(ITS#6696) back-sql and pagedResultsControl can be extremely heavy due to no LIMIT
by Andrew.Gray＠unlv.edu
Full_Name: Andrew Gray
Version: 2.4.17
OS: Debian 5.0
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (131.216.14.1)
On receiving LDAP queries with a pagedResultsControl (in this case with a size
of 250), back-sql generates an extremely inefficient query for every iteration
in the form of:
SELECT DISTINCT ldap_entries.id,people.local_id,text('UNLVexpperson') AS
objectClass,ldap_entries.dn AS dn FROM ldap_entries,people,ldap_entry_objclasses
WHERE people.local_
id=ldap_entries.keyval AND ldap_entries.oc_map_id=1 AND upper(ldap_entries.dn)
LIKE upper('%'||'%OU=PEOPLE,DC=UNLV,DC=EDU') AND ldap_entries.id>250 AND (2=2 OR
(ldap_entries.id=ldap_entry_objclasses.entry_id AND ldap_entry_objclasses.oc_
name='UNLVexpperson'))
(this repeats for id>250, id>500, id>750, etc. etc.)
Ideally (IMO) there really should be a SQL LIMIT applied here, as in this case
slapd gets back a few tens of thousands of rows on every iteration, and the
memory usage explodes and eventually gets killed.
12 years, 10 months
(ITS#6695) syncrepl end retrying and stop thread
by nacho＠di.uc3m.es
Full_Name: Nacho Diaz Asenjo
Version: 2.4.23
OS: Debian 5.0
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (2001:720:410:b131:219:d1ff:feb2:d0fa)
My slapd.conf slave
retry="30 10 600 10"
If operation fails stop retry (not +)
log file ----
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 be_search (0)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
uid=100010149,ou=LICENCIATURA EN ECONOMIA,ou=Alumnos,ou=Gente,o=Universidad
Carlos III,c=es
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 entry unchanged,
ignored (uid=100010149,ou=LICENCIATURA EN
ECONOMIA,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 be_search (0)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
uid=100044776,ou=DOCTORADO EN INGENIERIA
MATEMATICA,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 entry unchanged,
ignored (uid=100044776,ou=DOCTORADO EN INGENIERIA
MATEMATICA,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 be_search (0)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
uid=100010216,ou=DIPLOMATURA EN BIBLIOTECONOMIA Y
DOCUMENTACION,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 entry unchanged,
ignored (uid=100010216,ou=DIPLOMATURA EN BIBLIOTECONOMIA Y
DOCUMENTACION,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 be_search (0)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
uid=100016204,ou=LICENCIATURA EN HUMANIDADES,ou=Alumnos,ou=Gente,o=Universidad
Carlos III,c=es
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 entry unchanged,
ignored (uid=100016204,ou=LICENCIATURA EN
HUMANIDADES,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 be_search (0)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
uid=300040997,ou=MASTER OF BUSINESS
ADMINISTRATION,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 entry unchanged,
ignored (uid=300040997,ou=MASTER OF BUSINESS
ADMINISTRATION,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
LDAP_RES_SEARCH_ENTRY(LDAP_SYNC_ADD)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 be_search (0)
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002
uid=100003756,ou=DIPLOMATURA EN RELACIONES
LABORALES,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es
Nov 4 08:25:16 ldap02 slapd[404]: syncrepl_entry: rid=002 entry unchanged,
ignored (uid=100003756,ou=DIPLOMATURA EN RELACIONES
LABORALES,ou=Alumnos,ou=Gente,o=Universidad Carlos III,c=es)
Syncrepl is trying to change an entry which haven't changed ... with a
ldapsearch i can see same entry. But with a ldapbrowser export entry,
$ diff /tmp/a.ldif /tmp/b.ldif
2c2
< Universidad Carlos III,c=es
---
> Universidad Carlos III,c=ES
Entries seem different, baseDN is apparently different.
I don't know what's the problem but syncrepl retry change operation several
times and finally die, because nothing has changed really.
Thanks
12 years, 10 months
(ITS#6694) poor "unchecked" sizelimit doc
by h.b.furuseth＠usit.uio.no
Full_Name: Hallvard B Furuseth
Version: HEAD
OS: Linux
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (129.240.6.233)
Submitted by: hallvard
Both the admin guide and man slapd.conf(5) could use improved
"unchecked"/"pr" sizelimit documentation. That is, they could
mention a few more places that a statement like "sizelimit unlimited"
does not set the unchecked limit, so if you override limits set
elsewhere, you need to explicitly override your unchecked setting.
Admin guide: 9.3. Global Limits. 9.4.3. Specifying size limits
which does not mention that the default sets soft,hard.
Also the 9.4.3 syntax is wrong - doesn't mention .pr - as the
very next paragraph says. Same thing applies to the manpage.
Man page: 'sizelimit': does not mention that default is soft,hard.
'limits': says this at the very end - could move it up. And
split into several paragraphs.
12 years, 10 months
(ITS#6693) Value dependent ACL issues
by ralf＠OpenLDAP.org
Full_Name: Ralf Haferkamp
Version: 2.4.23, HEAD
OS:
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (92.252.54.248)
Submitted by: ralf
It seems that if the first ACL on a server is a value dependend ACL it is not
evaluated correctly.
Steps to reproduce:
1. Set this global ACL on the server:
access to dn.base="" attrs=supportedControl
val/objectIdentifierMatch=1.3.6.1.4.1.4203.666.5.14
by * none
access to dn.base=""
by * read
Now, when "1.3.6.1.4.1.4203.666.5.14" would be the first value of the
supportedControl Attribute that the server would return, slapd will return no
value of that attribute at all.
OTOH when "1.3.6.1.4.1.4203.666.5.14" is not the first value, slapd will return
all values of the "supportedControl" Attribute, including
"1.3.6.1.4.1.4203.666.5.14".
The expected result would be to return all values but
"1.3.6.1.4.1.4203.666.5.14".
This problem only seems to be present if there are no other ACLs present before
the first value dependent ACL.
This patch seems to fix the problem, it would be nice however if somebody with
more insight into the acl code could review it before we commit it to HEAD.
-------------------------------------------------------------
--- a/servers/slapd/acl.c
+++ b/servers/slapd/acl.c
@@ -405,7 +405,8 @@ access_allowed_mask(
if ( state->as_desc == desc &&
state->as_access == access &&
state->as_result != -1 &&
- state->as_vd_acl == NULL )
+ state->as_vd_acl == NULL &&
+ state->as_vd_acl_count > 0 )
{
Debug( LDAP_DEBUG_ACL,
"=> access_allowed: result was in cache
(%s)\n",
-------------------------------------------------------------
thanks,
Ralf
12 years, 10 months
Re: (ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by doug.leavitt＠oracle.com
Thanks Kurt. I missed seeing that part of the spec.
Doug.
On 11/ 2/10 01:33 PM, Kurt Zeilenga wrote:
> On Nov 2, 2010, at 10:59 AM, doug.leavitt(a)oracle.com wrote:
>
>> Full_Name: Doug Leavitt
>> Version: HEAD
>> OS: Solaris
>> URL: ftp://ftp.openldap.org/incoming/
>> Submission from: (NULL) (192.18.43.225)
>>
>>
>> It seems that slapd is returning success if an unsupported extensible match
>> is given. Probably LDAP_INAPPROPRIATE_MATCHING or maybe
>> LDAP_UNAVAILABLE_CRITICAL_EXTENSION chould be returned. Instead.
> Per RFC 4511, Section 4.5.1.7, no.
>
> -- Kurt
>
12 years, 10 months
(ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by doug.leavitt＠oracle.com
Full_Name: Doug Leavitt
Version: HEAD
OS: Solaris
URL: ftp://ftp.openldap.org/incoming/
Submission from: (NULL) (192.18.43.225)
It seems that slapd is returning success if an unsupported extensible match
is given. Probably LDAP_INAPPROPRIATE_MATCHING or maybe
LDAP_UNAVAILABLE_CRITICAL_EXTENSION chould be returned. Instead.
Example:
Attempting a search using the MS LDAP_MATCHING_RULE_IN_CHAIN extensible match
rule:
http://msdn.microsoft.com/en-us/library/aa746475%28VS.85%29.aspx
OID: 1.2.840.113556.1.4.194
Should fail since it is currently unsupported by OpenLDAP. Something like:
ldapsearch -v -h <server> -D <admin dn> -w <admin pw> -b <base>
"memberof:1.2.840.113556.1.4.1941:=cn=ldap_many1,dc=mc,dc=sun,dc=com"
Should return error, but instead returns success with 0 matches.
I believe that the root of the problem is that in servers/slapd/filter.c:
case LDAP_FILTER_EXT:
Debug( LDAP_DEBUG_FILTER, "EXTENSIBLE\n", 0, 0, 0 );
err = get_mra( op, ber, &f, text );
if ( err != LDAP_SUCCESS ) {
break;
>>> err is returned with the value LDAP_INAPPROPRIATE_MATCHING
}
assert( f.f_mra != NULL );
break;
default:
(void) ber_scanf( ber, "x" ); /* skip the element */
Debug( LDAP_DEBUG_ANY, "get_filter: unknown filter type=%lu\n",
f.f_choice, 0, 0 );
f.f_choice = SLAPD_FILTER_COMPUTED;
f.f_result = SLAPD_COMPARE_UNDEFINED;
break;
}
>>> and will return LDAP_SUCCESS with the following:
if( err != LDAP_SUCCESS && err != SLAPD_DISCONNECT ) {
/* ignore error */
*text = NULL;
f.f_choice = SLAPD_FILTER_COMPUTED;
f.f_result = SLAPD_COMPARE_UNDEFINED;
err = LDAP_SUCCESS;
}
which will allow the filter to proceed, loosing the error.
It seems like the search should fail given an illegal/unsupported
extensible filter.
12 years, 10 months
Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by masarati＠aero.polimi.it
Looks like a duplicate of ITS#6657; I have already investigated that bug
to no avail. Apparently, a pointer to stack-residing data is erroneously
freed. You may be able to find out more info by checking where this
happens from the core. I can't take care of this issue right now as I'd
need to give it incredibly low priority.
p.
> Ok, thanks for the answer
>
> This is the new backtrace:
>
> Core was generated by `./slapd -d -1'.
> Program terminated with signal 11, Segmentation fault.
> [New process 1656]
> [New process 1570]
> [New process 1573]
> #0 0x0000000000491ac5 in slap_sl_free (ptr=0xffffffd2028b00d0,
> ctx=0x28a3120)
> at sl_malloc.c:490
> 490 if ( tmpp[-1] & 1 ) {
> (gdb) bt
> #0 0x0000000000491ac5 in slap_sl_free (ptr=0xffffffd2028b00d0,
> ctx=0x28a3120)
> at sl_malloc.c:490
> #1 0x00000000004d562e in backsql_entry_clean (op=0x28a9b10, e=0x42e98a40)
> at search.c:2680
> #2 0x00000000004d4e8f in backsql_search (op=0x28a9b10, rs=0x42e99ca0)
> at search.c:2517
> #3 0x0000000000429f5c in fe_op_search (op=0x28a9b10, rs=0x42e99ca0)
> at search.c:366
> #4 0x00000000004298c7 in do_search (op=0x28a9b10, rs=0x42e99ca0)
> at search.c:217
> #5 0x0000000000426952 in connection_operation (ctx=0x42e99df0,
> arg_v=0x28a9b10) at connection.c:1109
> #6 0x0000000000426ede in connection_read_thread (ctx=0x42e99df0,
> argv=0x9)
> at connection.c:1245
> #7 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=0x26f6ea0)
> at tpool.c:685
> #8 0x00007fddda10cfc7 in start_thread () from /lib/libpthread.so.0
> #9 0x00007fddd9e8264d in clone () from /lib/libc.so.6
> #10 0x0000000000000000 in ?? ()
>
>
>
>
>
>
> 2010/11/1 <masarati(a)aero.polimi.it>
>
>> > Full_Name: Andrés Marenco Zúñiga
>> > Version: 2.4.23 (20100719)
>> > OS: Debian 5.06 amd64
>> > URL:
>> > Submission from: (NULL) (201.198.99.66)
>> >
>> >
>> > I'm getting a segfault while doing any search in openldap. This is my
>> > configuration:
>> >
>> > Debian 5.06 amd64 (kernel 2.6.26-2-amd64)
>> > OpenLDAP 2.4.23 (20100719)
>> > UnixODBC 2.3.0
>> > PostgreSQL 8.2.10
>> > psqlodbc 09.00.0101
>> >
>> >
>> >
>> #############################################################################
>> > slapd.conf (the relevant parts)
>> >
>> #############################################################################
>> > include
>> /var/lib/openldap/etc/openldap/schema/core.schema
>> > include
>> /var/lib/openldap/etc/openldap/schema/cosine.schema
>> > include
>> /var/lib/openldap/etc/openldap/schema/inetorgperson.schema
>> >
>> > pidfile /var/lib/openldap/var/slapd.pid
>> > argsfile /var/lib/openldap/slapd.args
>> >
>> > database sql
>> > suffix "dc=example,dc=com"
>> > rootdn "cn=root,dc=example,dc=com"
>> > rootpw secret
>> > dbname PgSQL
>> > dbuser ""
>> > dbpasswd ""
>> > insentry_stmt "insert into ldap_entries
>> (id,dn,oc_map_id,parent,keyval)
>> > values
>> > ((select max(id)+1 from ldap_entries),?,?,?,?)"
>> > upper_func "upper"
>> > strcast_func "text"
>> > concat_pattern "?||?"
>> > has_ldapinfo_dn_ru no
>> >
>> > lastmod off
>> >
>> >
>> >
>> >
>> #############################################################################
>> > odbcinst.ini
>> >
>> #############################################################################
>> > [PostgreSQL]
>> > Description=ODBC for PostgreSQL
>> > Driver=/usr/local/lib/psqlodbcw.so
>> >
>> >
>> >
>> #############################################################################
>> > odbc.ini
>> >
>> #############################################################################
>> > [PgSQL]
>> > Driver=/usr/local/lib/psqlodbcw.so
>> > Description=Connection to LDAP/POSTGRESQL
>> > Server=xxx.xxx.xxx.xxx
>> > Port=5432
>> > Protocol=6.4
>> > FetchBufferSize=99
>> > Database=db
>> > Username=user
>> > ReadOnly=no
>> > CommLog=1
>> >
>> >
>> >
>> >
>> >
>> >
>> > slapd starts fine, but when I make any search this is what I'm
>> getting:
>> >
>> > <= send_search_entry: conn 1000 exit.
>> > send_ldap_result: conn=1000 op=2 p=3
>> > send_ldap_result: err=0 matched="" text=""
>> > send_ldap_response: msgid=3 tag=101 err=0
>> > ber_flush2: 14 bytes to sd 11
>> > 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00
>> 0....e........
>> > ldap_write: want=14, written=14
>> > 0000: 30 0c 02 01 03 65 07 0a 01 00 04 00 04 00
>> 0....e........
>> > conn=1000 op=2 SEARCH RESULT tag=101 err=0 nentries=1 text=
>> > Segmentation Fault (Core Dumped)
>> >
>> >
>> >
>> > in the syslog this is what I have:
>> >
>> > Oct 29 17:53:17 td-server slapd[32026]: conn=1000 op=2 SEARCH RESULT
>> > tag=101
>> > err=0 nentries=1 text=
>> > Oct 29 17:53:17 td-server kernel: [10058.462325] slapd[32029]:
>> segfault
>> at
>> > ffffffde0274e4a0 ip 46c23b sp 425d7570 error 4 in slapd[400000+161000]
>> >
>> >
>> >
>> > and the gdb backtrace shows this:
>> >
>> > Core was generated by `/var/lib/openldap/libexec/slapd -d -1'.
>> > Program terminated with signal 11, Segmentation fault.
>> > [New process 31991]
>> > [New process 31987]
>> > [New process 31990]
>> > #0 0x000000000046c23b in ?? ()
>> > #1 0x0000000000499903 in ?? ()
>> > #2 0x000000000049e01b in ?? ()
>> > #3 0x000000000041ed51 in ?? ()
>> > #4 0x000000000041f54c in ?? ()
>> > #5 0x000000000041cb5f in ?? ()
>> > #6 0x000000000041d7dc in ?? ()
>> > #7 0x00000000004c8760 in ?? ()
>> > #8 0x00007fe1a4861fc7 in start_thread () from /lib/libpthread.so.0
>> > #9 0x00007fe1a45d764d in clone () from /lib/libc.so.6
>> > #10 0x0000000000000000 in ?? ()
>>
>> This trace is useless; since the issue appears to be repeatable, you
>> should retry with slapd built with debugging symbols and unstripped.
>>
>> >
>> >
>> >
>> >
>> > Everything works fine in 32bits (Debian 5.0 i386), but it fails with
>> > 64bits.
>> >
>> > Any idea?
>> >
>> Moreover, you may want to try with HEAD code, where some modifications
>> to
>> deal with 64 bit (long int) key values. Should be unrelated, but just
>> in
>> case...
>>
>> p.
>>
>>
>>
>>
>
>
> --
> Andrés Marenco Zúñiga
> Equipo de Desarrollo
> TEC_Digital
>
12 years, 10 months
Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by andresmarenco＠gmail.com
--20cf3054961990a416049404fd5f
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Ok. Here is the full backtrace:
#0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffde01373fc0,
ctx=3D0x1367120)
at sl_malloc.c:490
490 if ( tmpp[-1] & 1 ) {
(gdb) thr apply all bt full
Thread 3 (process 30526):
#0 0x00007f6cc93b4c18 in epoll_wait () from /lib/libc.so.6
No symbol table info available.
#1 0x0000000000422e03 in slapd_daemon_task (ptr=3D0x0) at daemon.c:2467
ns =3D 1
at =3D 0
nfds =3D 4
revents =3D (struct epoll_event *) 0x11996b0
tvp =3D (struct timeval *) 0x0
cat =3D {tv_sec =3D 0, tv_usec =3D 0}
i =3D 1
nwriters =3D 0
now =3D 1288647213
tv =3D {tv_sec =3D 0, tv_usec =3D 0}
tdelta =3D 1
rtask =3D (struct re_s *) 0x0
l =3D 2
last_idle_check =3D 0
ebadf =3D 0
#2 0x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#3 0x00007f6cc93b464d in clone () from /lib/libc.so.6
No symbol table info available.
#4 0x0000000000000000 in ?? ()
No symbol table info available.
Thread 2 (process 30523):
#0 0x00007f6cc963f715 in pthread_join () from /lib/libpthread.so.0
No symbol table info available.
#1 0x000000000050f74f in ldap_pvt_thread_join (thread=3D1103399248,
thread_return=3D0x0) at thr_posix.c:197
No locals.
#2 0x0000000000423b52 in slapd_daemon () at daemon.c:2842
listener_tid =3D 1103399248
rc =3D 0
#3 0x0000000000406093 in main (argc=3D3, argv=3D0x7fff6175c7a8) at main.c:=
961
i =3D 3
no_detach =3D 1
rc =3D 0
urls =3D 0x0
username =3D 0x0
groupname =3D 0x0
sandbox =3D 0x0
syslogUser =3D 160
g_argc =3D 3
g_argv =3D (char **) 0x7fff6175c7a8
configfile =3D 0x0
configdir =3D 0x0
serverName =3D 0x7fff6175d7da "slapd"
serverMode =3D 1
scp =3D (struct sync_cookie *) 0x0
scp_entry =3D (struct sync_cookie *) 0x0
debug_unknowns =3D (char **) 0x0
syslog_unknowns =3D (char **) 0x0
serverNamePrefix =3D 0x53fb6b ""
l =3D 4209819
slapd_pid_file_unlink =3D 1
slapd_args_file_unlink =3D 1
firstopt =3D 0
__PRETTY_FUNCTION__ =3D "main"
Thread 1 (process 30527):
#0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffde01373fc0,
ctx=3D0x1367120)
at sl_malloc.c:490
sh =3D (struct slab_heap *) 0x1367120
size =3D 146028888064
p =3D (ber_len_t *) 0xffffffde01373fb8
tmpp =3D (ber_len_t *) 0xffffffde01373fb8
__PRETTY_FUNCTION__ =3D "slap_sl_free"
#1 0x00000000004d562e in backsql_entry_clean (op=3D0x136db10, e=3D0x42447a=
40)
at search.c:2680
ctx =3D (void *) 0x42448df0
#2 0x00000000004d4e8f in backsql_search (op=3D0x136db10, rs=3D0x42448ca0)
at search.c:2517
bi =3D (backsql_info *) 0x11de090
dbh =3D (SQLHDBC) 0x1343bf0
sres =3D 0
user_entry =3D {e_id =3D 0, e_name =3D {bv_len =3D 0, bv_val =3D 0x0},
e_nname =3D {bv_len =3D 0, bv_val =3D 0x0}, e_attrs =3D 0x0, e_ocflags =
=3D 0, e_bv =3D
{
bv_len =3D 0, bv_val =3D 0x0}, e_private =3D 0x0}
base_entry =3D {e_id =3D 2743, e_name =3D {bv_len =3D 0, bv_val =3D 0x0=
},
e_nname =3D {bv_len =3D 34,
bv_val =3D 0x1380620 "dc=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"},
e_attrs =3D 0x1212858, e_ocflags =3D 256, e_bv =3D {bv_len =3D 0, bv_val =
=3D 0x0},
e_private =3D 0x0}
manageDSAit =3D 0
stoptime =3D 1288647212
bsi =3D {bsi_op =3D 0x136db10, bsi_rs =3D 0x42448ca0, bsi_flags =3D 1,
bsi_base_ndn =3D 0x136db48, bsi_use_subtree_shortcut =3D 0, bsi_base_id =
=3D {
eid_id =3D 2743, eid_keyval =3D 2743, eid_oc_id =3D 1, eid_oc =3D 0x136=
93b0,
eid_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, eid_ndn =3D {bv_len =3D 0, b=
v_val =3D
0x0},
eid_next =3D 0x0}, bsi_scope =3D 0, bsi_filter =3D 0x1373e98,
bsi_stoptime =3D 1288647212, bsi_id_list =3D 0x42447938,
bsi_id_listtail =3D 0x42447978, bsi_c_eid =3D 0x42447938, bsi_n_candidate=
s =3D
-2,
bsi_status =3D 0, bsi_oc =3D 0x13693b0, bsi_sel =3D {bb_val =3D {bv_len =
=3D 0,
bv_val =3D 0x0}, bb_len =3D 0}, bsi_from =3D {bb_val =3D {bv_len =3D =
0,
bv_val =3D 0x0}, bb_len =3D 0}, bsi_join_where =3D {bb_val =3D {bv_le=
n =3D 0,
bv_val =3D 0x0}, bb_len =3D 0}, bsi_flt_where =3D {bb_val =3D {bv_len=
=3D 0,
bv_val =3D 0x0}, bb_len =3D 0}, bsi_filter_oc =3D 0x0, bsi_dbh =3D 0x=
1343bf0,
bsi_attrs =3D 0x0, bsi_e =3D 0x0}
eid =3D (backsql_entryID *) 0x0
nbase =3D {bv_len =3D 0, bv_val =3D 0x0}
lastid =3D 0
#3 0x0000000000429f5c in fe_op_search (op=3D0x136db10, rs=3D0x42448ca0)
at search.c:366
bd =3D (BackendDB *) 0x7c28a0
#4 0x00000000004298c7 in do_search (op=3D0x136db10, rs=3D0x42448ca0)
at search.c:217
base =3D {bv_len =3D 34,
bv_val =3D 0x136d867 "dc=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}
siz =3D 0
off =3D 0
i =3D 0
#5 0x0000000000426952 in connection_operation (ctx=3D0x42448df0,
arg_v=3D0x136db10) at connection.c:1109
rc =3D 80
cancel =3D 32620
op =3D (Operation *) 0x136db10
rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 3, sr_err =
=3D 0,
sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, sr_ctrls =3D 0x0, sr=
_un =3D {
sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operational_attr=
s =3D
0x0,
r_attrs =3D 0x0, r_nentries =3D 1, r_v2ref =3D 0x0}, sru_sasl =3D {
r_sasldata =3D 0x0}, sru_extended =3D {r_rspoid =3D 0x0, r_rspdata =
=3D 0x0}},
sr_flags =3D 0}
tag =3D 99
opidx =3D SLAP_OP_SEARCH
conn =3D (Connection *) 0x7f6cca0568d0
memctx =3D (void *) 0x1367120
memctx_null =3D (void *) 0x0
memsiz =3D 1048576
__PRETTY_FUNCTION__ =3D "connection_operation"
#6 0x0000000000426ede in connection_read_thread (ctx=3D0x42448df0, argv=3D=
0x9)
at connection.c:1245
rc =3D 0
cri =3D {op =3D 0x136db10, func =3D 0, arg =3D 0x0, ctx =3D 0x42448df0,
nullop =3D 0}
s =3D 9
#7 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=3D0x11baea0)
at tpool.c:685
pool =3D (struct ldap_int_thread_pool_s *) 0x11baea0
task =3D (ldap_int_thread_task_t *) 0x136d610
work_list =3D (ldap_int_tpool_plist_t *) 0x11baf38
ctx =3D {ltu_id =3D 1111791952, ltu_key =3D {{ltk_key =3D 0x4264ab,
ltk_data =3D 0x136df60, ltk_free =3D 0x4262fb <conn_counter_destroy>}=
, {
ltk_key =3D 0x490802, ltk_data =3D 0x1367120,
ltk_free =3D 0x4905fc <slap_sl_mem_destroy>}, {ltk_key =3D 0x440888,
ltk_data =3D 0x0, ltk_free =3D 0x4407e4 <slap_op_q_destroy>}, {
ltk_key =3D 0x806ca0, ltk_data =3D 0x1343bf0,
ltk_free =3D 0x4d6aea <backsql_db_conn_keyfree>}, {ltk_key =3D 0x0,
ltk_data =3D 0x0, ltk_free =3D 0} <repeats 28 times>}}
kctx =3D (ldap_int_thread_userctx_t *) 0x0
i =3D 32
keyslot =3D 431
hash =3D 2036986287
__PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"
#8 0x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0
No symbol table info available.
#9 0x00007f6cc93b464d in clone () from /lib/libc.so.6
No symbol table info available.
#10 0x0000000000000000 in ?? ()
No symbol table info available.
(gdb)
--=20
Andr=E9s Marenco Z=FA=F1iga
Equipo de Desarrollo
TEC_Digital
--20cf3054961990a416049404fd5f
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Ok. Here is the full backtrace:<br><br>#0=A0 0x0000000000491ac5 in slap_sl_=
free (ptr=3D0xffffffde01373fc0, ctx=3D0x1367120)<br>=A0=A0=A0 at sl_malloc.=
c:490<br>490=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 if ( tmpp[-1] & 1 )=
{<br>(gdb) thr apply all bt full<br>
<br>Thread 3 (process 30526):<br>#0=A0 0x00007f6cc93b4c18 in epoll_wait () =
from /lib/libc.so.6<br>No symbol table info available.<br>#1=A0 0x000000000=
0422e03 in slapd_daemon_task (ptr=3D0x0) at daemon.c:2467<br>=A0=A0=A0 ns =
=3D 1<br>=A0=A0=A0 at =3D 0<br>
=A0=A0=A0 nfds =3D 4<br>=A0=A0=A0 revents =3D (struct epoll_event *) 0x1199=
6b0<br>=A0=A0=A0 tvp =3D (struct timeval *) 0x0<br>=A0=A0=A0 cat =3D {tv_se=
c =3D 0, tv_usec =3D 0}<br>=A0=A0=A0 i =3D 1<br>=A0=A0=A0 nwriters =3D 0<br=
>=A0=A0=A0 now =3D 1288647213<br>=A0=A0=A0 tv =3D {tv_sec =3D 0, tv_usec =
=3D 0}<br>
=A0=A0=A0 tdelta =3D 1<br>=A0=A0=A0 rtask =3D (struct re_s *) 0x0<br>=A0=A0=
=A0 l =3D 2<br>=A0=A0=A0 last_idle_check =3D 0<br>=A0=A0=A0 ebadf =3D 0<br>=
#2=A0 0x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0<br>No=
symbol table info available.<br>#3=A0 0x00007f6cc93b464d in clone () from =
/lib/libc.so.6<br>
No symbol table info available.<br>#4=A0 0x0000000000000000 in ?? ()<br>No =
symbol table info available.<br><br>Thread 2 (process 30523):<br>#0=A0 0x00=
007f6cc963f715 in pthread_join () from /lib/libpthread.so.0<br>No symbol ta=
ble info available.<br>
#1=A0 0x000000000050f74f in ldap_pvt_thread_join (thread=3D1103399248, <br>=
=A0=A0=A0 thread_return=3D0x0) at thr_posix.c:197<br>No locals.<br>#2=A0 0x=
0000000000423b52 in slapd_daemon () at daemon.c:2842<br>=A0=A0=A0 listener_=
tid =3D 1103399248<br>
=A0=A0=A0 rc =3D 0<br>#3=A0 0x0000000000406093 in main (argc=3D3, argv=3D0x=
7fff6175c7a8) at main.c:961<br>=A0=A0=A0 i =3D 3<br>=A0=A0=A0 no_detach =3D=
1<br>=A0=A0=A0 rc =3D 0<br>=A0=A0=A0 urls =3D 0x0<br>=A0=A0=A0 username =
=3D 0x0<br>=A0=A0=A0 groupname =3D 0x0<br>=A0=A0=A0 sandbox =3D 0x0<br>
=A0=A0=A0 syslogUser =3D 160<br>=A0=A0=A0 g_argc =3D 3<br>=A0=A0=A0 g_argv =
=3D (char **) 0x7fff6175c7a8<br>=A0=A0=A0 configfile =3D 0x0<br>=A0=A0=A0 c=
onfigdir =3D 0x0<br>=A0=A0=A0 serverName =3D 0x7fff6175d7da "slapd&quo=
t;<br>=A0=A0=A0 serverMode =3D 1<br>=A0=A0=A0 scp =3D (struct sync_cookie *=
) 0x0<br>
=A0=A0=A0 scp_entry =3D (struct sync_cookie *) 0x0<br>=A0=A0=A0 debug_unkno=
wns =3D (char **) 0x0<br>=A0=A0=A0 syslog_unknowns =3D (char **) 0x0<br>=A0=
=A0=A0 serverNamePrefix =3D 0x53fb6b ""<br>=A0=A0=A0 l =3D 420981=
9<br>=A0=A0=A0 slapd_pid_file_unlink =3D 1<br>
=A0=A0=A0 slapd_args_file_unlink =3D 1<br>=A0=A0=A0 firstopt =3D 0<br>=A0=
=A0=A0 __PRETTY_FUNCTION__ =3D "main"<br><br>Thread 1 (process 30=
527):<br>#0=A0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffde01373fc0=
, ctx=3D0x1367120)<br>=A0=A0=A0 at sl_malloc.c:490<br>
=A0=A0=A0 sh =3D (struct slab_heap *) 0x1367120<br>=A0=A0=A0 size =3D 14602=
8888064<br>=A0=A0=A0 p =3D (ber_len_t *) 0xffffffde01373fb8<br>=A0=A0=A0 tm=
pp =3D (ber_len_t *) 0xffffffde01373fb8<br>=A0=A0=A0 __PRETTY_FUNCTION__ =
=3D "slap_sl_free"<br>#1=A0 0x00000000004d562e in backsql_entry_c=
lean (op=3D0x136db10, e=3D0x42447a40)<br>
=A0=A0=A0 at search.c:2680<br>=A0=A0=A0 ctx =3D (void *) 0x42448df0<br>#2=
=A0 0x00000000004d4e8f in backsql_search (op=3D0x136db10, rs=3D0x42448ca0)<=
br>=A0=A0=A0 at search.c:2517<br>=A0=A0=A0 bi =3D (backsql_info *) 0x11de09=
0<br>=A0=A0=A0 dbh =3D (SQLHDBC) 0x1343bf0<br>
=A0=A0=A0 sres =3D 0<br>=A0=A0=A0 user_entry =3D {e_id =3D 0, e_name =3D {b=
v_len =3D 0, bv_val =3D 0x0}, <br>=A0 e_nname =3D {bv_len =3D 0, bv_val =3D=
0x0}, e_attrs =3D 0x0, e_ocflags =3D 0, e_bv =3D {<br>=A0=A0=A0 bv_len =3D=
0, bv_val =3D 0x0}, e_private =3D 0x0}<br>=A0=A0=A0 base_entry =3D {e_id =
=3D 2743, e_name =3D {bv_len =3D 0, bv_val =3D 0x0}, <br>
=A0 e_nname =3D {bv_len =3D 34, <br>=A0=A0=A0 bv_val =3D 0x1380620 "dc=
=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}, <br>=A0 e_attrs =3D 0x1212=
858, e_ocflags =3D 256, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, <br>=A0 e_=
private =3D 0x0}<br>=A0=A0=A0 manageDSAit =3D 0<br>
=A0=A0=A0 stoptime =3D 1288647212<br>=A0=A0=A0 bsi =3D {bsi_op =3D 0x136db1=
0, bsi_rs =3D 0x42448ca0, bsi_flags =3D 1, <br>=A0 bsi_base_ndn =3D 0x136db=
48, bsi_use_subtree_shortcut =3D 0, bsi_base_id =3D {<br>=A0=A0=A0 eid_id =
=3D 2743, eid_keyval =3D 2743, eid_oc_id =3D 1, eid_oc =3D 0x13693b0, <br>
=A0=A0=A0 eid_dn =3D {bv_len =3D 0, bv_val =3D 0x0}, eid_ndn =3D {bv_len =
=3D 0, bv_val =3D 0x0}, <br>=A0=A0=A0 eid_next =3D 0x0}, bsi_scope =3D 0, b=
si_filter =3D 0x1373e98, <br>=A0 bsi_stoptime =3D 1288647212, bsi_id_list =
=3D 0x42447938, <br>=A0 bsi_id_listtail =3D 0x42447978, bsi_c_eid =3D 0x424=
47938, bsi_n_candidates =3D -2, <br>
=A0 bsi_status =3D 0, bsi_oc =3D 0x13693b0, bsi_sel =3D {bb_val =3D {bv_len=
=3D 0, <br>=A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_from =3D {b=
b_val =3D {bv_len =3D 0, <br>=A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}=
, bsi_join_where =3D {bb_val =3D {bv_len =3D 0, <br>
=A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_flt_where =3D {bb_val =
=3D {bv_len =3D 0, <br>=A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_=
filter_oc =3D 0x0, bsi_dbh =3D 0x1343bf0, <br>=A0 bsi_attrs =3D 0x0, bsi_e =
=3D 0x0}<br>=A0=A0=A0 eid =3D (backsql_entryID *) 0x0<br>
=A0=A0=A0 nbase =3D {bv_len =3D 0, bv_val =3D 0x0}<br>=A0=A0=A0 lastid =3D =
0<br>#3=A0 0x0000000000429f5c in fe_op_search (op=3D0x136db10, rs=3D0x42448=
ca0)<br>=A0=A0=A0 at search.c:366<br>=A0=A0=A0 bd =3D (BackendDB *) 0x7c28a=
0<br>#4=A0 0x00000000004298c7 in do_search (op=3D0x136db10, rs=3D0x42448ca0=
)<br>
=A0=A0=A0 at search.c:217<br>=A0=A0=A0 base =3D {bv_len =3D 34, <br>=A0 bv_=
val =3D 0x136d867 "dc=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}<b=
r>=A0=A0=A0 siz =3D 0<br>=A0=A0=A0 off =3D 0<br>=A0=A0=A0 i =3D 0<br>#5=A0 =
0x0000000000426952 in connection_operation (ctx=3D0x42448df0, <br>
=A0=A0=A0 arg_v=3D0x136db10) at connection.c:1109<br>=A0=A0=A0 rc =3D 80<br=
>=A0=A0=A0 cancel =3D 32620<br>=A0=A0=A0 op =3D (Operation *) 0x136db10<br>=
=A0=A0=A0 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 3, s=
r_err =3D 0, <br>=A0 sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, s=
r_ctrls =3D 0x0, sr_un =3D {<br>
=A0=A0=A0 sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operationa=
l_attrs =3D 0x0, <br>=A0=A0=A0=A0=A0 r_attrs =3D 0x0, r_nentries =3D 1, r_v=
2ref =3D 0x0}, sru_sasl =3D {<br>=A0=A0=A0=A0=A0 r_sasldata =3D 0x0}, sru_e=
xtended =3D {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, <br>
=A0 sr_flags =3D 0}<br>=A0=A0=A0 tag =3D 99<br>=A0=A0=A0 opidx =3D SLAP_OP_=
SEARCH<br>=A0=A0=A0 conn =3D (Connection *) 0x7f6cca0568d0<br>=A0=A0=A0 mem=
ctx =3D (void *) 0x1367120<br>=A0=A0=A0 memctx_null =3D (void *) 0x0<br>=A0=
=A0=A0 memsiz =3D 1048576<br>=A0=A0=A0 __PRETTY_FUNCTION__ =3D "connec=
tion_operation"<br>
#6=A0 0x0000000000426ede in connection_read_thread (ctx=3D0x42448df0, argv=
=3D0x9)<br>=A0=A0=A0 at connection.c:1245<br>=A0=A0=A0 rc =3D 0<br>=A0=A0=
=A0 cri =3D {op =3D 0x136db10, func =3D 0, arg =3D 0x0, ctx =3D 0x42448df0,=
<br>=A0 nullop =3D 0}<br>=A0=A0=A0 s =3D 9<br>
#7=A0 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=3D0x11baea0=
)<br>=A0=A0=A0 at tpool.c:685<br>=A0=A0=A0 pool =3D (struct ldap_int_thread=
_pool_s *) 0x11baea0<br>=A0=A0=A0 task =3D (ldap_int_thread_task_t *) 0x136=
d610<br>=A0=A0=A0 work_list =3D (ldap_int_tpool_plist_t *) 0x11baf38<br>
=A0=A0=A0 ctx =3D {ltu_id =3D 1111791952, ltu_key =3D {{ltk_key =3D 0x4264a=
b, <br>=A0=A0=A0=A0=A0 ltk_data =3D 0x136df60, ltk_free =3D 0x4262fb <co=
nn_counter_destroy>}, {<br>=A0=A0=A0=A0=A0 ltk_key =3D 0x490802, ltk_dat=
a =3D 0x1367120, <br>=A0=A0=A0=A0=A0 ltk_free =3D 0x4905fc <slap_sl_mem_=
destroy>}, {ltk_key =3D 0x440888, <br>
=A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0x4407e4 <slap_op_q_destr=
oy>}, {<br>=A0=A0=A0=A0=A0 ltk_key =3D 0x806ca0, ltk_data =3D 0x1343bf0,=
<br>=A0=A0=A0=A0=A0 ltk_free =3D 0x4d6aea <backsql_db_conn_keyfree>}=
, {ltk_key =3D 0x0, <br>=A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0} &=
lt;repeats 28 times>}}<br>
=A0=A0=A0 kctx =3D (ldap_int_thread_userctx_t *) 0x0<br>=A0=A0=A0 i =3D 32<=
br>=A0=A0=A0 keyslot =3D 431<br>=A0=A0=A0 hash =3D 2036986287<br>=A0=A0=A0 =
__PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper"<br>#8=A0 0=
x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0<br>
No symbol table info available.<br>#9=A0 0x00007f6cc93b464d in clone () fro=
m /lib/libc.so.6<br>No symbol table info available.<br>#10 0x00000000000000=
00 in ?? ()<br>No symbol table info available.<br>(gdb) <br><br><br>-- <br>
Andr=E9s Marenco Z=FA=F1iga<br>Equipo de Desarrollo<br>TEC_Digital<br>
--20cf3054961990a416049404fd5f--
12 years, 10 months
