openldap-bugs December 2007

openldap-bugs@openldap.org

45 participants
166 discussions

Start a nNew thread

Re: (ITS#5248) non-atomic signal variables
by h.b.furuseth＠usit.uio.no 06 Dec '07

06 Dec '07

Fixed the easy cases in HEAD. WAKE_LISTENER under --without-threads remains. -- Hallvard

1 0

Re: (ITS#5261) Samba4 can 'hang' OpenLDAP slapd
by hyc＠symas.com 06 Dec '07

06 Dec '07

This stack trace looks a little funny, but I think this should be fixed now in HEAD. Andrew Bartlett wrote: > Loaded symbols for /usr/lib64/sasl2/libsasldb.so.2 > 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > (gdb) thread apply all bt > > Thread 6 (Thread 1082132816 (LWP 26448)): > #0 0x00000035236d50d8 in epoll_wait () from /lib64/libc.so.6 > #1 0x000000000042af5a in ?? () > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 5 (Thread 1090525520 (LWP 26453)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:582 > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 4 (Thread 1098918224 (LWP 26455)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x000000353ac28a2d in __db_pthread_mutex_lock () > from /lib64/libdb-4.6.so > #2 0x000000353ac2866f in __db_tas_mutex_lock () > from /lib64/libdb-4.6.so > #3 0x000000353ac9136d in __lock_get_internal () > from /lib64/libdb-4.6.so > #4 0x000000353ac9193e in __lock_vec () from /lib64/libdb-4.6.so > #5 0x000000353ac9241b in __lock_vec_pp () from /lib64/libdb-4.6.so > #6 0x00000000004c545f in hdb_cache_entry_db_relock () > #7 0x00000000004c5c00 in hdb_cache_modify () > #8 0x00000000004a03bd in hdb_modify () > #9 0x0000000000500036 in ?? () > #10 0x0000000000500382 in ?? () > #11 0x000000000043bd15 in ?? () > #12 0x000000000043e52f in ?? () > #13 0x000000000043f158 in slap_send_ldap_result () > #14 0x00000000004c314d in hdb_add () > #15 0x00000000004888d2 in overlay_op_walk () > #16 0x0000000000488dd5 in ?? () > #17 0x00000000004343d7 in fe_op_add () > #18 0x0000000000434bdc in do_add () > #19 0x000000000042dd86 in ?? () > #20 0x000000000042e21d in ?? () > #21 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:625 > ---Type <return> to continue, or q <return> to quit--- > #22 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #23 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 3 (Thread 1107310928 (LWP 26456)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x00002aaaaaabd300 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:582 > #2 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #3 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 2 (Thread 1115703632 (LWP 26457)): > #0 0x000000352420a8f9 in pthread_cond_wait@@GLIBC_2.3.2 () > from /lib64/libpthread.so.0 > #1 0x000000353ac28a2d in __db_pthread_mutex_lock () > from /lib64/libdb-4.6.so > #2 0x000000353ac2866f in __db_tas_mutex_lock () > from /lib64/libdb-4.6.so > #3 0x000000353ac9136d in __lock_get_internal () > from /lib64/libdb-4.6.so > #4 0x000000353ac916fa in __lock_get_pp () from /lib64/libdb-4.6.so > #5 0x00000000004c52c4 in ?? () > #6 0x00000000004c6a89 in hdb_cache_find_id () > #7 0x00000000004c9f99 in hdb_dn2entry () > #8 0x00000000004a3cd0 in hdb_referrals () > #9 0x00000000004888d2 in overlay_op_walk () > #10 0x0000000000488dd5 in ?? () > #11 0x0000000000438f90 in backend_check_referrals () > #12 0x000000000043427b in fe_op_add () > #13 0x0000000000434bdc in do_add () > #14 0x000000000042dd86 in ?? () > #15 0x000000000042e21d in ?? () > #16 0x00002aaaaaabd2a7 in ldap_int_thread_pool_wrapper (xpool=0x844530) > at tpool.c:625 > #17 0x0000003524206407 in start_thread () from /lib64/libpthread.so.0 > #18 0x00000035236d4b0d in clone () from /lib64/libc.so.6 > > Thread 1 (Thread 46912500832560 (LWP 26443)): > #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > #1 0x0000000000428ca2 in slapd_daemon () > #2 0x0000000000418519 in main () > #0 0x00000035242076dd in pthread_join () from /lib64/libpthread.so.0 > (gdb) > > -- -- Howard Chu Chief Architect, 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#5258) memberof-Overlay issue when deleting all values of the "memberof-member-ad" attribute
by ando＠sys-net.it 05 Dec '07

05 Dec '07

rhafer(a)suse.de wrote: Found it. A fix will follow, perhaps not too shortly. p. Ing. Pierangelo Masarati OpenLDAP Core Team SysNet s.r.l. via Dossi, 8 - 27100 Pavia - ITALIA http://www.sys-net.it --------------------------------------- Office: +39 02 23998309 Mobile: +39 333 4963172 Email: pierangelo.masarati(a)sys-net.it ---------------------------------------

1 0

Re: (ITS#5262) test008 failures
by hyc＠symas.com 05 Dec '07

05 Dec '07

hyc(a)symas.com wrote: > hyc(a)OpenLDAP.org wrote: >> hyc(a)OpenLDAP.org wrote: >>> Full_Name: Howard Chu >>> Version: HEAD/RE24/RE23 >>> OS: Linux > I take this back; it wasn't recompiled yet. The current code in HEAD has > passed over 100 iterations. I'll leave it running overnight. This is now fixed in HEAD/RE24. I suppose it ought to be fixed in RE23 as well if we're going to do another 2.3 release. -- -- Howard Chu Chief Architect, 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#5231) test045 failure in HEAD/RE24
by hyc＠OpenLDAP.org 05 Dec '07

05 Dec '07

hyc(a)OpenLDAP.org wrote: > Full_Name: Howard Chu > Version: HEAD/RE24 > The comparison fails after the first modify step, an entry that should have been > deleted is still present on the slave. > > The presentlist is still left over from the initial query, and hasn't been > emptied yet. This appears to be a missing step when the initial query > transitions from Refresh to Persist mode. This broke after patching ITS#5210. That means the corresponding fix needs to go into RE23 as well, and any syncrepl.c without this patch will not work with newer syncprov. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

(ITS#5264) invalid printf of NULL
by richton＠nbcs.rutgers.edu 05 Dec '07

05 Dec '07

Full_Name: Aaron Richton Version: HEAD OS: Solaris 9 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (128.6.31.137) [5] slap_sasl_match(opx = 0x100a32c10, rule = 0x100a363e0, assertDN = 0x7fffffff7927c6c0, authc = 0x7fffffff7927c6c0), line 1668 in "saslauthz.c" 1660 struct berval base = BER_BVNULL; 1661 1662 sm.dn = assertDN; 1663 sm.match = 0; 1664 cb.sc_private = &sm; 1665 1666 Debug( LDAP_DEBUG_TRACE, 1667 "===>slap_sasl_match: comparing DN %s to rule %s\n", 1668 assertDN->bv_val, rule->bv_val, 0 ); 1669 1670 /* NOTE: don't normalize rule if authz syntax is enabled */ (dbx) print assertDN->bv_val assertDN->bv_val = (nil) don't do that...

1 0

Re: (ITS#5161) delta-syncrepl mutex lockup
by quanah＠zimbra.com 05 Dec '07

05 Dec '07

Just to note, Howard tracked this down to the overlay not handling abandonding clients. i.e., I can trigger this behavior repeatably by issuing 3 async deletes to the master and then unbinding without waiting for the results of the deletes. Sync deletes obviously do not trigger this. --Quanah -- Quanah Gibson-Mount Principal Software Engineer Zimbra, Inc -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#5263) ldap_parse_sasl_bind_result() returning wrong error code
by rhafer＠suse.de 05 Dec '07

05 Dec '07

Full_Name: Ralf Haferkamp Version: HEAD, RE23, RE24 OS: - URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (89.166.205.58) According to the man-pages and the C-API draft the ldap_parse_*_result() functions return LDAP_SUCCESS, when the result was successfully parsed, otherwise != LDAP_SUCCESS. The current implementation of ldap_parse_sasl_bind_result() (not sure about ldap_parse_extended_result()) however will return the LDAP Error Code of the passwd LDAPMessages as the result (e.g. LDAP_SASL_BIND_IN_PROGRESS). If this is the desired behavior we should fix our documentation. But I guess this is a bug in ldap_parse_sasl_bind_result() and probably ldap_parse_extended_result().

1 0

Authentication data not used when chasing referrals (ITS#2106)
by my-tien.sadler＠hp.com 05 Dec '07

05 Dec '07

--_000_C8088FB9610ACD4FBC6260588B10E56251184D83G6W0269americas_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Do you know if this is now fixed? Per link http://www.openldap.org/lists/openldap-bugs/200209/msg00088.html Presently, all OpenLDAP clients only support anonymous chasing. The -C option was purposely removed from the usage message of all LDAP commands but mistaken left in some manual pages. These have been corrected in HEAD. If and when non-anonymous chasing is implemented, the usage and manual pages will be updated to reflect this. Implementation of non-anonymous chasing is on the TODO list. Kurt Thanks much for your time, My-Tien Sadler --_000_C8088FB9610ACD4FBC6260588B10E56251184D83G6W0269americas_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> <HTML><HEAD> <META http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii"> <META content=3D"MSHTML 6.00.6000.16544" name=3DGENERATOR></HEAD> <BODY> <DIV><FONT face=3DArial size=3D2><SPAN class=3D625072214-05122007>Do you kn= ow if this=20 is now fixed?</SPAN></FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D625072214-05122007></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN class=3D625072214-05122007>Per link = <A=20 href=3D"http://www.openldap.org/lists/openldap-bugs/200209/msg00088.html">h= ttp://www.openldap.org/lists/openldap-bugs/200209/msg00088.html</A></SPAN><= /FONT></DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D625072214-05122007></SPAN></FONT> </DIV> <DIV><FONT face=3DArial size=3D2><SPAN=20 class=3D625072214-05122007></SPAN></FONT> </DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007>Presently, all Ope= nLDAP=20 clients only support anonymous chasing.<BR><BR>The -C option was purposely= =20 removed from the usage message of<BR>all LDAP commands but mistaken left in= some=20 manual pages.<BR>These have been corrected in HEAD.<BR><BR>If and when=20 non-anonymous chasing is implemented, the usage<BR>and manual pages will be= =20 updated to reflect this.<BR><BR>Implementation of non-anonymous chasing is = on=20 the TODO list.<BR><BR>Kurt<BR><BR>Thanks much for your time,</SPAN></FONT><= /DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007>My-Tien=20 Sadler</SPAN></FONT></DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007></SPAN></FONT>&nbs= p;</DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007><FONT=20 size=3D2></FONT></SPAN></FONT> </DIV> <DIV><FONT face=3DArial><SPAN class=3D625072214-05122007><FONT=20 size=3D2></FONT> </DIV> <DIV><BR></DIV></SPAN></FONT></BODY></HTML> --_000_C8088FB9610ACD4FBC6260588B10E56251184D83G6W0269americas_--

1 0

Re: (ITS#5262) test008 failures
by hyc＠symas.com 05 Dec '07

05 Dec '07

hyc(a)OpenLDAP.org wrote: > hyc(a)OpenLDAP.org wrote: >> Full_Name: Howard Chu >> Version: HEAD/RE24/RE23 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (76.91.220.157) >> Submitted by: hyc > >> As originally reported by Aaron Richton here >> http://www.openldap.org/lists/openldap-devel/200711/msg00097.html and further >> here >> http://www.openldap.org/lists/openldap-devel/200712/msg00026.html >> >> ITS#5257 is a secondary effect of this bug. > > The patch in HEAD seems to help; my 8-core system has now run test008 with > over 150 successful iterations. Over 200 now. > On my dual core system it still failed after > 27 iterations. Still looking at it. I take this back; it wasn't recompiled yet. The current code in HEAD has passed over 100 iterations. I'll leave it running overnight. -- -- Howard Chu Chief Architect, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/

1 0

← Newer
1
...
10
11
12
13
14
15
16
17
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs December 2007