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
_______________________________________________ dev-tech-ldap mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-ldap
