Closed Bug 466465 Opened 16 years ago Closed 16 years ago

Unhandled exception in certutil on Windows.

Categories

(NSS :: Tools, defect)

x86
Windows Server 2003
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME
3.12.4

People

(Reporter: slavomir.katuscak+mozilla, Assigned: julien.pierre)

Details

Today I found NSS on Windows Tinderbox hanged with error message about unhandled exception/access violation. Error message: Unhandled exception at 0x7c82f350 in certutil.exe: 0xC0000005: Access violation writing location 0x00000020. I don't have much info yet, there was a choice to open it in debugger/visual studio, so you can look there and analyze what needed. Access info: You can login to machine nss-w2kp via vnc. If you don't know password, contact me directly.
Here's the stack at the time of crash: ntdll.dll!7c82f350() libnspr4.dll!PR_LogPrint(const char * fmt=0x0036e254, ...) Line 499 libnspr4.dll!_PR_Schedule() Line 979 + 0x23 libnspr4.dll!_PR_MD_SWITCH_CONTEXT(PRThread * thread=0x00af3440) Line 468 libnspr4.dll!_PR_CPU_Idle(void * _cpu=0x00af2930) Line 386 + 0x9 libnspr4.dll!_PR_UserRunThread() Line 526 + 0xd libnspr4.dll!_pr_fiber_mainline(void * unused=0x00000000) Line 410 + 0x13 kernel32.dll!77e6608b() kernel32.dll!77e4d21e() The crash apparently occurs in EnterCriticalSection, (which is _MD_LOCK) called from the _PR_LOCK_LOG() macro at line 498 in prlog.c With the debugger, I observe that _pr_logLock is NULL, as is logBuf. In short, the _PR_LOCK_LOG() macro called _PR_LOCK_LOCK(_pr_logLock) with a NULL argument.
i seem to remember hitting this when i was playing w/ pr_asserts.
Summary: Unhandled expcetion in certutil on Windows. → Unhandled exception in certutil on Windows.
Nelson, _pr_logLock is initialized in _PR_InitLog() and freed in _PR_LogCleanup(). If it was NULL, either NSPR initialization was not complete, or NSPR was already shutdown. I think it's probably the later case. certutil contains a call to PR_Cleanup() at the end. There are numerous bugs in PR_Cleanup(). I don't recall running into this particular one before. I don't think PR_Cleanup() is supposed to wait for user threads on termination, by design. So, it may not be a PR_Cleanup bug in this case. Perhaps the application needs to be able to join that thread and make sure it has terminated before it is allowed to call PR_Cleanup(). It would help tremendously if we knew what test case was running, and if a user thread may have been spun as part of that test. certutil itself doesn't create threads. The only PR_CreateThread I see in all of NSS is in lib/ssl, but that's for Unix only.
Slavo, Did this ever happen again ?
Target Milestone: 3.12.3 → 3.12.4
I have seen this failure more times in +- November-December, I haven't seen it since that time.
This is not happening anymore, and there isn't enough information in the prior occurence to work with. Marking WORKSFORME.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.