Logged in as guest
Viewing Software Bugs/7167 Full headers
Major security issue: yes no
Notes: fix in master fixed in RE24 Notification:
Date: Wed, 15 Feb 2012 15:38:43 +0000 From: jvcelak@redhat.com To: openldap-its@OpenLDAP.org Subject: regression, ldap_result() returns -1
Full_Name: Jan Vcelak Version: 2.4.29 OS: Linux URL: ftp://ftp.openldap.org/incoming/ Submission from: (NULL) (209.132.186.34) There is a possible regression caused by 06ec9f1db2bb9dc304a4adcd0d0506203cf9e6b6. SSSD's event loop listens for events on a file descriptor retrieved using ber_sockbuf_ctrl(sb, LBER_SB_OPT_GET_FD, &ber_fd). If there are some data to be read, processing using ldap_result is triggered. (Internally, tevent from Samba project is used, which uses epoll.) But sometimes, ldap_result() returns -1 error code. It seems that the descriptor is marked as readable untimely. This problem is not present with OpenLDAP 2.4.26, it appears with all future versions. When the mentioned commit is reverted, everything works well. Original report in our Bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=771484 It was also reported in Ubuntu: https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/929888 And i similar report, hopefully with the same cause: https://bugzilla.redhat.com/show_bug.cgi?id=790414
Date: Wed, 15 Feb 2012 13:28:11 -0800 From: Howard Chu <hyc@symas.com> To: jvcelak@redhat.com CC: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
jvcelak@redhat.com wrote: > Full_Name: Jan Vcelak > Version: 2.4.29 > OS: Linux > URL: ftp://ftp.openldap.org/incoming/ > Submission from: (NULL) (209.132.186.34) > > > There is a possible regression caused by > 06ec9f1db2bb9dc304a4adcd0d0506203cf9e6b6. > > SSSD's event loop listens for events on a file descriptor retrieved using > ber_sockbuf_ctrl(sb, LBER_SB_OPT_GET_FD,&ber_fd). If there are some data to be > read, processing using ldap_result is triggered. (Internally, tevent from Samba > project is used, which uses epoll.) But sometimes, ldap_result() returns -1 > error code. It seems that the descriptor is marked as readable untimely. > > This problem is not present with OpenLDAP 2.4.26, it appears with all future > versions. When the mentioned commit is reverted, everything works well. > > Original report in our Bugzilla: > https://bugzilla.redhat.com/show_bug.cgi?id=771484 Thanks for the report and the detailed investigation, but this sounds to me like a kernel bug. We expect select/epoll/whatever to only return that a descriptor is readable if it actually is readable. (Gosh, who'dathunkit.) If not, then these syscalls are not behaving as documented/designed. > > It was also reported in Ubuntu: > https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/929888 > > And i similar report, hopefully with the same cause: > https://bugzilla.redhat.com/show_bug.cgi?id=790414 > > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Wed, 15 Feb 2012 13:30:48 -0800 From: Howard Chu <hyc@symas.com> To: jvcelak@redhat.com CC: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
Howard Chu wrote: > jvcelak@redhat.com wrote: >> Full_Name: Jan Vcelak >> Version: 2.4.29 >> OS: Linux >> URL: ftp://ftp.openldap.org/incoming/ >> Submission from: (NULL) (209.132.186.34) >> >> >> There is a possible regression caused by >> 06ec9f1db2bb9dc304a4adcd0d0506203cf9e6b6. >> >> SSSD's event loop listens for events on a file descriptor retrieved using >> ber_sockbuf_ctrl(sb, LBER_SB_OPT_GET_FD,&ber_fd). If there are some data to be >> read, processing using ldap_result is triggered. (Internally, tevent from Samba >> project is used, which uses epoll.) But sometimes, ldap_result() returns -1 >> error code. It seems that the descriptor is marked as readable untimely. >> >> This problem is not present with OpenLDAP 2.4.26, it appears with all future >> versions. When the mentioned commit is reverted, everything works well. >> >> Original report in our Bugzilla: >> https://bugzilla.redhat.com/show_bug.cgi?id=771484 > > Thanks for the report and the detailed investigation, but this sounds to me > like a kernel bug. We expect select/epoll/whatever to only return that a > descriptor is readable if it actually is readable. (Gosh, who'dathunkit.) If > not, then these syscalls are not behaving as documented/designed. By the way, the patch in question was due to ITS#7035; you should read that ITS for the motivation behind this change. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Wed, 15 Feb 2012 18:09:42 -0500 (EST) From: Jan Vcelak <jvcelak@redhat.com> To: Howard Chu <hyc@symas.com> Cc: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
----- Original Message ----- > By the way, the patch in question was due to ITS#7035; you should > read that > ITS for the motivation behind this change. Yes, I have read that ITS. I'm just not sure, if I understand it correctly. My server runs on the same machine as the SSSD client. The connection should not be closed unexpectedly. Therefore I think that POLL_HANGUP is not relevant.
Date: Wed, 15 Feb 2012 18:06:05 -0800 From: Howard Chu <hyc@symas.com> To: Jan Vcelak <jvcelak@redhat.com> CC: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
Jan Vcelak wrote: > ----- Original Message ----- >> By the way, the patch in question was due to ITS#7035; you should >> read that >> ITS for the motivation behind this change. > > Yes, I have read that ITS. I'm just not sure, if I understand it > correctly. My server runs on the same machine as the SSSD client. > The connection should not be closed unexpectedly. Therefore > I think that POLL_HANGUP is not relevant. To clarify - are all of the failures occuring when TLS is in use on the LDAP session? It's common for the socket layer to have data, but for the TLS layer to report that nothing is available yet since it hasn't read a complete record yet. If that's what is happening here, then yes, we need to fix this patch. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/
Date: Wed, 15 Feb 2012 18:28:58 -0800 From: Howard Chu <hyc@symas.com> To: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
This is a multi-part message in MIME format. --------------000007040307000306010401 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit hyc@symas.com wrote: > Jan Vcelak wrote: >> ----- Original Message ----- >>> By the way, the patch in question was due to ITS#7035; you should >>> read that >>> ITS for the motivation behind this change. >> >> Yes, I have read that ITS. I'm just not sure, if I understand it >> correctly. My server runs on the same machine as the SSSD client. >> The connection should not be closed unexpectedly. Therefore >> I think that POLL_HANGUP is not relevant. > > To clarify - are all of the failures occuring when TLS is in use on the LDAP > session? It's common for the socket layer to have data, but for the TLS layer > to report that nothing is available yet since it hasn't read a complete record > yet. If that's what is happening here, then yes, we need to fix this patch. > Please test the attached patch and see if the problem is resolved, thanks. -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------000007040307000306010401 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/libraries/libldap/result.c b/libraries/libldap/result.c index b6e8e75..7241df9 100644 --- a/libraries/libldap/result.c +++ b/libraries/libldap/result.c @@ -302,7 +302,7 @@ wait4msg( if ( ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_DATA_READY, NULL ) ) { - lc_ready = 1; + lc_ready = 2; /* ready at ber level, not socket level */ break; } } @@ -373,8 +373,8 @@ wait4msg( } } LDAP_MUTEX_UNLOCK( &ld->ld_req_mutex ); - /* Quit looping if no one handled any events */ - if (!serviced) + /* Quit looping if no one handled any socket events */ + if (!serviced && lc_ready == 1) rc = -1; } LDAP_MUTEX_UNLOCK( &ld->ld_conn_mutex ); --------------000007040307000306010401--
Date: Thu, 16 Feb 2012 05:14:42 -0500 (EST) From: Jan Vcelak <jvcelak@redhat.com> To: hyc@symas.com Cc: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
Thank you for quick responses. :-) > To clarify - are all of the failures occuring when TLS is in use on > the LDAP session? It's common for the socket layer to have data, but > for the TLS layer to report that nothing is available yet since it > hasn't read a complete record yet. If that's what is happening here, > then yes, we need to fix this patch. No, TLS is disabled in my case. > Please test the attached patch and see if the problem is resolved, > thanks. The patch didn't help. I'm still getting the error. Jan
Date: Thu, 16 Feb 2012 11:10:40 -0500 (EST) From: Jan Vcelak <jvcelak@redhat.com> To: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
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
Date: Thu, 16 Feb 2012 16:37:13 -0800 From: Howard Chu <hyc@symas.com> To: jvcelak@redhat.com CC: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
jvcelak@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
Date: Mon, 20 Feb 2012 12:57:15 -0800 From: Howard Chu <hyc@symas.com> To: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
This is a multi-part message in MIME format. --------------060206020501030606090605 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Try this instead. Howard Chu wrote: > Please test the attached patch and see if the problem is resolved, thanks. > -- -- Howard Chu CTO, Symas Corp. http://www.symas.com Director, Highland Sun http://highlandsun.com/hyc/ Chief Architect, OpenLDAP http://www.openldap.org/project/ --------------060206020501030606090605 Content-Type: text/plain; charset=UTF-8; name="diff.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="diff.txt" diff --git a/libraries/libldap/ldap-int.h b/libraries/libldap/ldap-int.h index c558d2a..ad37250 100644 --- a/libraries/libldap/ldap-int.h +++ b/libraries/libldap/ldap-int.h @@ -622,6 +622,7 @@ LDAP_F (void) ldap_free_select_info( void *sip ); LDAP_F (void) ldap_mark_select_write( LDAP *ld, Sockbuf *sb ); LDAP_F (void) ldap_mark_select_read( LDAP *ld, Sockbuf *sb ); LDAP_F (void) ldap_mark_select_clear( LDAP *ld, Sockbuf *sb ); +LDAP_F (void) ldap_clear_select_write( LDAP *ld, Sockbuf *sb ); LDAP_F (int) ldap_is_read_ready( LDAP *ld, Sockbuf *sb ); LDAP_F (int) ldap_is_write_ready( LDAP *ld, Sockbuf *sb ); diff --git a/libraries/libldap/open.c b/libraries/libldap/open.c index 6b92ba6..a920953 100644 --- a/libraries/libldap/open.c +++ b/libraries/libldap/open.c @@ -344,7 +344,6 @@ ldap_init_fd( /* Add the connection to the *LDAP's select pool */ ldap_mark_select_read( ld, conn->lconn_sb ); - ldap_mark_select_write( ld, conn->lconn_sb ); *ldp = ld; return LDAP_SUCCESS; @@ -502,7 +501,6 @@ ldap_open_internal_connection( LDAP **ldp, ber_socket_t *fdp ) /* Add the connection to the *LDAP's select pool */ ldap_mark_select_read( ld, c->lconn_sb ); - ldap_mark_select_write( ld, c->lconn_sb ); /* Make this connection an LDAP V3 protocol connection */ rc = LDAP_VERSION3; diff --git a/libraries/libldap/os-ip.c b/libraries/libldap/os-ip.c index daa765e..2864256 100644 --- a/libraries/libldap/os-ip.c +++ b/libraries/libldap/os-ip.c @@ -966,6 +966,32 @@ ldap_mark_select_clear( LDAP *ld, Sockbuf *sb ) #endif } +void +ldap_clear_select_write( LDAP *ld, Sockbuf *sb ) +{ + struct selectinfo *sip; + ber_socket_t sd; + + sip = (struct selectinfo *)ld->ld_selectinfo; + + ber_sockbuf_ctrl( sb, LBER_SB_OPT_GET_FD, &sd ); + +#ifdef HAVE_POLL + /* for UNIX poll(2) */ + { + int i; + for(i=0; i < sip->si_maxfd; i++) { + if( sip->si_fds[i].fd == sd ) { + sip->si_fds[i].events &= ~POLL_WRITE; + } + } + } +#else + /* for UNIX select(2) */ + FD_CLR( sd, &sip->si_writefds ); +#endif +} + int ldap_is_write_ready( LDAP *ld, Sockbuf *sb ) diff --git a/libraries/libldap/request.c b/libraries/libldap/request.c index 88190a2..071391d 100644 --- a/libraries/libldap/request.c +++ b/libraries/libldap/request.c @@ -202,6 +202,7 @@ ldap_int_flush_request( /* sent -- waiting for a response */ ldap_mark_select_read( ld, lc->lconn_sb ); + ldap_clear_select_write( ld, lc->lconn_sb ); } return 0; } diff --git a/libraries/libldap/result.c b/libraries/libldap/result.c index b6e8e75..7241df9 100644 --- a/libraries/libldap/result.c +++ b/libraries/libldap/result.c @@ -302,7 +302,7 @@ wait4msg( if ( ber_sockbuf_ctrl( lc->lconn_sb, LBER_SB_OPT_DATA_READY, NULL ) ) { - lc_ready = 1; + lc_ready = 2; /* ready at ber level, not socket level */ break; } } @@ -373,8 +373,8 @@ wait4msg( } } LDAP_MUTEX_UNLOCK( &ld->ld_req_mutex ); - /* Quit looping if no one handled any events */ - if (!serviced) + /* Quit looping if no one handled any socket events */ + if (!serviced && lc_ready == 1) rc = -1; } LDAP_MUTEX_UNLOCK( &ld->ld_conn_mutex ); --------------060206020501030606090605--
Date: Tue, 21 Feb 2012 08:54:05 -0500 (EST) From: Jan Vcelak <jvcelak@redhat.com> To: hyc@symas.com Cc: openldap-its@openldap.org Subject: Re: (ITS#7167) regression, ldap_result() returns -1
Perfect! This patch resolves the issue. Thank you, Howard! Jan ----- Original Message ----- > This is a multi-part message in MIME format. > --------------060206020501030606090605 > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > Content-Transfer-Encoding: 7bit > > Try this instead. > > Howard Chu wrote: > > Please test the attached patch and see if the problem is resolved, > > thanks. > >
______________ © Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org
