Closed Bug 511759 Opened 16 years ago Closed 16 years ago

Frequent crashes at [@ RtlpWaitOnCriticalSection]

Categories

(Firefox :: General, defect, P2)

x86
Windows XP
defect

Tracking

()

VERIFIED INCOMPLETE

People

(Reporter: cww, Assigned: jst)

References

Details

(Keywords: topcrash, Whiteboard: [crashkill])

Crash Data

Attachments

(1 file)

The stacks all seem to be different, with most of them leading into various plugins (flash is most common) or other libraries that we don't control.
Summary: Crash at [RtlpWaitOnCriticalSection] → Crash at [@ RtlpWaitOnCriticalSection]
Group: core-security
Filed bug 514505 on splitting up these crash signatures.
Attached file Crash stack analysis
This is jumping a lot in the number of reports so I wrote a quick perlscript to analyze the stacks. Attached is the result of parsing 500 crash-stacks Shown is number of crash reports with the given property or the given line in either the modules list or the crashing thread.
i see quite a few lsp's floating around, that's where i'd first point blame
http://dbaron.org/log/20090922-crashes shows a whole bunch of libraries that could be relevant: RtlpWaitOnCriticalSection (64 crashes) 98% (63/64) vs. 20% (1428/7100) avrt.dll 98% (63/64) vs. 20% (1432/7100) MMDevAPI.dll 97% (62/64) vs. 20% (1415/7100) credssp.dll 97% (62/64) vs. 20% (1424/7100) AudioSes.dll 100% (64/64) vs. 25% (1753/7100) WindowsCodecs.dll 100% (64/64) vs. 25% (1771/7100) NapiNSP.dll 100% (64/64) vs. 25% (1772/7100) nlaapi.dll 100% (64/64) vs. 25% (1791/7100) Wldap32.dll 100% (64/64) vs. 25% (1800/7100) winnsi.dll 100% (64/64) vs. 25% (1805/7100) IPHLPAPI.DLL 100% (64/64) vs. 25% (1807/7100) WSHTCPIP.DLL 100% (64/64) vs. 26% (1822/7100) propsys.dll 100% (64/64) vs. 26% (1825/7100) nsi.dll 100% (64/64) vs. 26% (1837/7100) dwmapi.dll 100% (64/64) vs. 27% (1883/7100) wship6.dll 98% (63/64) vs. 25% (1787/7100) pnrpnsp.dll 100% (64/64) vs. 28% (2006/7100) powrprof.dll 98% (63/64) vs. 27% (1932/7100) ksuser.dll 89% (57/64) vs. 18% (1311/7100) AudioEng.dll 92% (59/64) vs. 24% (1700/7100) dhcpcsvc6.DLL 100% (64/64) vs. 39% (2767/7100) lpk.dll 91% (58/64) vs. 31% (2167/7100) oleacc.dll 52% (33/64) vs. 4% (280/7100) imon.dll 100% (64/64) vs. 53% (3748/7100) rsaenh.dll 92% (59/64) vs. 45% (3210/7100) dhcpcsvc.dll 100% (64/64) vs. 61% (4327/7100) msctf.dll 45% (29/64) vs. 7% (524/7100) SensApi.dll 100% (64/64) vs. 66% (4694/7100) normaliz.dll 44% (28/64) vs. 11% (746/7100) EhStorShell.dll 100% (64/64) vs. 67% (4769/7100) iertutil.dll ...
52% (33/64) vs. 4% (280/7100) imon.dll is NOD32 Antivirus, nod32.com
Keywords: topcrash
Assignee: nobody → jst
(mostly changing the title so that this gets linked in crash-stats, as per lars' suggestion - trying to figure out why it hasn't been to date)
Summary: Crash at [@ RtlpWaitOnCriticalSection] → Frequent crashes at [@ RtlpWaitOnCriticalSection]
We really need to get bug 514505 fixed to get this split into a more unique set of crashes. As it stands, this is just "a bunch of places where someone calls a system library function with bad data." It's like having |free()| as a topcrash.
blocking 3.6+ per CrashKill effort.
Flags: blocking-firefox3.6+
Marking all topcrash bugs as P2 (3.6 release blockers, but not 3.6b1 blockers)
Priority: -- → P2
Whiteboard: [crashkill]
from memory, the following are from ms and are or should be relatively uninteresting: Wldap32.dll winnsi.dll IPHLPAPI.DLL WSHTCPIP.DLL propsys.dll nsi.dll dwmapi.dll (display window manager) wship6.dll (ipv6) pnrpnsp.dll powrprof.dll (this is from microsoft, but i don't recall seeing it normally) ksuser.dll (audio subsystem) AudioEng.dll dhcpcsvc6.DLL (ipv6) lpk.dll (language pack) oleacc.dll (ole automation) rsaenh.dll dhcpcsvc.dll msctf.dll SensApi.dll normaliz.dll what might be interesting is why some of them are loaded (although quite a few of these are fairly normally and totally not worth even thinking about) imon.dll is either norton or a pest.
Depends on: 514505
I do get the same on vista.
fwiw, bug 527540 is clearly a buggy lsp.
Damon: do we still think this blocks?
bug 514505 is fixed, so this should not be showing up in topcrash lists anymore. Separate bugs can be filed for the individual crashes that show up.
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: blocking-firefox3.6+ → blocking-firefox3.6-
Resolution: --- → INCOMPLETE
Status: RESOLVED → VERIFIED
Crash Signature: [@ RtlpWaitOnCriticalSection]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: