Full_Name: Stig Venaas Version: 2.0.4 OS: Linux URL: Submission from: (NULL) (158.38.60.92) If I do ldapsearch -h sipus.uninett.no -b "dc=hisf,dc=no" "cn=Stig*" I get two referrals, when following those and turning on debugging ldapsearch -C -d65535 -h sipus.uninett.no -b "dc=hisf,dc=no" "cn=Stig*" ldapsearch will hang, ending with: ** Outstanding Requests: * msgid 5, origid 2, status Request Completed outstanding referrals 0, parent count 1 * msgid 2, origid 2, status Request Completed outstanding referrals 1, parent count 0 ** Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 4, type 97 do_ldap_select It looks like it got all the data it should, it just hasn't realised it. The LDAP servers are publicly available so you can hopefully reproduce this. I can try to debug more myself but some pointers would be nice, the code isn't trivial. Stig
changed notes
Could you send me the complete trace? -Steve >>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM >>> Full_Name: Stig Venaas Version: 2.0.4 OS: Linux URL: Submission from: (NULL) (158.38.60.92) If I do ldapsearch -h sipus.uninett.no -b "dc=hisf,dc=no" "cn=Stig*" I get two referrals, when following those and turning on debugging ldapsearch -C -d65535 -h sipus.uninett.no -b "dc=hisf,dc=no" "cn=Stig*" ldapsearch will hang, ending with: ** Outstanding Requests: * msgid 5, origid 2, status Request Completed outstanding referrals 0, parent count 1 * msgid 2, origid 2, status Request Completed outstanding referrals 1, parent count 0 ** Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 4, type 97 do_ldap_select It looks like it got all the data it should, it just hasn't realised it. The LDAP servers are publicly available so you can hopefully reproduce this. I can try to debug more myself but some pointers would be nice, the code isn't trivial. Stig
I have submitted a patch to ftp://ftp.openldap.org/incoming/aclark-001004.patch The problem is caused by a deficiency in result.c:wait4msg() The scenario goes like this: Application does search_s Search_s calls result( ) result calls wait4msg(msgid=-1) wait4msg calls read1msg(msgid=-1) read1msg gets searchref on msgid=2 read1msg chases referral which calls simple bind - msgid = 4 bind_s calls result( msgid = 4) result calls wait4msg, msgid = 4 wait4msg calls read1msg msgid=4 read1msg gets a searchref on msgid = 2 read1msg chases referral which calls simple-bind - msgid = 6 bind_s calls result( msgid = 6) result calls wait4msg, msgid = 6 wait4msg calls read1msg msgid=6 read1msg gets msg with msgid=4 not looking for msgid=4, queue msg wait4msg calls read1msg msgid=6 read1msg get msg with msgid=6 read1msg returns msg to wait4msg msgid=6 wait4msg returns msg to result msgid=6 result returns status to bind request msgid=6 read1msg returns no data to wait4msg wait4msg calls read1msg msgid = 4 read1msg returns no data to wait4msg .... wait4msg calls read1msg msgid = 4 read1msg returns no data to wait4msg Because neither wait4msg nor try_read1msg look in the queue to see if the request is satisfied, wait4msg waits forever and the bind request with msgid=4 never returns. Result does however check the queue, but in this case it is too early. The patch makes the code that checks the queue a function and puts a check into wait4msg before calling read1msg. ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software >>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM >>> Full_Name: Stig Venaas Version: 2.0.4 OS: Linux URL: Submission from: (NULL) (158.38.60.92) If I do ldapsearch -h sipus.uninett.no -b "dc=hisf,dc=no" "cn=Stig*" I get two referrals, when following those and turning on debugging ldapsearch -C -d65535 -h sipus.uninett.no -b "dc=hisf,dc=no" "cn=Stig*" ldapsearch will hang, ending with: ** Outstanding Requests: * msgid 5, origid 2, status Request Completed outstanding referrals 0, parent count 1 * msgid 2, origid 2, status Request Completed outstanding referrals 1, parent count 0 ** Response Queue: * msgid 2, type 100 chained responses: * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 2, type 100 * msgid 4, type 97 do_ldap_select It looks like it got all the data it should, it just hasn't realised it. The LDAP servers are publicly available so you can hopefully reproduce this. I can try to debug more myself but some pointers would be nice, the code isn't trivial. Stig
The uploaded file was empty. Can you re-upload (under a new name). Kurt At 09:25 PM 10/4/00 +0000, VTAG@novell.com wrote: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=_0058EF2A.365735EB >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > > >I have submitted a patch to > >ftp://ftp.openldap.org/incoming/aclark-001004.patch > >The problem is caused by a deficiency in result.c:wait4msg() > >The scenario goes like this: > >Application does search_s >Search_s calls result( ) > result calls wait4msg(msgid=3D-1) > wait4msg calls read1msg(msgid=3D-1) > read1msg gets searchref on msgid=3D2 > read1msg chases referral which calls simple bind - msgid =3D 4 > bind_s calls result( msgid =3D 4) > result calls wait4msg, msgid =3D 4 > wait4msg calls read1msg msgid=3D4 > read1msg gets a searchref on msgid =3D 2 > read1msg chases referral which calls simple-bind - msgid =3D 6 > bind_s calls result( msgid =3D 6) > result calls wait4msg, msgid =3D 6 > wait4msg calls read1msg msgid=3D6 > read1msg gets msg with msgid=3D4 > not looking for msgid=3D4, queue msg > wait4msg calls read1msg msgid=3D6 > read1msg get msg with msgid=3D6 > read1msg returns msg to wait4msg msgid=3D6 > wait4msg returns msg to result msgid=3D6 > result returns status to bind request msgid=3D6 > read1msg returns no data to wait4msg > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to wait4msg > .... > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to wait4msg > >Because neither wait4msg nor try_read1msg look in the queue to see >if the request is satisfied, wait4msg waits forever and the bind request >with msgid=3D4 never returns. > >Result does however check the queue, but in this case it is too early. > >The patch makes the code that checks the queue a function and puts >a check into wait4msg before calling read1msg. > > >------------------------ >Steve Sonntag >Novell, Inc., the leading provider of Net services software > > > >>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM >>> >Full_Name: Stig Venaas >Version: 2.0.4 >OS: Linux >URL:=20 >Submission from: (NULL) (158.38.60.92) > > >If I do > >ldapsearch -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*" > >I get two referrals, when following those and turning on debugging > >ldapsearch -C -d65535 -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig= >*" > >ldapsearch will hang, ending with: > >** Outstanding Requests: >* msgid 5, origid 2, status Request Completed > outstanding referrals 0, parent count 1 >* msgid 2, origid 2, status Request Completed > outstanding referrals 1, parent count 0 >** Response Queue: >* msgid 2, type 100 > chained responses: > * msgid 2, type 100 > * msgid 2, type 100 > * msgid 2, type 100 > * msgid 2, type 100 > * msgid 2, type 100 >* msgid 4, type 97 >do_ldap_select > >It looks like it got all the data it should, it just hasn't realised it. = >The >LDAP servers are publicly available so you can hopefully reproduce this. I = >can >try to debug more myself but some pointers would be nice, the code isn't >trivial. > >Stig > >--=_0058EF2A.365735EB >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > >I have submitted a patch to > ><3d.htm>ftp://ftp.open= ldap.org/incoming/aclark-001004.patch > >The problem is caused by a deficiency in result.c:wait4msg() > >The scenario goes like this: > >Application does search_s >Search_s calls result( ) > result calls wait4msg(msgid=3D-1) > wait4msg calls read1msg(msgid=3D-1) > read1msg gets searchref on msgid=3D2 > read1msg chases referral which calls simple = bind -=20 msgid =3D 4 > bind_s calls result( msgid =3D = 4) > result calls wait4msg, msgid =3D = 4 > wait4msg calls read1msg=20 msgid=3D4 > read1msg gets a searchref on = msgid =3D=20 2 > read1msg chases=20 referral which calls simple-bind - msgid =3D 6 > bind_s calls = result(=20 msgid =3D 6) > result calls = wait4msg,=20 msgid =3D 6 > wait4msg = calls=20 read1msg msgid=3D6 > read1msg = gets=20 msg with msgid=3D4 > &nbs= >p; not=20 looking for msgid=3D4, queue msg > wait4msg = calls=20 read1msg msgid=3D6 > read1msg get = msg=20 with msgid=3D6 > read1msg = returns msg=20 to wait4msg msgid=3D6 > wait4msg = returns msg=20 to result msgid=3D6 > result = returns=20 status to bind request msgid=3D6 > read1msg returns no data to wait4msg > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to wait4msg > .... > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to=20 wait4msg > >Because neither wait4msg nor try_read1msg look in the queue to = see >if the request is satisfied, wait4msg waits forever and the bind=20 request >with msgid=3D4 never returns. > >Result does however check the queue, but in this case it is too=20 early. > >The patch makes the code that checks the queue a function and = puts >a check into wait4msg before calling read1msg. > > >------------------------ >Steve Sonntag >Novell, Inc., the = leading=20 provider of Net services software > > > >>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM=20 >>> >Full_Name: Stig Venaas >Version: 2.0.4 >OS: Linux >UR= L:=20 >Submission from: (NULL) (158.38.60.92) > > >If I do > >ldapse= arch=20 -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*" > >I get two = referrals,=20 when following those and turning on debugging > >ldapsearch -C -d65535 = -h=20 sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*" > >ldapsearch = will hang,=20 ending with: > >** Outstanding Requests: >* msgid 5, origid = 2,=20 status Request Completed > outstanding referrals 0, parent = count=20 1 >* msgid 2, origid 2, status Request Completed > =20= outstanding referrals 1, parent count 0 >** Response Queue: >* = msgid=20 2, type 100 > chained responses: > * msgid = 2, =20 type 100 > * msgid 2, type 100 > * msgid 2, = type=20 100 > * msgid 2, type 100 > * msgid 2, type = 100 >*=20 msgid 4, type 97 >do_ldap_select > >It looks like it got all = the=20 data it should, it just hasn't realised it. The >LDAP servers are = publicly=20 available so you can hopefully reproduce this. I can >try to debug more = myself=20 but some pointers would be nice, the code=20 isn't >trivial. > >Stig > >--=_0058EF2A.365735EB--
Done ftp://ftp.openldap.org/incoming/aclark-001004a.patch -Stve >>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org> 04-Oct-00 4:03:57 PM >>> The uploaded file was empty. Can you re-upload (under a new name). Kurt At 09:25 PM 10/4/00 +0000, VTAG@novell.com wrote: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=_0058EF2A.365735EB >Content-Type: text/plain; charset=US-ASCII >Content-Transfer-Encoding: quoted-printable > > >I have submitted a patch to > >ftp://ftp.openldap.org/incoming/aclark-001004.patch > >The problem is caused by a deficiency in result.c:wait4msg() > >The scenario goes like this: > >Application does search_s >Search_s calls result( ) > result calls wait4msg(msgid=3D-1) > wait4msg calls read1msg(msgid=3D-1) > read1msg gets searchref on msgid=3D2 > read1msg chases referral which calls simple bind - msgid =3D 4 > bind_s calls result( msgid =3D 4) > result calls wait4msg, msgid =3D 4 > wait4msg calls read1msg msgid=3D4 > read1msg gets a searchref on msgid =3D 2 > read1msg chases referral which calls simple-bind - msgid =3D 6 > bind_s calls result( msgid =3D 6) > result calls wait4msg, msgid =3D 6 > wait4msg calls read1msg msgid=3D6 > read1msg gets msg with msgid=3D4 > not looking for msgid=3D4, queue msg > wait4msg calls read1msg msgid=3D6 > read1msg get msg with msgid=3D6 > read1msg returns msg to wait4msg msgid=3D6 > wait4msg returns msg to result msgid=3D6 > result returns status to bind request msgid=3D6 > read1msg returns no data to wait4msg > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to wait4msg > .... > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to wait4msg > >Because neither wait4msg nor try_read1msg look in the queue to see >if the request is satisfied, wait4msg waits forever and the bind request >with msgid=3D4 never returns. > >Result does however check the queue, but in this case it is too early. > >The patch makes the code that checks the queue a function and puts >a check into wait4msg before calling read1msg. > > >------------------------ >Steve Sonntag >Novell, Inc., the leading provider of Net services software > > > >>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM >>> >Full_Name: Stig Venaas >Version: 2.0.4 >OS: Linux >URL:=20 >Submission from: (NULL) (158.38.60.92) > > >If I do > >ldapsearch -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*" > >I get two referrals, when following those and turning on debugging > >ldapsearch -C -d65535 -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig= >*" > >ldapsearch will hang, ending with: > >** Outstanding Requests: >* msgid 5, origid 2, status Request Completed > outstanding referrals 0, parent count 1 >* msgid 2, origid 2, status Request Completed > outstanding referrals 1, parent count 0 >** Response Queue: >* msgid 2, type 100 > chained responses: > * msgid 2, type 100 > * msgid 2, type 100 > * msgid 2, type 100 > * msgid 2, type 100 > * msgid 2, type 100 >* msgid 4, type 97 >do_ldap_select > >It looks like it got all the data it should, it just hasn't realised it. = >The >LDAP servers are publicly available so you can hopefully reproduce this. I = >can >try to debug more myself but some pointers would be nice, the code isn't >trivial. > >Stig > >--=_0058EF2A.365735EB >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> > >I have submitted a patch to > ><3d.htm>ftp://ftp.open= ldap.org/incoming/aclark-001004.patch > >The problem is caused by a deficiency in result.c:wait4msg() > >The scenario goes like this: > >Application does search_s >Search_s calls result( ) > result calls wait4msg(msgid=3D-1) > wait4msg calls read1msg(msgid=3D-1) > read1msg gets searchref on msgid=3D2 > read1msg chases referral which calls simple = bind -=20 msgid =3D 4 > bind_s calls result( msgid =3D = 4) > result calls wait4msg, msgid =3D = 4 > wait4msg calls read1msg=20 msgid=3D4 > read1msg gets a searchref on = msgid =3D=20 2 > read1msg chases=20 referral which calls simple-bind - msgid =3D 6 > bind_s calls = result(=20 msgid =3D 6) > result calls = wait4msg,=20 msgid =3D 6 > wait4msg = calls=20 read1msg msgid=3D6 > read1msg = gets=20 msg with msgid=3D4 > &nbs= >p; not=20 looking for msgid=3D4, queue msg > wait4msg = calls=20 read1msg msgid=3D6 > read1msg get = msg=20 with msgid=3D6 > read1msg = returns msg=20 to wait4msg msgid=3D6 > wait4msg = returns msg=20 to result msgid=3D6 > result = returns=20 status to bind request msgid=3D6 > read1msg returns no data to wait4msg > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to wait4msg > .... > wait4msg calls read1msg msgid =3D 4 > read1msg returns no data to=20 wait4msg > >Because neither wait4msg nor try_read1msg look in the queue to = see >if the request is satisfied, wait4msg waits forever and the bind=20 request >with msgid=3D4 never returns. > >Result does however check the queue, but in this case it is too=20 early. > >The patch makes the code that checks the queue a function and = puts >a check into wait4msg before calling read1msg. > > >------------------------ >Steve Sonntag >Novell, Inc., the = leading=20 provider of Net services software > > > >>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM=20 >>> >Full_Name: Stig Venaas >Version: 2.0.4 >OS: Linux >UR= L:=20 >Submission from: (NULL) (158.38.60.92) > > >If I do > >ldapse= arch=20 -h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*" > >I get two = referrals,=20 when following those and turning on debugging > >ldapsearch -C -d65535 = -h=20 sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*" > >ldapsearch = will hang,=20 ending with: > >** Outstanding Requests: >* msgid 5, origid = 2,=20 status Request Completed > outstanding referrals 0, parent = count=20 1 >* msgid 2, origid 2, status Request Completed > =20= outstanding referrals 1, parent count 0 >** Response Queue: >* = msgid=20 2, type 100 > chained responses: > * msgid = 2, =20 type 100 > * msgid 2, type 100 > * msgid 2, = type=20 100 > * msgid 2, type 100 > * msgid 2, type = 100 >*=20 msgid 4, type 97 >do_ldap_select > >It looks like it got all = the=20 data it should, it just hasn't realised it. The >LDAP servers are = publicly=20 available so you can hopefully reproduce this. I can >try to debug more = myself=20 but some pointers would be nice, the code=20 isn't >trivial. > >Stig > >--=_0058EF2A.365735EB--
moved from Incoming to Software Bugs
changed notes changed state Open to Test
I have prepared a more robust fix. It is to be found at URL ftp://ftp.openldap.org/incoming/vtag-001011.patch The problem is that the current code checks the queue inside the test for correct connecction state, so sometimes the queue doesn't get checked. This change moves the test outside the connection check. -Steve ------------------------ Steve Sonntag Novell, Inc., the leading provider of Net services software >>> Stig Venås <venaas@alfa.itea.ntnu.no> 10-Oct-00 7:23:08 AM >>> Hi Thanks for trying to fix the problem. It got better, but I still encounter problems in some situations. Have a look at the attached debug output. I'll try to give you more info if necessary. Stig
Applied, thanks! Kurt At 07:05 PM 10/11/00 +0000, VTAG@novell.com wrote: >This is a MIME message. If you are reading this text, you may want to >consider changing to a mail reader or gateway that understands how to >properly handle MIME multipart messages. > >--=_C29A12CE.A7C6B963 >Content-Type: text/plain; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > >I have prepared a more robust fix. It is to be found at URL > >ftp://ftp.openldap.org/incoming/vtag-001011.patch > >The problem is that the current code checks the queue inside >the test for correct connecction state, so sometimes the queue >doesn't get checked. This change moves the test outside >the connection check. > >-Steve > >------------------------ >Steve Sonntag >Novell, Inc., the leading provider of Net services software > > > >>>> Stig Ven=E5s <venaas@alfa.itea.ntnu.no> 10-Oct-00 7:23:08 AM >>> >Hi > >Thanks for trying to fix the problem. It got better, but I still >encounter problems in some situations. Have a look at the attached >debug output. I'll try to give you more info if necessary. > >Stig > >--=_C29A12CE.A7C6B963 >Content-Type: text/html; charset=ISO-8859-1 >Content-Transfer-Encoding: quoted-printable > ><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> >I have prepared a more robust fix. It is to be found = at=20 URL > ><3d.htm>ftp://ftp.openld= ap.org/incoming/vtag-001011.patch > >The problem is that the current code checks the queue inside >the test for correct connecction state, so sometimes the queue >doesn't get checked. This change moves the test outside >the connection check. > >-Steve > >------------------------ >Steve Sonntag >Novell, Inc., the = leading=20 provider of Net services software > > > >>>> Stig Ven=E5s <venaas@alfa.itea.ntnu.no> = 10-Oct-00=20 7:23:08 AM >>> >Hi > >Thanks for trying to fix the problem. = It=20 got better, but I still >encounter problems in some situations. Have a = look at=20 the attached >debug output. I'll try to give you more info if=20 necessary. > >Stig > >--=_C29A12CE.A7C6B963--
changed notes changed state Test to Release
changed notes changed state Release to Closed
moved from Software Bugs to Archive.Software Bugs
vtag to review fixed in devel fixed in re20