[Date Prev][Date Next]
[Chronological]
[Thread]
[Top]
Re: Problem chasing multiple referrals (ITS#799)
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">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" http-equiv=3DContent-Type=
>
<META content=3D"MSHTML 5.00.2014.210" name=3DGENERATOR></HEAD>
<BODY style=3D"FONT: 8pt MS Sans Serif; MARGIN-LEFT: 2px; MARGIN-TOP: =
2px">
<DIV> </DIV>
<DIV><FONT size=3D1>I have submitted a patch to</FONT></DIV>
<DIV> </DIV>
<DIV><A=20
href=3D"ftp://ftp.openldap.org/incoming/aclark-001004.patch";>ftp://ftp.open=
ldap.org/incoming/aclark-001004.patch</A></DIV>
<DIV> </DIV>
<DIV>The problem is caused by a deficiency in result.c:wait4msg()</DIV>
<DIV> </DIV>
<DIV>The scenario goes like this:</DIV>
<DIV> </DIV>
<DIV>Application does search_s</DIV>
<DIV>Search_s calls result( )</DIV>
<DIV> result calls wait4msg(msgid=3D-1)</DIV>
<DIV> wait4msg calls read1msg(msgid=3D-1)</DIV>
<DIV> read1msg gets searchref on msgid=3D2</DIV>
<DIV> read1msg chases referral which calls simple =
bind -=20
msgid =3D 4</DIV>
<DIV> bind_s calls result( msgid =3D =
4)</DIV>
<DIV> result calls wait4msg, msgid =3D =
4</DIV>
<DIV> wait4msg calls read1msg=20
msgid=3D4</DIV>
<DIV> read1msg gets a searchref on =
msgid =3D=20
2</DIV>
<DIV> read1msg chases=20
referral which calls simple-bind - msgid =3D 6</DIV>
<DIV>
<DIV> bind_s calls =
result(=20
msgid =3D 6)</DIV>
<DIV> result calls =
wait4msg,=20
msgid =3D 6</DIV>
<DIV> wait4msg =
calls=20
read1msg msgid=3D6</DIV>
<DIV> read1msg =
gets=20
msg with msgid=3D4</DIV>
<DIV> &nbs=
p; not=20
looking for msgid=3D4, queue msg</DIV>
<DIV> wait4msg =
calls=20
read1msg msgid=3D6</DIV>
<DIV> read1msg get =
msg=20
with msgid=3D6</DIV>
<DIV> read1msg =
returns msg=20
to wait4msg msgid=3D6</DIV>
<DIV> wait4msg =
returns msg=20
to result msgid=3D6</DIV>
<DIV> result =
returns=20
status to bind request msgid=3D6</DIV>
<DIV> read1msg returns no data to wait4msg</DI=
V>
<DIV> wait4msg calls read1msg msgid =3D 4</DIV>
<DIV> read1msg returns no data to wait4msg</DIV>
<DIV> ....</DIV>
<DIV>
<DIV> wait4msg calls read1msg msgid =3D 4</DIV>
<DIV> read1msg returns no data to=20
wait4msg</DIV></DIV></DIV>
<DIV> </DIV>
<DIV>Because neither wait4msg nor try_read1msg look in the queue to =
see</DIV>
<DIV>if the request is satisfied, wait4msg waits forever and the bind=20
request</DIV>
<DIV>with msgid=3D4 never returns.</DIV>
<DIV> </DIV>
<DIV>Result does however check the queue, but in this case it is too=20
early.</DIV>
<DIV> </DIV>
<DIV>The patch makes the code that checks the queue a function and =
puts</DIV>
<DIV>a check into wait4msg before calling read1msg.</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV>------------------------<BR>Steve Sonntag<BR>Novell, Inc., the =
leading=20
provider of Net services software</DIV>
<DIV> </DIV>
<DIV> </DIV>
<DIV><BR>>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM=20
>>><BR>Full_Name: Stig Venaas<BR>Version: 2.0.4<BR>OS: Linux<BR>UR=
L:=20
<BR>Submission from: (NULL) (158.38.60.92)<BR><BR><BR>If I do<BR><BR>ldapse=
arch=20
-h sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*"<BR><BR>I get two =
referrals,=20
when following those and turning on debugging<BR><BR>ldapsearch -C -d65535 =
-h=20
sipus.uninett.no -b "dc=3Dhisf,dc=3Dno" "cn=3DStig*"<BR><BR>ldapsearch =
will hang,=20
ending with:<BR><BR>** Outstanding Requests:<BR>* msgid 5, origid =
2,=20
status Request Completed<BR> outstanding referrals 0, parent =
count=20
1<BR>* msgid 2, origid 2, status Request Completed<BR> =20=
outstanding referrals 1, parent count 0<BR>** Response Queue:<BR>* =
msgid=20
2, type 100<BR> chained responses:<BR> * msgid =
2, =20
type 100<BR> * msgid 2, type 100<BR> * msgid 2, =
type=20
100<BR> * msgid 2, type 100<BR> * msgid 2, type =
100<BR>*=20
msgid 4, type 97<BR>do_ldap_select<BR><BR>It looks like it got all =
the=20
data it should, it just hasn't realised it. The<BR>LDAP servers are =
publicly=20
available so you can hopefully reproduce this. I can<BR>try to debug more =
myself=20
but some pointers would be nice, the code=20
isn't<BR>trivial.<BR><BR>Stig<BR></DIV></BODY></HTML>
--=_0058EF2A.365735EB--