Re: Crash in NSPR from within LDAP C-SDK - Bad MDOverlapped struct from GetQueuedCompletionStatus?

LDAP SDK does not create any extra threads in addition to any
threads you create yourself and execute LDAP calls on. NSPR
might, i dunno, could also originate from some Windows lib or
component. you can clarify about NSPR on dev-tech-nspr list,
maybe its a known issue.

On 05/02/2010 18:01, Matthew M. DeLoera wrote:
> Hello,
>
> I'm getting a crash down within NSPR (I'm using C-SDK 6.06, and NSPR
> 4.6.4.0). I'm running in Windows XP. I saw a crash in my release build,
> and I've been running in VS2003 to try and pinpoint it. I rebuilt NSPR
> as debug to get its PDBs.
>
> Anyway, I saw a crash within PR_MD_PAUSE_CPU. It looks like the
> MDOverlapped struct that comes back from GetQueuedCompletionStatus (line
> 301 in ntio.c) is bad. It asserts (PR_ASSERT) down below on line 386,
> where it checks that mdOlp->ioModel == _MD_BlockingIO.
>
> I know next to nothing about NSPR - beyond that the LDAP C-SDK is
> internally using it. I'm only making LDAP calls. But, is it the case
> that LDAP causes some threads to be spun up internally within NSPR? And
> in fact, in VS, I see 3 seemingly identical threads to this one that
> asserted. So, it looks like for some reason, NSPR has at least 4 active
> threads all doing the same thing - handing non-blocking IO.
>
> Where I'm going with this, is - are there always supposed to be NSPR
> threads running in the background? Not knowing NSPR, if I've
> theoretically called ldap_unbind and even ldap_memcache_destroy,
> shouldn't any related NSPR threads or whatnot be stopped also?
>
> I'm testing a failure scenario, where I do a non-blocking bind
> (ldapssl_advclientauth_init, ldapssl_init, ldap_memcache_init,
> ldap_simple_bind), the ldap_simple_bind call fails due to network
> errors, and I call ldap_unbind and ldap_memcache_destroy to clean up. I
> periodically repeat this process.
>
> So, when I would have thought I was all cleaned up, sitting idle, and
> awaiting another change to retry this process, why do I have 5 NSPR
> threads active? Is there something else I should call besides
> ldap_unbind that I just haven't noticed? Is this expected behavior, and
> should I think about this in a different way? I'm wondering if the NSPR
> crash isn't something to do with an internal thread that is in an
> indeterminate state, and hence getting bad IO completion status.
>
> Also, I call ldap_simple_bind in a different, temporary thread. I'm not
> sharing the instance between threads, so shouldn't be any worries there.
> But, could that be related as well?
>
> Hopefully someone can give me a hint of the direction to investigate.
> And, I'm still browsing source for ideas.
>
> Thanks!
> - Matthew
> _______________________________________________
> dev-tech-ldap mailing list
> [email protected]
> https://lists.mozilla.org/listinfo/dev-tech-ldap