openldap-bugs

openldap-bugs@openldap.org

1 participants
20969 discussions

Re: (ITS#7170) back-mdb indexing generation failure
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On Friday, February 17, 2012 3:14 AM +0000 quanah(a)OpenLDAP.org wrote: > Full_Name: Quanah Gibson-Mount > Version: 2.4.29 > OS: Linux 2.6 > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (75.108.184.39) > > > If one has a back-mdb database, some searches on the indexed attr of "cn" > fail. I do not see this issue with an identically configured back-hdb > install. In checking some other entries, it only appears to occur with the filters: "(cn=zimbra)" and "(cn=config)" All other cn=xxxx values I tested work correctly. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7166) MDB segfault
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On Friday, February 17, 2012 1:52 AM +0000 hyc(a)symas.com wrote: > tomasz.rutkowski(a)tombas.pl wrote: >> --=-KyDwFvnw0ca1u3hWxz7q >> Content-Type: text/plain; charset="UTF-8" >> Content-Transfer-Encoding: quoted-printable >> >> Dnia 2012-02-15, =C5=9Bro o godzinie 10:11 -0800, Quanah Gibson-Mount >> pisze= : >>> --On Wednesday, February 15, 2012 1:00 PM +0000 >>> tomasz.rutkowski(a)tombas.p= >> l=20 >>> wrote: >>> =20 >>>> Full_Name: Tomasz Rutkowski >>>> Version: 2.4.28, 2.4.29 >>>> OS: PLD Linux (Th) x86_64 >>>> URL: >>>> Submission from: (NULL) (91.216.16.90) >>>> >>>> >>>> back_mdb crashes when it's accessed through back_relay >>>> (rwm-suffixmassa= >> ge >>>> rewrite) for authentication, works normal for search/write however. >>> =20 >>> =20 >>> Please provide a full backtrace from gdb, with debugging symbols. >>> =20 > > In addition, please provide the config of your mdb database as well. > There's more modules involved here than just rwm, relay, and mdb and the > entire combination is relevant. Also, have you verified that the same > combination using back-bdb/hdb works correctly? > > This looks more like an rwm bug to me than a backend bug. Could be related to <http://www.openldap.org/its/index.cgi/?findid=5941> and <http://www.openldap.org/its/index.cgi/?findid=6166> --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7170) back-mdb indexing generation failure
by quanah＠OpenLDAP.org 16 Feb '12

16 Feb '12

Full_Name: Quanah Gibson-Mount Version: 2.4.29 OS: Linux 2.6 URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (75.108.184.39) If one has a back-mdb database, some searches on the indexed attr of "cn" fail. I do not see this issue with an identically configured back-hdb install. cn is explicitly indexed in my db: olcDbIndex: cn pres,eq,sub This works: zimbra@zre-ldap002:~$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "cn=config,cn=zimbra" -s base createTimeStamp cn dn: cn=config,cn=zimbra cn: config createTimestamp: 20120217022019Z However, the following searches all fail: ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "cn=zimbra" -s sub cn=config cn ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "" -s sub cn=config cn ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra cn=config ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra cn=zimbra ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra "(cn=zimbra)" However, the following searches work: ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra "(cn=zre-ldap003.eng.vmware.com)" cn dn: cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra cn: zre-ldap003.eng.vmware.com zimbra@zre-ldap002:~/data/ldap/config/cn=config$ ldapsearch -LLL -x -H ldapi:/// -D cn=config -w zimbra -b "cn=zimbra" "(cn=zre-ldap003.eng.vmware.com)" cn dn: cn=zre-ldap003.eng.vmware.com,cn=servers,cn=zimbra cn: zre-ldap003.eng.vmware.com Running "slapindex" does not fix the issue. --Quanah

1 0

