[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.
--=_BBE35485.1D7C1EA8
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable
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=20
>consider changing to a mail reader or gateway that understands how to=20
>properly handle MIME multipart messages.
>
>--=3D_0058EF2A.365735EB
>Content-Type: text/plain; charset=3DUS-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=3D3D-1)
> wait4msg calls read1msg(msgid=3D3D-1)
> read1msg gets searchref on msgid=3D3D2
> read1msg chases referral which calls simple bind - msgid =3D3D 4
> bind_s calls result( msgid =3D3D 4)
> result calls wait4msg, msgid =3D3D 4
> wait4msg calls read1msg msgid=3D3D4
> read1msg gets a searchref on msgid =3D3D 2
> read1msg chases referral which calls simple-bind - msgid =3D3D 6
> bind_s calls result( msgid =3D3D 6)
> result calls wait4msg, msgid =3D3D 6
> wait4msg calls read1msg msgid=3D3D6
> read1msg gets msg with msgid=3D3D4
> not looking for msgid=3D3D4, queue msg
> wait4msg calls read1msg msgid=3D3D6
> read1msg get msg with msgid=3D3D6
> read1msg returns msg to wait4msg msgid=3D3D6
> wait4msg returns msg to result msgid=3D3D6
> result returns status to bind request msgid=3D3D6
> read1msg returns no data to wait4msg
> wait4msg calls read1msg msgid =3D3D 4
> read1msg returns no data to wait4msg
> ....
> wait4msg calls read1msg msgid =3D3D 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=3D3D4 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:=3D20
>Submission from: (NULL) (158.38.60.92)
>
>
>If I do
>
>ldapsearch -h sipus.uninett.no -b "dc=3D3Dhisf,dc=3D3Dno" "cn=3D3DStig*"
>
>I get two referrals, when following those and turning on debugging
>
>ldapsearch -C -d65535 -h sipus.uninett.no -b "dc=3D3Dhisf,dc=3D3Dno" =
"cn=3D3DStig=3D
>*"
>
>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. =
=3D
>The
>LDAP servers are publicly available so you can hopefully reproduce this. =
I =3D
>can
>try to debug more myself but some pointers would be nice, the code isn't
>trivial.
>
>Stig
>
>--=3D_0058EF2A.365735EB
>Content-Type: text/html; charset=3DISO-8859-1
>Content-Transfer-Encoding: quoted-printable
>
><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
>=20
>I have submitted a patch to
>=20
><3d.htm>ftp://ftp.open=3D ldap.org/incoming/aclark-001004.patch
>=20
>The problem is caused by a deficiency in result.c:wait4msg()
>=20
>The scenario goes like this:
>=20
>Application does search_s
>Search_s calls result( )
> result calls wait4msg(msgid=3D3D-1)
> wait4msg calls read1msg(msgid=3D3D-1)
> read1msg gets searchref on msgid=3D3D2
> read1msg chases referral which calls simple =3D bind -=3D20 msgid =
=3D3D 4
> bind_s calls result( msgid =3D3D =3D 4)
> result calls wait4msg, msgid =3D3D =3D 4
> wait4msg calls read1msg=3D20 msgid=3D3D4
> read1msg gets a searchref on =3D msgid =3D3D=3D20 2
> read1msg chases=3D20 referral which calls simple-bind - msgid =
=3D3D 6
> bind_s calls =3D result(=3D20 msgid =3D3D 6)
> result calls =3D wait4msg,=3D20 msgid =3D3D 6
> wait4msg =3D calls=3D20 read1msg msgid=3D3D6
> read1msg =3D gets=3D20 msg with msgid=3D3D4
> &nbs=3D
>p; not=3D20 looking for msgid=3D3D4, queue msg
> wait4msg =3D calls=3D20 read1msg msgid=3D3D6
> read1msg get =3D msg=3D20 with msgid=3D3D6
> read1msg =3D returns msg=3D20 to wait4msg msgid=3D3D6
> wait4msg =3D returns msg=3D20 to result msgid=3D3D6
> result =3D returns=3D20 status to bind request msgid=3D3D6
> read1msg returns no data to wait4msg=20
> wait4msg calls read1msg msgid =3D3D 4
> read1msg returns no data to wait4msg
> ....
> wait4msg calls read1msg msgid =3D3D 4
> read1msg returns no data to=3D20 wait4msg
>=20
>Because neither wait4msg nor try_read1msg look in the queue to =3D see
>if the request is satisfied, wait4msg waits forever and the bind=3D20 =
request
>with msgid=3D3D4 never returns.
>=20
>Result does however check the queue, but in this case it is too=3D20 =
early.
>=20
>The patch makes the code that checks the queue a function and =3D puts
>a check into wait4msg before calling read1msg.
>=20
>=20
>------------------------
>Steve Sonntag
>Novell, Inc., the =3D leading=3D20 provider of Net services software
>=20
>=20
>
>>>> <venaas@uninett.no> 03-Oct-00 8:03:37 AM=3D20 >>>
>Full_Name: Stig Venaas
>Version: 2.0.4
>OS: Linux
>UR=3D L:=3D20=20
>Submission from: (NULL) (158.38.60.92)
>
>
>If I do
>
>ldapse=3D arch=3D20 -h sipus.uninett.no -b "dc=3D3Dhisf,dc=3D3Dno" =
"cn=3D3DStig*"
>
>I get two =3D referrals,=3D20 when following those and turning on =
debugging
>
>ldapsearch -C -d65535 =3D -h=3D20 sipus.uninett.no -b "dc=3D3Dhisf,dc=3D3D=
no" "cn=3D3DStig*"
>
>ldapsearch =3D will hang,=3D20 ending with:
>
>** Outstanding Requests:
>* msgid 5, origid =3D 2,=3D20 status Request Completed
> outstanding referrals 0, parent =3D count=3D20 1
>* msgid 2, origid 2, status Request Completed
> =3D20=3D outstanding referrals 1, parent count 0
>** Response Queue:
>* =3D msgid=3D20 2, type 100
> chained responses:
> * msgid =3D 2, =3D20 type 100
> * msgid 2, type 100
> * msgid 2, =3D type=3D20 100
> * msgid 2, type 100
> * msgid 2, type =3D 100
>*=3D20 msgid 4, type 97
>do_ldap_select
>
>It looks like it got all =3D the=3D20 data it should, it just hasn't =
realised it. The
>LDAP servers are =3D publicly=3D20 available so you can hopefully =
reproduce this. I can
>try to debug more =3D myself=3D20 but some pointers would be nice, the =
code=3D20 isn't
>trivial.
>
>Stig
>
>--=3D_0058EF2A.365735EB--
--=_BBE35485.1D7C1EA8
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><FONT size=3D1>Done</FONT></DIV>
<DIV> </DIV>
<DIV><A=20
href=3D"ftp://ftp.openldap.org/incoming/aclark-001004a.patch";>ftp://ftp.ope=
nldap.org/incoming/aclark-001004a.patch</A></DIV>
<DIV> </DIV>
<DIV>-Stve<BR><BR><BR>>>> "Kurt D. Zeilenga" <Kurt@OpenLDAP.org=
>=20
04-Oct-00 4:03:57 PM >>><BR>The uploaded file was empty. =
Can you=20
re-upload (under a new<BR>name).<BR><BR>Kurt<BR><BR>At 09:25 PM 10/4/00 =
+0000,=20
VTAG@novell.com wrote:<BR>>This is a MIME message. If you are reading =
this=20
text, you may want to <BR>>consider changing to a mail reader or =
gateway that=20
understands how to <BR>>properly handle MIME multipart=20
messages.<BR>><BR>>--=3D_0058EF2A.365735EB<BR>>Content-Type: =
text/plain;=20
charset=3DUS-ASCII<BR>>Content-Transfer-Encoding:=20
quoted-printable<BR>><BR>><BR>>I have submitted a patch=20
to<BR>><BR>>ftp://ftp.openldap.org/incoming/aclark-001004.patch<BR>&g=
t;<BR>>The=20
problem is caused by a deficiency in result.c:wait4msg()<BR>><BR>>The=
=20
scenario goes like this:<BR>><BR>>Application does=20
search_s<BR>>Search_s calls result( )<BR>> result =
calls=20
wait4msg(msgid=3D3D-1)<BR>> wait4msg calls=20
read1msg(msgid=3D3D-1)<BR>> read1msg gets searchref on=20
msgid=3D3D2<BR>> read1msg chases referral which calls =
simple bind -=20
msgid =3D3D 4<BR>> bind_s calls =
result(=20
msgid =3D3D 4)<BR>> result calls =
wait4msg,=20
msgid =3D3D 4<BR>> wait4msg calls =
read1msg=20
msgid=3D3D4<BR>> read1msg gets a =
searchref=20
on msgid =3D3D 2<BR>> read1msg =
chases=20
referral which calls simple-bind - msgid =3D3D=20
6<BR>> bind_s =
calls=20
result( msgid =3D3D=20
6)<BR>> result =
calls=20
wait4msg, msgid =3D3D=20
6<BR>> wait4msg =
calls=20
read1msg msgid=3D3D6<BR>>  =
; =20
read1msg gets msg with=20
msgid=3D3D4<BR>> &n=
bsp; =20
not looking for msgid=3D3D4, queue=20
msg<BR>> wait4msg =
calls=20
read1msg msgid=3D3D6<BR>>  =
; =20
read1msg get msg with=20
msgid=3D3D6<BR>> =
read1msg=20
returns msg to wait4msg=20
msgid=3D3D6<BR>> =
wait4msg=20
returns msg to result=20
msgid=3D3D6<BR>> =
result=20
returns status to bind request msgid=3D3D6<BR>> =
=20
read1msg returns no data to wait4msg<BR>> =
wait4msg=20
calls read1msg msgid =3D3D 4<BR>> read1msg =
returns no=20
data to wait4msg<BR>> =20
....<BR>> wait4msg calls read1msg msgid =
=3D3D=20
4<BR>> read1msg returns no data to=20
wait4msg<BR>><BR>>Because neither wait4msg nor try_read1msg look in =
the=20
queue to see<BR>>if the request is satisfied, wait4msg waits forever =
and the=20
bind request<BR>>with msgid=3D3D4 never returns.<BR>><BR>>Result =
does=20
however check the queue, but in this case it is too early.<BR>><BR>>T=
he=20
patch makes the code that checks the queue a function and puts<BR>>a =
check=20
into wait4msg before calling=20
read1msg.<BR>><BR>><BR>>------------------------<BR>>Steve=20
Sonntag<BR>>Novell, Inc., the leading provider of Net services=20
software<BR>><BR>><BR>><BR>>>>> <venaas@uninett.no&=
gt;=20
03-Oct-00 8:03:37 AM >>><BR>>Full_Name: Stig Venaas<BR>>Vers=
ion:=20
2.0.4<BR>>OS: Linux<BR>>URL:=3D20<BR>>Submission from: (NULL)=20
(158.38.60.92)<BR>><BR>><BR>>If I do<BR>><BR>>ldapsearch =
-h=20
sipus.uninett.no -b "dc=3D3Dhisf,dc=3D3Dno" "cn=3D3DStig*"<BR>><BR>>I=
get two=20
referrals, when following those and turning on=20
debugging<BR>><BR>>ldapsearch -C -d65535 -h sipus.uninett.no -b=20
"dc=3D3Dhisf,dc=3D3Dno" "cn=3D3DStig=3D<BR>>*"<BR>><BR>>ldapsearch=
will hang,=20
ending with:<BR>><BR>>** Outstanding Requests:<BR>>* msgid =
5, =20
origid 2, status Request Completed<BR>> outstanding =
referrals 0,=20
parent count 1<BR>>* msgid 2, origid 2, status Request=20
Completed<BR>> outstanding referrals 1, parent count =
0<BR>>**=20
Response Queue:<BR>>* msgid 2, type 100<BR>> =
chained=20
responses:<BR>> * msgid 2, type 100<BR>> * =
msgid=20
2, type 100<BR>> * msgid 2, type 100<BR>> * =
msgid=20
2, type 100<BR>> * msgid 2, type 100<BR>>* =
msgid=20
4, type 97<BR>>do_ldap_select<BR>><BR>>It looks like it got =
all=20
the data it should, it just hasn't realised it. =3D<BR>>The<BR>>LDAP =
servers=20
are publicly available so you can hopefully reproduce this. I=20
=3D<BR>>can<BR>>try to debug more myself but some pointers would be =
nice,=20
the code=20
isn't<BR>>trivial.<BR>><BR>>Stig<BR>><BR>>--=3D_0058EF2A.365=
735EB<BR>>Content-Type:=20
text/html; charset=3DISO-8859-1<BR>>Content-Transfer-Encoding:=20
quoted-printable<BR>><BR>><!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML =
4.0=20
Transitional//EN"><BR>> <BR>>I have submitted a patch to<BR>>=
=20
<BR>><3d.htm>ftp://ftp.open=3D=20
ldap.org/incoming/aclark-001004.patch<BR>> <BR>>The problem is =
caused by a=20
deficiency in result.c:wait4msg()<BR>> <BR>>The scenario goes =
like=20
this:<BR>> <BR>>Application does search_s<BR>>Search_s calls =
result(=20
)<BR>> result calls wait4msg(msgid=3D3D-1)<BR>> &nbs=
p;=20
wait4msg calls read1msg(msgid=3D3D-1)<BR>> read1msg gets =
searchref=20
on msgid=3D3D2<BR>> read1msg chases referral which calls =
simple =3D=20
bind -=3D20 msgid =3D3D 4<BR>> =
bind_s calls=20
result( msgid =3D3D =3D 4)<BR>> =
result calls=20
wait4msg, msgid =3D3D =3D 4<BR>> =
wait4msg=20
calls read1msg=3D20 msgid=3D3D4<BR>> =
read1msg=20
gets a searchref on =3D msgid =3D3D=3D20 2<BR>> &=
nbsp; =20
read1msg chases=3D20 referral which calls simple-bind - msgid =3D3D=20
6<BR>> bind_s =
calls =3D=20
result(=3D20 msgid =3D3D=20
6)<BR>> result =
calls =3D=20
wait4msg,=3D20 msgid =3D3D=20
6<BR>> wait4msg =
=3D=20
calls=3D20 read1msg=20
msgid=3D3D6<BR>> =
read1msg=20
=3D gets=3D20 msg with=20
msgid=3D3D4<BR>> &n=
bsp;=20
&nbs=3D<BR>>p; not=3D20 looking for msgid=3D3D4, queue=20
msg<BR>> wait4msg =
=3D=20
calls=3D20 read1msg=20
msgid=3D3D6<BR>> =
read1msg=20
get =3D msg=3D20 with=20
msgid=3D3D6<BR>> =
read1msg=20
=3D returns msg=3D20 to wait4msg=20
msgid=3D3D6<BR>> =
wait4msg=20
=3D returns msg=3D20 to result=20
msgid=3D3D6<BR>> =
result =3D=20
returns=3D20 status to bind request msgid=3D3D6<BR>> &n=
bsp;=20
read1msg returns no data to wait4msg <BR>> =
wait4msg=20
calls read1msg msgid =3D3D 4<BR>> read1msg =
returns no=20
data to wait4msg<BR>> =20
....<BR>> wait4msg calls read1msg msgid =
=3D3D=20
4<BR>> read1msg returns no data to=3D20=20
wait4msg<BR>> <BR>>Because neither wait4msg nor try_read1msg look in =
the=20
queue to =3D see<BR>>if the request is satisfied, wait4msg waits =
forever and=20
the bind=3D20 request<BR>>with msgid=3D3D4 never returns.<BR>> =
<BR>>Result=20
does however check the queue, but in this case it is too=3D20 early.<BR>>=
;=20
<BR>>The patch makes the code that checks the queue a function and =
=3D=20
puts<BR>>a check into wait4msg before calling read1msg.<BR>> =
<BR>>=20
<BR>>------------------------<BR>>Steve Sonntag<BR>>Novell, Inc., =
the =3D=20
leading=3D20 provider of Net services software<BR>> <BR>>=20
<BR>><BR>>>>> <venaas@uninett.no> 03-Oct-00 8:03:37 =
AM=3D20=20
>>><BR>>Full_Name: Stig Venaas<BR>>Version: 2.0.4<BR>>OS:=
=20
Linux<BR>>UR=3D L:=3D20 <BR>>Submission from: (NULL)=20
(158.38.60.92)<BR>><BR>><BR>>If I do<BR>><BR>>ldapse=3D =
arch=3D20 -h=20
sipus.uninett.no -b "dc=3D3Dhisf,dc=3D3Dno" "cn=3D3DStig*"<BR>><BR>>I=
get two =3D=20
referrals,=3D20 when following those and turning on=20
debugging<BR>><BR>>ldapsearch -C -d65535 =3D -h=3D20 sipus.uninett.no=
-b=20
"dc=3D3Dhisf,dc=3D3Dno" "cn=3D3DStig*"<BR>><BR>>ldapsearch =3D will =
hang,=3D20=20
ending with:<BR>><BR>>** Outstanding Requests:<BR>>* msgid =
5, =20
origid =3D 2,=3D20 status Request Completed<BR>> outstanding=
=20
referrals 0, parent =3D count=3D20 1<BR>>* msgid 2, origid 2, =
status=20
Request Completed<BR>> =3D20=3D outstanding referrals 1, parent =
count=20
0<BR>>** Response Queue:<BR>>* =3D msgid=3D20 2, type=20
100<BR>> chained responses:<BR>> * msgid =3D 2, =
=3D20 type=20
100<BR>> * msgid 2, type 100<BR>> * msgid 2, =
=3D=20
type=3D20 100<BR>> * msgid 2, type 100<BR>> * =
msgid=20
2, type =3D 100<BR>>*=3D20 msgid 4, type=20
97<BR>>do_ldap_select<BR>><BR>>It looks like it got all =3D =
the=3D20 data=20
it should, it just hasn't realised it. The<BR>>LDAP servers are =3D =
publicly=3D20=20
available so you can hopefully reproduce this. I can<BR>>try to debug =
more =3D=20
myself=3D20 but some pointers would be nice, the code=3D20=20
isn't<BR>>trivial.<BR>><BR>>Stig<BR>><BR>>--=3D_0058EF2A.365=
735EB--<BR><BR></DIV></BODY></HTML>
--=_BBE35485.1D7C1EA8--