82598 - LDAP C SDK deadlock with ldap_abandon_ext and ldap_result

Status: VERIFIED FIXED

(Directory :: LDAP C SDK, defect, P1)

Description

[Dan Mosedale (:dmosedale, :dmose)]

When doing an LDAP autocomplete over a slow connection, we hit a deadlock in the
SDK with some frequency.  It can be reproduced using the same steps to reproduce
the crasher in bug 81692.  The stack traces for the deadlocked threads follow; I
believe the NTDLL lines are actually NSPR locking primitives.

<srilatha> NTDLL! 77f6829b()
<srilatha> NTDLL! 77f67546()
<srilatha> ldap_abandon_ext(ldap * 0x06785490, int 11, ldapcontrol * *
0x00000000, ldapcontrol * * 0x00000000) line 84 + 151 bytes
<srilatha> nsLDAPOperation::AbandonExt(ldapcontrol * * 0x00000000, ldapcontrol *
* 0x00000000) line 310 + 27 bytes
<srilatha> nsLDAPOperation::Abandon(nsLDAPOperation * const 0x06cc4f10) line
359<srilatha> nsLDAPAutoCompleteSession::OnStopLookup(nsLDAPAutoCompleteSession
* const 0x067b3e04) line 223 + 26 bytes
<srilatha> XPTC_InvokeByIndex(nsISupports * 0x067b3e04, unsigned int 4, unsigned
int 0, nsXPTCVariant * 0x0012be90) line 139
<srilatha> XPCWrappedNative::CallMethod(XPCCallContext & {...},
XPCWrappedNative::CallMode CALL_METHOD) line 1835 + 42 bytes
<srilatha> XPC_WN_CallMethod(JSContext * 0x04bd8750, JSObject * 0x059e2328,
unsigned int 0, long * 0x05ac0720, long * 0x0012c0c4) line 1241 + 11 bytes


<srilatha> NTDLL! 77f6829b()
<srilatha> NTDLL! 77f67546()
<srilatha> wait4msg(ldap * 0x06785490, int -1, int 0, int 1, timeval *
0x00000000, ldapmsg * * 0x06c9ff38) line 349 + 151 bytes
<srilatha> nsldapi_result_nolock(ldap * 0x06785490, int -1, int 0, int 1,
timeval * 0x00000000, ldapmsg * * 0x06c9ff38) line 136 + 29 bytes
<srilatha> ldap_result(ldap * 0x06785490, int -1, int 0, timeval * 0x00000000,
ldapmsg * * 0x06c9ff38) line 94 + 27 bytes
<srilatha> nsLDAPConnection::Run(nsLDAPConnection * const 0x06772d04) line 388 +
22 bytes
<srilatha> nsThread::Main(void * 0x06b57fd0) line 105 + 26 bytes
<srilatha> _PR_NativeRunThread(void * 0x06b54e00) line 399 + 13 bytes
<srilatha> _threadstartex(void * 0x06b54d60) line 212 + 13 bytes
<srilatha> KERNEL32! 77f04ee8()

This is seen with the LDAPCSDK_40_BRANCH.  I'm hoping the answer is "oh yeah,
that's a bug we've fixed since 4.0; you just need to backport these patches". 
In the meantime, I'll be working on getting this rebuilt with debugging symbols
under linux and sorting out more of the context.  This is a very high priority
bug for us, so any help you could provide would be great!

Comment 1

[Michael Hein]

Wionner, Winner, Winner.  Take a look at bugsplat 522577.  The bug change is 
included in the bug....and it is very simple.  Sounds like a match to me.

Comment 2

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: original patch, doesn't apply to LDAPCSDK_40_BRANCH

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

OK, I've just attached the original patch from the bug that Michael mentioned
(thanks!).  It doesn't apply directly to the LDAPCSDK_40_BRANCH, but it should
be trivial to cons up a version that does; I'll do that momentarily.  The
original patch was from [e-mail] and was reviewed by [e-mail].

Comment 4

[Dan Mosedale (:dmosedale, :dmose)]

Attachment: patch tweaked to apply on LDAPCSDK_40_BRANCH

Comment 5

[Dan Mosedale (:dmosedale, :dmose)]

On my Linux box, it was easy for me to reproduce this hang before applying the
patch, but I have been unable to reproduce it after applying.

Comment 6

[David :Bienvenu]

sr=bienvenu

Comment 7

[Dan Mosedale (:dmosedale, :dmose)]

Built and tested on all three platforms.

Comment 8

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to 0.9.1

Comment 9

[Dan Mosedale (:dmosedale, :dmose)]

Fix checked in.

Comment 10

[olga charapaev]

Verified on WinNT 4.0 , MacOS 9.1, Linux RH7.1 unable to reproduce this hang
with 2001053004, 2001060611 builds