Re: (ITS#7166) MDB segfault
by hyc＠symas.com 16 Feb '12

16 Feb '12

tomasz.rutkowski(a)tombas.pl wrote: > --=-KyDwFvnw0ca1u3hWxz7q > Content-Type: text/plain; charset="UTF-8" > Content-Transfer-Encoding: quoted-printable > > Dnia 2012-02-15, =C5=9Bro o godzinie 10:11 -0800, Quanah Gibson-Mount pisze= > : >> --On Wednesday, February 15, 2012 1:00 PM +0000 tomasz.rutkowski(a)tombas.p= > l=20 >> wrote: >> =20 >>> Full_Name: Tomasz Rutkowski >>> Version: 2.4.28, 2.4.29 >>> OS: PLD Linux (Th) x86_64 >>> URL: >>> Submission from: (NULL) (91.216.16.90) >>> >>> >>> back_mdb crashes when it's accessed through back_relay (rwm-suffixmassa= > ge >>> rewrite) for authentication, works normal for search/write however. >> =20 >> =20 >> Please provide a full backtrace from gdb, with debugging symbols. >> =20 In addition, please provide the config of your mdb database as well. There's more modules involved here than just rwm, relay, and mdb and the entire combination is relevant. Also, have you verified that the same combination using back-bdb/hdb works correctly? This looks more like an rwm bug to me than a backend bug. -- -- 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#7166) MDB segfault
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On Thursday, February 16, 2012 1:03 PM +0100 Tomasz Rutkowski <tomasz.rutkowski(a)tombas.pl> wrote: > Dnia 2012-02-15, śro o godzinie 10:11 -0800, Quanah Gibson-Mount pisze: >> --On Wednesday, February 15, 2012 1:00 PM +0000 >> tomasz.rutkowski(a)tombas.pl wrote: >> >> > Full_Name: Tomasz Rutkowski >> > Version: 2.4.28, 2.4.29 >> > OS: PLD Linux (Th) x86_64 >> > URL: >> > Submission from: (NULL) (91.216.16.90) >> > >> > >> > back_mdb crashes when it's accessed through back_relay >> > (rwm-suffixmassage rewrite) for authentication, works normal for >> > search/write however. >> >> >> Please provide a full backtrace from gdb, with debugging symbols. Unfortunately, you optimized your build, which makes backtraces fairly useless. Please rebuild with CFLAGS="-O0 -g" and obtain a new backtrace. Thanks! --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

Re: (ITS#7167) regression, ldap_result() returns -1
by hyc＠symas.com 16 Feb '12

16 Feb '12

jvcelak(a)redhat.com wrote: > Here is what I have tried. This is the processing of the failing ldap_result(): > > (gdb) c > Continuing. > > Breakpoint 3, ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1005 > 1005 sip = (struct selectinfo *)ld->ld_selectinfo; > (gdb) n > 1007 if (ber_sockbuf_ctrl( sb, LBER_SB_OPT_DATA_READY, NULL )) > (gdb) > 1010 ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD,&sd ); > (gdb) > 1016 for(i=0; i< sip->si_maxfd; i++) { > (gdb) > 1017 if( sip->si_fds[i].fd == sd ) { > (gdb) > 1018 return sip->si_fds[i].revents& POLL_READ; > (gdb) p sip->si_fds[0].revents > $14 = 4 > (gdb) bt full > #0 ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1018 > i = 0 > sip = 0x7f48f3a2f590 > sd = 17 > #1 0x00007f48f17ab743 in wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:357 > lnext = 0x0 > serviced = 0 > lc_ready = 1 > rc = -2 > tv = {tv_sec = 0, tv_usec = 0} > tv0 = {tv_sec = 0, tv_usec = 0} > start_time_tv = {tv_sec = 1329407008, tv_usec = 270973} > tvp = 0x7fff16e75c70 > lc = 0x7f48f3a2db80 > __PRETTY_FUNCTION__ = "wait4msg" > #2 0x00007f48f17aaf0e in ldap_result (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:117 > rc = 32584 > __PRETTY_FUNCTION__ = "ldap_result" > #3 0x00007f48e6da897e in sdap_process_result (ev=0x7f48f39f94d0, pvt=0x7f48f3a38b70) at src/providers/ldap/sdap_async.c:179 > sh = 0x7f48f3a38b70 > no_timeout = {tv_sec = 0, tv_usec = 0} > te = 0x7f48f3a2cab0 > msg = 0x0 > ret = 101 > __FUNCTION__ = "sdap_process_result" > #4 0x00007f48e6da8594 in sdap_ldap_next_result (ev=0x7f48f39f94d0, te=0x7f48f3a2cab0, tv=..., pvt=0x7f48f3a38b70) > at src/providers/ldap/sdap_async.c:159 > No locals. > #5 0x00007f48f2f19310 in tevent_common_loop_timer_delay (ev=ev@entry=0x7f48f39f94d0) at ../tevent_timed.c:254 > current_time = {tv_sec = 0, tv_usec = 0} > te = 0x7f48f3a2cab0 > #6 0x00007f48f2f189ec in std_event_loop_once (ev=0x7f48f39f94d0, location=<optimized out>) at ../tevent_standard.c:558 > std_ev = 0x7f48f39f9590 > tval = {tv_sec = 0, tv_usec = 0} > #7 0x00007f48f2f15cb0 in _tevent_loop_once (ev=ev@entry=0x7f48f39f94d0, > location=location@entry=0x7f48f37e52e7 "src/util/server.c:572") at ../tevent.c:504 > ret =<optimized out> > nesting_stack_ptr = 0x0 > #8 0x00007f48f2f15e3b in tevent_common_loop_wait (ev=0x7f48f39f94d0, location=0x7f48f37e52e7 "src/util/server.c:572") > at ../tevent.c:605 > ret =<optimized out> > #9 0x00007f48f37b8a85 in server_loop (main_ctx=0x7f48f39fa640) at src/util/server.c:572 > No locals. > #10 0x00007f48f3779a88 in main (argc=5, argv=0x7fff16e763a8) at src/providers/data_provider_be.c:2003 > opt = -1 > pc = 0x7f48f39f8010 > be_domain = 0x7f48f39f8420 "foo" > srv_name = 0x7f48f39f80d0 "sssd[be[foo]]" > main_ctx = 0x7f48f39fa640 > confdb_path = 0x7f48f39f8140 "config/domain/foo" > ret = 0 > long_options = {{longName = 0x0, shortName = 0 '\000', argInfo = 4, arg = 0x7f48f2d06200, val = 0, > descrip = 0x7f48f37dcb7c "Help options:", argDescrip = 0x0}, {longName = 0x7f48f37dcb8a "debug-level", > shortName = 100 'd', argInfo = 2, arg = 0x7f48f39f4738, val = 0, descrip = 0x7f48f37dcb96 "Debug level", > argDescrip = 0x0}, {longName = 0x7f48f37dcba2 "debug-to-files", shortName = 102 'f', argInfo = 0, arg = 0x7f48f39f473c, > val = 0, descrip = 0x7f48f37dcbb8 "Send the debug output to files instead of stderr", argDescrip = 0x0}, { > longName = 0x7f48f37dcbe9 "debug-timestamps", shortName = 0 '\000', argInfo = 2, arg = 0x7f48f39f4598, val = 0, > descrip = 0x7f48f37dcbfa "Add debug timestamps", argDescrip = 0x0}, {longName = 0x7f48f37dcc0f "debug-microseconds", > shortName = 0 '\000', argInfo = 2, arg = 0x7f48f39f459c, val = 0, > descrip = 0x7f48f37dcc28 "Show timestamps with microseconds", argDescrip = 0x0}, {longName = 0x7f48f37dcc4a "domain", > shortName = 0 '\000', argInfo = 1, arg = 0x7fff16e76058, val = 0, > descrip = 0x7f48f37dcc58 "Domain of the information provider (mandatory)", argDescrip = 0x0}, {longName = 0x0, > shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}} > __FUNCTION__ = "main" > (gdb) fin > Run till exit from #0 ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1028 > wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:356 > 356 if ( lc->lconn_status == LDAP_CONNST_CONNECTED&& > Value returned is $15 = 0 > (gdb) c > Continuing. > > Breakpoint 2, wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) > at ../../../libraries/libldap/result.c:378 > 378 rc = -1; > > As you may see, there is only a POLLOUT flag set: > >> (gdb) p sip->si_fds[0].revents >> $14 = 4 > > /usr/include/bits/poll.h: >> #define POLLOUT 0x004 /* Writing now will not block. */ > > So I believe, that there is some other problem, because lc_ready is 1. And > without the reverted patch, the operation would just keep looping with > LDAP_MSG_X_KEEP_LOOKING. (Or will timeout alternatively.) Your debug session indicates that the socket is writable but libldap doesn't have any record of being blocked for any writes, so it doesn't check for writable state. Frankly this sounds more like an sssd bug, since libldap is still working fine for just about everything else out there. Perhaps you should set libldap's debug level to 7 and see what actually got handled in the library up to the point of failure. -- -- 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#7169) When using protocol address, port parameter is ignored on connect
by h.b.furuseth＠usit.uio.no 16 Feb '12

16 Feb '12

To clarify a bit: When you use ldap_connect(URI, port), php ignores the port parameter and uses ldap_initialize() - which does not take a port parameter. Maybe php should refuse to accept a port parameter to in this case. OTOH ldap_connect(host, port) calls ldap_init(host, port), where port is used unless the host paramter has the form "host:actual port". -- Hallvard

1 0

Re: (ITS#7169) When using protocol address, port parameter is ignored on connect
by quanah＠zimbra.com 16 Feb '12

16 Feb '12

--On Thursday, February 16, 2012 5:02 PM +0000 marcel.esser(a)gmail.com wrote: > Full_Name: Marcel Esser > Version: 2.4 > OS: Ubuntu Lucid > URL: http://pastebin.com/TzNGmUCL > Submission from: (NULL) (98.169.136.204) > > > When passing a protocol address (i.e. "ldap://127.0.0.1" instead of a > plain hostname/IP address, i.e. "127.0.0.1" to libldap, connect seems to > ignore the port number parameter and always use 389/636 instead. > > Issue with libldap 2.4 on Ubuntu Lucid. Note that in the example below, > the PHP wrapper for libldap passes the strings on to the library > unmodified. Detail system information is at the bottom. Linked against > /usr/lib/libldap-2.4.so.2 I don't see a bug here. You are using two different methods: 1) The first method is using a URI. A URI includes the port, or defaults to 389/636, depending on the URI protocol. For example, ldap://127.0.0.1 is treated as ldap://127.0.0.1:389. If you want to use a URI with a different port, then include the port as part of the URI. 2) The second method is composed of a hostname/IP address, and a port. Since it is not a URI, these two separate pieces are required to be passed in. Essentially, if you are going to use a URI, then use it correctly and pass in the port as a part of the URI string. Passing in a URI with a separate port parameter that is not part of the URI is not valid. --Quanah -- Quanah Gibson-Mount Sr. Member of Technical Staff Zimbra, Inc A Division of VMware, Inc. -------------------- Zimbra :: the leader in open source messaging and collaboration

1 0

(ITS#7169) When using protocol address, port parameter is ignored on connect
by marcel.esser＠gmail.com 16 Feb '12

16 Feb '12

Full_Name: Marcel Esser Version: 2.4 OS: Ubuntu Lucid URL: http://pastebin.com/TzNGmUCL Submission from: (NULL) (98.169.136.204) When passing a protocol address (i.e. "ldap://127.0.0.1" instead of a plain hostname/IP address, i.e. "127.0.0.1" to libldap, connect seems to ignore the port number parameter and always use 389/636 instead. Issue with libldap 2.4 on Ubuntu Lucid. Note that in the example below, the PHP wrapper for libldap passes the strings on to the library unmodified. Detail system information is at the bottom. Linked against /usr/lib/libldap-2.4.so.2 Use case illustrated in attached URL.

1 0

Re: (ITS#7167) regression, ldap_result() returns -1
by jvcelak＠redhat.com 16 Feb '12

16 Feb '12

Here is what I have tried. This is the processing of the failing ldap_result(): (gdb) c Continuing. Breakpoint 3, ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1005 1005 sip = (struct selectinfo *)ld->ld_selectinfo; (gdb) n 1007 if (ber_sockbuf_ctrl( sb, LBER_SB_OPT_DATA_READY, NULL )) (gdb) 1010 ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD, &sd ); (gdb) 1016 for(i=0; i < sip->si_maxfd; i++) { (gdb) 1017 if( sip->si_fds[i].fd == sd ) { (gdb) 1018 return sip->si_fds[i].revents & POLL_READ; (gdb) p sip->si_fds[0].revents $14 = 4 (gdb) bt full #0 ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1018 i = 0 sip = 0x7f48f3a2f590 sd = 17 #1 0x00007f48f17ab743 in wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) at ../../../libraries/libldap/result.c:357 lnext = 0x0 serviced = 0 lc_ready = 1 rc = -2 tv = {tv_sec = 0, tv_usec = 0} tv0 = {tv_sec = 0, tv_usec = 0} start_time_tv = {tv_sec = 1329407008, tv_usec = 270973} tvp = 0x7fff16e75c70 lc = 0x7f48f3a2db80 __PRETTY_FUNCTION__ = "wait4msg" #2 0x00007f48f17aaf0e in ldap_result (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) at ../../../libraries/libldap/result.c:117 rc = 32584 __PRETTY_FUNCTION__ = "ldap_result" #3 0x00007f48e6da897e in sdap_process_result (ev=0x7f48f39f94d0, pvt=0x7f48f3a38b70) at src/providers/ldap/sdap_async.c:179 sh = 0x7f48f3a38b70 no_timeout = {tv_sec = 0, tv_usec = 0} te = 0x7f48f3a2cab0 msg = 0x0 ret = 101 __FUNCTION__ = "sdap_process_result" #4 0x00007f48e6da8594 in sdap_ldap_next_result (ev=0x7f48f39f94d0, te=0x7f48f3a2cab0, tv=..., pvt=0x7f48f3a38b70) at src/providers/ldap/sdap_async.c:159 No locals. #5 0x00007f48f2f19310 in tevent_common_loop_timer_delay (ev=ev@entry=0x7f48f39f94d0) at ../tevent_timed.c:254 current_time = {tv_sec = 0, tv_usec = 0} te = 0x7f48f3a2cab0 #6 0x00007f48f2f189ec in std_event_loop_once (ev=0x7f48f39f94d0, location=<optimized out>) at ../tevent_standard.c:558 std_ev = 0x7f48f39f9590 tval = {tv_sec = 0, tv_usec = 0} #7 0x00007f48f2f15cb0 in _tevent_loop_once (ev=ev@entry=0x7f48f39f94d0, location=location@entry=0x7f48f37e52e7 "src/util/server.c:572") at ../tevent.c:504 ret = <optimized out> nesting_stack_ptr = 0x0 #8 0x00007f48f2f15e3b in tevent_common_loop_wait (ev=0x7f48f39f94d0, location=0x7f48f37e52e7 "src/util/server.c:572") at ../tevent.c:605 ret = <optimized out> #9 0x00007f48f37b8a85 in server_loop (main_ctx=0x7f48f39fa640) at src/util/server.c:572 No locals. #10 0x00007f48f3779a88 in main (argc=5, argv=0x7fff16e763a8) at src/providers/data_provider_be.c:2003 opt = -1 pc = 0x7f48f39f8010 be_domain = 0x7f48f39f8420 "foo" srv_name = 0x7f48f39f80d0 "sssd[be[foo]]" main_ctx = 0x7f48f39fa640 confdb_path = 0x7f48f39f8140 "config/domain/foo" ret = 0 long_options = {{longName = 0x0, shortName = 0 '\000', argInfo = 4, arg = 0x7f48f2d06200, val = 0, descrip = 0x7f48f37dcb7c "Help options:", argDescrip = 0x0}, {longName = 0x7f48f37dcb8a "debug-level", shortName = 100 'd', argInfo = 2, arg = 0x7f48f39f4738, val = 0, descrip = 0x7f48f37dcb96 "Debug level", argDescrip = 0x0}, {longName = 0x7f48f37dcba2 "debug-to-files", shortName = 102 'f', argInfo = 0, arg = 0x7f48f39f473c, val = 0, descrip = 0x7f48f37dcbb8 "Send the debug output to files instead of stderr", argDescrip = 0x0}, { longName = 0x7f48f37dcbe9 "debug-timestamps", shortName = 0 '\000', argInfo = 2, arg = 0x7f48f39f4598, val = 0, descrip = 0x7f48f37dcbfa "Add debug timestamps", argDescrip = 0x0}, {longName = 0x7f48f37dcc0f "debug-microseconds", shortName = 0 '\000', argInfo = 2, arg = 0x7f48f39f459c, val = 0, descrip = 0x7f48f37dcc28 "Show timestamps with microseconds", argDescrip = 0x0}, {longName = 0x7f48f37dcc4a "domain", shortName = 0 '\000', argInfo = 1, arg = 0x7fff16e76058, val = 0, descrip = 0x7f48f37dcc58 "Domain of the information provider (mandatory)", argDescrip = 0x0}, {longName = 0x0, shortName = 0 '\000', argInfo = 0, arg = 0x0, val = 0, descrip = 0x0, argDescrip = 0x0}} __FUNCTION__ = "main" (gdb) fin Run till exit from #0 ldap_is_read_ready (ld=0x7f48f3a170a0, sb=0x7f48f3a22580) at ../../../libraries/libldap/os-ip.c:1028 wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) at ../../../libraries/libldap/result.c:356 356 if ( lc->lconn_status == LDAP_CONNST_CONNECTED && Value returned is $15 = 0 (gdb) c Continuing. Breakpoint 2, wait4msg (ld=0x7f48f3a170a0, msgid=-1, all=0, timeout=0x7fff16e75da0, result=0x7fff16e75d60) at ../../../libraries/libldap/result.c:378 378 rc = -1; As you may see, there is only a POLLOUT flag set: > (gdb) p sip->si_fds[0].revents > $14 = 4 /usr/include/bits/poll.h: > #define POLLOUT 0x004 /* Writing now will not block. */ So I believe, that there is some other problem, because lc_ready is 1. And without the reverted patch, the operation would just keep looping with LDAP_MSG_X_KEEP_LOOKING. (Or will timeout alternatively.)

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openldap-bugs