Closed
Bug 466465
Opened 16 years ago
Closed 16 years ago
Unhandled exception in certutil on Windows.
Categories
(NSS :: Tools, defect)
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.
Comment 1•16 years ago
|
||
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.
Summary: Unhandled expcetion in certutil on Windows. → Unhandled exception in certutil on Windows.
Assignee | ||
Comment 3•16 years ago
|
||
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.
Assignee | ||
Comment 4•16 years ago
|
||
Slavo,
Did this ever happen again ?
Target Milestone: 3.12.3 → 3.12.4
Reporter | ||
Comment 5•16 years ago
|
||
I have seen this failure more times in +- November-December, I haven't seen it since that time.
Assignee | ||
Comment 6•16 years ago
|
||
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.
Description
•