OpenLDAP
Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest

Viewing Software Bugs/7167
Full headers

From: jvcelak@redhat.com
Subject: regression, ldap_result() returns -1
Compose comment
Download message
State:
0 replies:
10 followups: 1 2 3 4 5 6 7 8 9 10

Major security issue: yes  no

Notes:

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

Followup 1

Download message
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/



Followup 2

Download message
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/



Followup 3

Download message
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.



Followup 4

Download message
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/



Followup 5

Download message
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--



Followup 6

Download message
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



Followup 7

Download message
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

Message of length 5790 truncated


Followup 8

Download message
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

Message of length 7005 truncated


Followup 9

Download message
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--



Followup 10

Download message
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.
> >


Up to top level
Build   Contrib   Development   Documentation   Historical   Incoming   Software Bugs   Software Enhancements   Web  

Logged in as guest


The OpenLDAP Issue Tracking System uses a hacked version of JitterBug

______________
© Copyright 2013, OpenLDAP Foundation, info@OpenLDAP.org