openldap-bugs November 2010

openldap-bugs@openldap.org

32 participants
103 discussions

(ITS#6696) back-sql and pagedResultsControl can be extremely heavy due to no LIMIT
by Andrew.Gray＠unlv.edu 04 Nov '10

04 Nov '10

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.

1 0

(ITS#6695) syncrepl end retrying and stop thread
by nacho＠di.uc3m.es 04 Nov '10

04 Nov '10

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

1 0

(ITS#6694) poor "unchecked" sizelimit doc
by h.b.furuseth＠usit.uio.no 03 Nov '10

03 Nov '10

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.

1 0

(ITS#6693) Value dependent ACL issues
by ralf＠OpenLDAP.org 03 Nov '10

03 Nov '10

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

1 0

Re: (ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by doug.leavitt＠oracle.com 02 Nov '10

02 Nov '10

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 >

1 0

Re: (ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by Kurt＠OpenLDAP.org 02 Nov '10

02 Nov '10

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

1 0

(ITS#6692) LDAP_INAPPROPRIATE_MATCHING not returned when faced with an unsupported extensible match
by doug.leavitt＠oracle.com 02 Nov '10

02 Nov '10

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.

1 0

Re: (ITS#6690) ldap_result & LDAP_TIMEOUT
by hyc＠symas.com 02 Nov '10

02 Nov '10

greg.silverman(a)webex.com wrote: > Full_Name: Greg Silverman > Version: 2.4.23 > OS: CentOS 5 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (171.69.115.12) > > > At result.c, line 438, ldap_result will return 0==LDAP_SUCCESS even though there > was a timeout error, ld_errno==LDAP_TIMEOUT > The return code from ldap_result is not return an LDAP success code. There is no bug here, this ITS will be closed. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by masarati＠aero.polimi.it 02 Nov '10

02 Nov '10

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 >

1 0

Re: (ITS#6691) error 4 in slapd: segfault with back-sql in debian amd64
by andresmarenco＠gmail.com 01 Nov '10

01 Nov '10

--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: #0=A0 0x0000000000491ac5 in slap_sl_= free (ptr=3D0xffffffde01373fc0, ctx=3D0x1367120) =A0=A0=A0 at sl_malloc.= c:490 490=A0=A0=A0 =A0=A0=A0 =A0=A0=A0 =A0=A0=A0 if ( tmpp[-1] & 1 )= { (gdb) thr apply all bt full Thread 3 (process 30526): #0=A0 0x00007f6cc93b4c18 in epoll_wait () = from /lib/libc.so.6 No symbol table info available. #1=A0 0x000000000= 0422e03 in slapd_daemon_task (ptr=3D0x0) at daemon.c:2467 =A0=A0=A0 ns = =3D 1 =A0=A0=A0 at =3D 0 =A0=A0=A0 nfds =3D 4 =A0=A0=A0 revents =3D (struct epoll_event *) 0x1199= 6b0 =A0=A0=A0 tvp =3D (struct timeval *) 0x0 =A0=A0=A0 cat =3D {tv_se= c =3D 0, tv_usec =3D 0} =A0=A0=A0 i =3D 1 =A0=A0=A0 nwriters =3D 0<br= >=A0=A0=A0 now =3D 1288647213 =A0=A0=A0 tv =3D {tv_sec =3D 0, tv_usec = =3D 0} =A0=A0=A0 tdelta =3D 1 =A0=A0=A0 rtask =3D (struct re_s *) 0x0 =A0=A0= =A0 l =3D 2 =A0=A0=A0 last_idle_check =3D 0 =A0=A0=A0 ebadf =3D 0 = #2=A0 0x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0 No= symbol table info available. #3=A0 0x00007f6cc93b464d in clone () from = /lib/libc.so.6 No symbol table info available. #4=A0 0x0000000000000000 in ?? () No = symbol table info available. Thread 2 (process 30523): #0=A0 0x00= 007f6cc963f715 in pthread_join () from /lib/libpthread.so.0 No symbol ta= ble info available. #1=A0 0x000000000050f74f in ldap_pvt_thread_join (thread=3D1103399248, = =A0=A0=A0 thread_return=3D0x0) at thr_posix.c:197 No locals. #2=A0 0x= 0000000000423b52 in slapd_daemon () at daemon.c:2842 =A0=A0=A0 listener_= tid =3D 1103399248 =A0=A0=A0 rc =3D 0 #3=A0 0x0000000000406093 in main (argc=3D3, argv=3D0x= 7fff6175c7a8) at main.c:961 =A0=A0=A0 i =3D 3 =A0=A0=A0 no_detach =3D= 1 =A0=A0=A0 rc =3D 0 =A0=A0=A0 urls =3D 0x0 =A0=A0=A0 username = =3D 0x0 =A0=A0=A0 groupname =3D 0x0 =A0=A0=A0 sandbox =3D 0x0 =A0=A0=A0 syslogUser =3D 160 =A0=A0=A0 g_argc =3D 3 =A0=A0=A0 g_argv = =3D (char **) 0x7fff6175c7a8 =A0=A0=A0 configfile =3D 0x0 =A0=A0=A0 c= onfigdir =3D 0x0 =A0=A0=A0 serverName =3D 0x7fff6175d7da "slapd&quo= t; =A0=A0=A0 serverMode =3D 1 =A0=A0=A0 scp =3D (struct sync_cookie *= ) 0x0 =A0=A0=A0 scp_entry =3D (struct sync_cookie *) 0x0 =A0=A0=A0 debug_unkno= wns =3D (char **) 0x0 =A0=A0=A0 syslog_unknowns =3D (char **) 0x0 =A0= =A0=A0 serverNamePrefix =3D 0x53fb6b "" =A0=A0=A0 l =3D 420981= 9 =A0=A0=A0 slapd_pid_file_unlink =3D 1 =A0=A0=A0 slapd_args_file_unlink =3D 1 =A0=A0=A0 firstopt =3D 0 =A0= =A0=A0 __PRETTY_FUNCTION__ =3D "main" Thread 1 (process 30= 527): #0=A0 0x0000000000491ac5 in slap_sl_free (ptr=3D0xffffffde01373fc0= , ctx=3D0x1367120) =A0=A0=A0 at sl_malloc.c:490 =A0=A0=A0 sh =3D (struct slab_heap *) 0x1367120 =A0=A0=A0 size =3D 14602= 8888064 =A0=A0=A0 p =3D (ber_len_t *) 0xffffffde01373fb8 =A0=A0=A0 tm= pp =3D (ber_len_t *) 0xffffffde01373fb8 =A0=A0=A0 __PRETTY_FUNCTION__ = =3D "slap_sl_free" #1=A0 0x00000000004d562e in backsql_entry_c= lean (op=3D0x136db10, e=3D0x42447a40) =A0=A0=A0 at search.c:2680 =A0=A0=A0 ctx =3D (void *) 0x42448df0 #2= =A0 0x00000000004d4e8f in backsql_search (op=3D0x136db10, rs=3D0x42448ca0)<= br>=A0=A0=A0 at search.c:2517 =A0=A0=A0 bi =3D (backsql_info *) 0x11de09= 0 =A0=A0=A0 dbh =3D (SQLHDBC) 0x1343bf0 =A0=A0=A0 sres =3D 0 =A0=A0=A0 user_entry =3D {e_id =3D 0, e_name =3D {b= v_len =3D 0, bv_val =3D 0x0}, =A0 e_nname =3D {bv_len =3D 0, bv_val =3D= 0x0}, e_attrs =3D 0x0, e_ocflags =3D 0, e_bv =3D { =A0=A0=A0 bv_len =3D= 0, bv_val =3D 0x0}, e_private =3D 0x0} =A0=A0=A0 base_entry =3D {e_id = =3D 2743, e_name =3D {bv_len =3D 0, bv_val =3D 0x0}, =A0 e_nname =3D {bv_len =3D 34, =A0=A0=A0 bv_val =3D 0x1380620 "dc= =3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}, =A0 e_attrs =3D 0x1212= 858, e_ocflags =3D 256, e_bv =3D {bv_len =3D 0, bv_val =3D 0x0}, =A0 e_= private =3D 0x0} =A0=A0=A0 manageDSAit =3D 0 =A0=A0=A0 stoptime =3D 1288647212 =A0=A0=A0 bsi =3D {bsi_op =3D 0x136db1= 0, bsi_rs =3D 0x42448ca0, bsi_flags =3D 1, =A0 bsi_base_ndn =3D 0x136db= 48, bsi_use_subtree_shortcut =3D 0, bsi_base_id =3D { =A0=A0=A0 eid_id = =3D 2743, eid_keyval =3D 2743, eid_oc_id =3D 1, eid_oc =3D 0x13693b0, =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}, =A0=A0=A0 eid_next =3D 0x0}, bsi_scope =3D 0, b= si_filter =3D 0x1373e98, =A0 bsi_stoptime =3D 1288647212, bsi_id_list = =3D 0x42447938, =A0 bsi_id_listtail =3D 0x42447978, bsi_c_eid =3D 0x424= 47938, bsi_n_candidates =3D -2, =A0 bsi_status =3D 0, bsi_oc =3D 0x13693b0, bsi_sel =3D {bb_val =3D {bv_len= =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_from =3D {b= b_val =3D {bv_len =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}= , bsi_join_where =3D {bb_val =3D {bv_len =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_flt_where =3D {bb_val = =3D {bv_len =3D 0, =A0=A0=A0=A0=A0 bv_val =3D 0x0}, bb_len =3D 0}, bsi_= filter_oc =3D 0x0, bsi_dbh =3D 0x1343bf0, =A0 bsi_attrs =3D 0x0, bsi_e = =3D 0x0} =A0=A0=A0 eid =3D (backsql_entryID *) 0x0 =A0=A0=A0 nbase =3D {bv_len =3D 0, bv_val =3D 0x0} =A0=A0=A0 lastid =3D = 0 #3=A0 0x0000000000429f5c in fe_op_search (op=3D0x136db10, rs=3D0x42448= ca0) =A0=A0=A0 at search.c:366 =A0=A0=A0 bd =3D (BackendDB *) 0x7c28a= 0 #4=A0 0x00000000004298c7 in do_search (op=3D0x136db10, rs=3D0x42448ca0= ) =A0=A0=A0 at search.c:217 =A0=A0=A0 base =3D {bv_len =3D 34, =A0 bv_= val =3D 0x136d867 "dc=3Dtec-digital,dc=3Ditcr,dc=3Dac,dc=3Dcr"}<b= r>=A0=A0=A0 siz =3D 0 =A0=A0=A0 off =3D 0 =A0=A0=A0 i =3D 0 #5=A0 = 0x0000000000426952 in connection_operation (ctx=3D0x42448df0, =A0=A0=A0 arg_v=3D0x136db10) at connection.c:1109 =A0=A0=A0 rc =3D 80<br= >=A0=A0=A0 cancel =3D 32620 =A0=A0=A0 op =3D (Operation *) 0x136db10 = =A0=A0=A0 rs =3D {sr_type =3D REP_RESULT, sr_tag =3D 101, sr_msgid =3D 3, s= r_err =3D 0, =A0 sr_matched =3D 0x0, sr_text =3D 0x0, sr_ref =3D 0x0, s= r_ctrls =3D 0x0, sr_un =3D { =A0=A0=A0 sru_search =3D {r_entry =3D 0x0, r_attr_flags =3D 0, r_operationa= l_attrs =3D 0x0, =A0=A0=A0=A0=A0 r_attrs =3D 0x0, r_nentries =3D 1, r_v= 2ref =3D 0x0}, sru_sasl =3D { =A0=A0=A0=A0=A0 r_sasldata =3D 0x0}, sru_e= xtended =3D {r_rspoid =3D 0x0, r_rspdata =3D 0x0}}, =A0 sr_flags =3D 0} =A0=A0=A0 tag =3D 99 =A0=A0=A0 opidx =3D SLAP_OP_= SEARCH =A0=A0=A0 conn =3D (Connection *) 0x7f6cca0568d0 =A0=A0=A0 mem= ctx =3D (void *) 0x1367120 =A0=A0=A0 memctx_null =3D (void *) 0x0 =A0= =A0=A0 memsiz =3D 1048576 =A0=A0=A0 __PRETTY_FUNCTION__ =3D "connec= tion_operation" #6=A0 0x0000000000426ede in connection_read_thread (ctx=3D0x42448df0, argv= =3D0x9) =A0=A0=A0 at connection.c:1245 =A0=A0=A0 rc =3D 0 =A0=A0= =A0 cri =3D {op =3D 0x136db10, func =3D 0, arg =3D 0x0, ctx =3D 0x42448df0,= =A0 nullop =3D 0} =A0=A0=A0 s =3D 9 #7=A0 0x000000000050e33b in ldap_int_thread_pool_wrapper (xpool=3D0x11baea0= ) =A0=A0=A0 at tpool.c:685 =A0=A0=A0 pool =3D (struct ldap_int_thread= _pool_s *) 0x11baea0 =A0=A0=A0 task =3D (ldap_int_thread_task_t *) 0x136= d610 =A0=A0=A0 work_list =3D (ldap_int_tpool_plist_t *) 0x11baf38 =A0=A0=A0 ctx =3D {ltu_id =3D 1111791952, ltu_key =3D {{ltk_key =3D 0x4264a= b, =A0=A0=A0=A0=A0 ltk_data =3D 0x136df60, ltk_free =3D 0x4262fb <co= nn_counter_destroy>}, { =A0=A0=A0=A0=A0 ltk_key =3D 0x490802, ltk_dat= a =3D 0x1367120, =A0=A0=A0=A0=A0 ltk_free =3D 0x4905fc <slap_sl_mem_= destroy>}, {ltk_key =3D 0x440888, =A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0x4407e4 <slap_op_q_destr= oy>}, { =A0=A0=A0=A0=A0 ltk_key =3D 0x806ca0, ltk_data =3D 0x1343bf0,= =A0=A0=A0=A0=A0 ltk_free =3D 0x4d6aea <backsql_db_conn_keyfree>}= , {ltk_key =3D 0x0, =A0=A0=A0=A0=A0 ltk_data =3D 0x0, ltk_free =3D 0} &= lt;repeats 28 times>}} =A0=A0=A0 kctx =3D (ldap_int_thread_userctx_t *) 0x0 =A0=A0=A0 i =3D 32<= br>=A0=A0=A0 keyslot =3D 431 =A0=A0=A0 hash =3D 2036986287 =A0=A0=A0 = __PRETTY_FUNCTION__ =3D "ldap_int_thread_pool_wrapper" #8=A0 0= x00007f6cc963efc7 in start_thread () from /lib/libpthread.so.0 No symbol table info available. #9=A0 0x00007f6cc93b464d in clone () fro= m /lib/libc.so.6 No symbol table info available. #10 0x00000000000000= 00 in ?? () No symbol table info available. (gdb) -- Andr=E9s Marenco Z=FA=F1iga Equipo de Desarrollo TEC_Digital --20cf3054961990a416049404fd5f--

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs November 2010