Closed Bug 511757 Opened 15 years ago Closed 13 years ago

Firefox 3.6.x + winxp Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]

Categories

(Firefox :: General, defect, P2)

3.6 Branch
x86
Windows XP
defect

Tracking

()

RESOLVED INCOMPLETE

People

(Reporter: cww, Assigned: jst)

References

Details

(Keywords: crash, Whiteboard: [3.6.x] maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty])

Crash Data

Attachments

(2 files)

1512 total crashes for RtlpWaitForCriticalSection on 20090817 192 start up crashes inside 3 minutes 358.599 (days) total uptime for 1330 of these crashes where user crashed within the last year 388.257 (minutes) avg time since last crash distribution of versions where the crash was found on 20090817 519 Firefox 3.5.2 58 Firefox 3.5b4 34 Firefox 3.0.12 33 Firefox 3.5 25 Firefox 3.1b3 22 Firefox 3.0.11 17 Firefox 3.0.10 13 Firefox 3.5.1 9 Firefox 3.0.8 9 Firefox 3.0.1 7 Firefox 3.0.6 6 Firefox 3.0.5 5 Firefox 3.0.7 5 Firefox 3.0 2 Firefox 3.0.4 2 Firefox 3.0.3 1 Firefox 3.6a1pre 1 Firefox 3.0b1 1 Firefox 3.0.9 1 Firefox 3.0.12pre
on user mentions being on futoncritic when the crash happend Trying to us "http://www.thefutoncritic.com/home.aspx". In the listing section, click on >> to get calendar. Select September 25. Abort. foutoncritic has worked before, but not always on the first try. see: http://crash-stats.mozilla.com/report/index/ca67b48b-0461-4d70-aab4-eeb712090820 that stack has mostly flash in it... in fact, quite a few people have flash crashes when visiting that site. 17 CFReadStreamGetStatus http://www.thefutoncritic.com/breakingnews.aspx 6 Flash Player@0x91bd0 http://thefutoncritic.com/breakingnews.aspx 5 Flash Player@0x91bd0 http://www.thefutoncritic.com/breakingnews.aspx 4 nsSubDocumentFrame 3 Flash_EnforceLocalSecurity http://www.thefutoncritic.com/breakingnews.aspx 2 Flash Player@0xe70fa http://www.thefutoncritic.com/breakingnews.aspx 2 Flash Player@0xe70fa http://thefutoncritic.com/breakingnews.aspx 2 Flash Player@0x91d10 http://www.thefutoncritic.com/breakingnews.aspx 2 Flash Player@0x91ac4 http://thefutoncritic.com/breakingnews.aspx 2 Flash Player@0x11e340 http://www.thefutoncritic.com/breakingnews.aspx 1 user32.dll@0x8815 http://www.thefutoncritic.com/breakingnews.aspx 1 strcmp | Flash Player@0x122084 http //thefutoncritic.com/breakingnews.aspx 1 send http //www.thefutoncritic.com/breakingnews.aspx 1 ntdll.dll@0x43387 http //www.thefutoncritic.com/breakingnews.aspx 1 ntdll.dll@0x1f1a http //www.thefutoncritic.com/breakingnews.aspx 1 memmove http //www.thefutoncritic.com/breakingnews.aspx 1 js_Interpret http //thefutoncritic.com/breakingnews.aspx 1 js_FullTestPropertyCache http //thefutoncritic.com/breakingnews.aspx 1 canonicalize(nsISupports*) http //thefutoncritic.com/breakingnews.aspx 1 _requestread http //www.thefutoncritic.com/breakingnews.aspx 1 TRACE_WININET_HTTP_RESPONSE_RECEIVED(int, void*, void*, char const*, char const*) http //www.thefutoncritic.com/breakingnews.aspx 1 PostMessageEvent 1 PayPalPlugin.dll@0x1be71 http //www.thefutoncritic.com/breakingnews.aspx 1 NSSRWLock_LockRead_Util http //www.thefutoncritic.com/breakingnews.aspx 1 NPSWF32.dll@0x9079b http //www.thefutoncritic.com/breakingnews.aspx 1 NPSWF32.dll@0x3486f http //www.thefutoncritic.com/breakingnews.aspx 1 NPSWF32.dll@0x21b8aa http //www.thefutoncritic.com/breakingnews.aspx 1 NPSWF32.dll@0x1744e9 http //www.thefutoncritic.com/breakingnews.aspx 1 NPSWF32.dll@0x173102 http //www.thefutoncritic.com/breakingnews.aspx 1 ICF.dll@0x1db94 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xf96db http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xee614 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xe8708 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xe6c4d http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xe61fd http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xdb068 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xb24e2 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xb23ca http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0xb1b9e http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x91d10 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x91ac4 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x91ac4 http //thefutoncritic.com/latestnews.aspx 1 Flash Player@0x91a13 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x91a13 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x8f8e4 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x86173 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x843ac http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x3f6ebd http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x2dce49 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x2ce3c2 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x2c6035 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x2bcb1c http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x2b7108 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x1b8be6 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x1b8be6 http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x17efbe http //thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x15dbb2 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x122657 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x1202a4 http //thefutoncritic.com/latestnews.aspx 1 Flash Player@0x11efd8 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x11e7e2 http //www.thefutoncritic.com/breakingnews.aspx 1 Flash Player@0x119fc8 http //www.thefutoncritic.com/breakingnews.aspx 1 CoreFoundation@0x8648b http //www.thefutoncritic.com/breakingnews.aspx 1 CoreFoundation@0x8646b http //www.thefutoncritic.com/breakingnews.aspx 1 CoreFoundation@0x6f78d http //www.thefutoncritic.com/breakingnews.aspx 1 CFReadStreamGetStatus http //www.thefutoncritic.com/showatch.aspx?id=mythbusters&view=listings 1 CFReadStreamGetStatus http //thefutoncritic.com/breakingnews.aspx 1 @0x61636f6c http //www.thefutoncritic.com/breakingnews.aspx 1 @0x41414141 http //www.thefutoncritic.com/breakingnews.aspx 1 @0x26133f89 http //www.thefutoncritic.com/breakingnews.aspx 1 @0x13db6a1c http //thefutoncritic.com/breakingnews.aspx 1 @0x0 | nsIFrame 1 @0x0 | SGPrxy.dll@0x24fe http //thefutoncritic.com/breakingnews.aspx 1 @0x0 | Flash Player@0x169643 http //thefutoncritic.com/breakingnews.aspx 1 @0x0 | Flash Player@0x15bb30 http //www.thefutoncritic.com/breakingnews.aspx 1 @0x0 | Flash Player@0x122808 http //www.thefutoncritic.com/breakingnews.aspx
Whiteboard: maybe related to CFReadStreamGetStatus and other flash crash signatures
stack for http://crash-stats.mozilla.com/report/index/ca67b48b-0461-4d70-aab4-eeb712090820 in case that goes away Frame Module Signature [Expand] Source 0 ntdll.dll RtlpWaitForCriticalSection 1 ntdll.dll RtlEnterCriticalSection 2 wininet.dll HttpOpenRequestA 3 NPSWF32.dll NPSWF32.dll@0x14d7ff 4 NPSWF32.dll NPSWF32.dll@0x5e53c 5 NPSWF32.dll NPSWF32.dll@0x5eb56 6 NPSWF32.dll NPSWF32.dll@0x5ec5a 7 NPSWF32.dll NPSWF32.dll@0x5ef00
another user comment on this signature is "had pandora site running and had another window up which when closed caused ff to crash" here is a sample of the url's other pandora vistors where on when they hit this crash. 20090818-crashdata.csv:RtlpWaitForCriticalSection http://pandora.com/#/song/thumbs-up/S118948 \N 20090818-crashdata.csv:RtlpWaitOnCriticalSection http://www.pandora.com/#/volume/100 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://pandora.com/#/extras/about \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/song/thumbs-down/S26581 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/stations/play/102797027280464354 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://pandora.com/ \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/song/thumbs-up/S10057 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/song/thumbs-down/S1381168 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://pandora.com/#/song/thumbs-up/S558855 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/ \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/stations/play/102797027280464354 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/paused \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/song/thumbs-down/S541987 \N 20090818-crashdata.csv:RtlpWaitForCriticalSection http://www.pandora.com/#/song/skip/S50356 \N RtlpWaitForCriticalSection http://www.pandora.com/#/song/skip/S1267147 \N RtlpWaitForCriticalSection http://www.pandora.com/ \N RtlpWaitForCriticalSection http://pandora.com/#/playlist/why/second \N RtlpWaitForCriticalSection http://www.pandora.com/#/stations/variety/32933160688617810 \N RtlpWaitForCriticalSection http://www.pandora.com/#/stations/play/124327333212712066 \N RtlpWaitForCriticalSection http://pandora.com/#/song/skip/S486307 \N RtlpWaitForCriticalSection http://www.pandora.com/#/song/skip/S382749 \N RtlpWaitForCriticalSection http://pandora.com/ \N RtlpWaitForCriticalSection http://www.pandora.com/#/song/sleep/S359952 \N RtlpWaitForCriticalSection http://www.pandora.com/#/song/skip/S873482 \N RtlpWaitForCriticalSection http://pandora.com/#/stations/play/164860640429249503 \N RtlpWaitForCriticalSection http://www.pandora.com/#/stations/play/111959188948772288 \N RtlpWaitForCriticalSection http://www.pandora.com/#/song/skip/S909595 \N RtlpWaitForCriticalSection http://pandora.com/#/stations/play/69476645206203466 \N RtlpWaitForCriticalSection http://www.pandora.com/#/ \N RtlpWaitOnCriticalSection http://pandora.com/#/ \N
Some of these crashers should have been fixed in Flash Player 10r32. Are any of these crashers in that version?
Summary: Crash at [RtlpWaitForCriticalSection] → Crash at [@ RtlpWaitForCriticalSection]
Blocks: 518287
here is a sample of 306 of the 1609 RtlpWaitForCriticalSection crashes we got on 2009 09 20. 57 of these crashes show no flash involved where flash is present here are counts of the versions 5 10.0.12.36 26 10.0.22.87 64 10.0.32.18 1 8.0.24.0
Keywords: topcrash
Assignee: nobody → jst
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
Blocks: 520639
note to self: we should try another run to see which versions are crashing now.
Whiteboard: maybe related to CFReadStreamGetStatus and other flash crash signatures → maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill]
Can we get a list of URLs that crash using Flash 10.0.32.18 then test to see if we can reproduce those crashes using Flash 10.0.32.18? Who can own doing that?
we don't have plugin version info accessible in the url report, and its really painful to dig out of indivual reports, but here is the set of most frequent crashes on this signature, along with crash counts for 2009 11 06, and the firefox version number 166 RtlpWaitForCriticalSection 3.5b4 104 RtlpWaitForCriticalSection 3.1b3 65 RtlpWaitForCriticalSection 3.5.4 \N 41 RtlpWaitForCriticalSection 3.5b5pre 36 RtlpWaitForCriticalSection 3.0.15 \N 33 RtlpWaitForCriticalSection 3.5.4 27 RtlpWaitForCriticalSection 3.0.15 26 RtlpWaitForCriticalSection 3.5.5 \N 20 RtlpWaitForCriticalSection 3.0.15 http://home.myspace.com/index.cfm?fuseaction=user 17 RtlpWaitForCriticalSection 3.5.4 http://home.myspace.com/index.cfm?fuseaction=user 14 RtlpWaitForCriticalSection 3.5.5 http://home.myspace.com/index.cfm?fuseaction=user 14 RtlpWaitForCriticalSection 3.5.5 12 RtlpWaitForCriticalSection 3.5.4 about:blank 9 RtlpWaitForCriticalSection 3.5.5 about:blank 9 RtlpWaitForCriticalSection 3.5.4 http://www.verizonwireless.com/b2c/index.html 9 RtlpWaitForCriticalSection 3.0.15 http://www.verizonwireless.com/b2c/index.html 9 RtlpWaitForCriticalSection 3.0.15 http://espn.go.com/ 9 RtlpWaitForCriticalSection 3.0.15 about:blank 8 RtlpWaitForCriticalSection 3.5.4 http://www.google.com.br/ 8 RtlpWaitForCriticalSection 3.5.3 \N 7 RtlpWaitForCriticalSection 3.5.4 http://www.aljazeera.net/Portal 7 RtlpWaitForCriticalSection 3.5.4 http://mail.live.com/default.aspx?wa=wsignin1.0 7 RtlpWaitForCriticalSection 3.0.15 http://www.nytimes.com/ 6 RtlpWaitForCriticalSection 3.5.5 http://www.google.com.br/ 6 RtlpWaitForCriticalSection 3.5.4 http://www.nytimes.com/ 6 RtlpWaitForCriticalSection 3.5.4 http://espn.go.com/ 5 RtlpWaitForCriticalSection 3.5.4 about:sessionrestore 5 RtlpWaitForCriticalSection 3.0.14 http://home.myspace.com/index.cfm?fuseaction=user 4 RtlpWaitForCriticalSection 3.5.5 http://www.maxnettv.tv/index.php 4 RtlpWaitForCriticalSection 3.5.5 http://www.aljazeera.net/Portal 4 RtlpWaitForCriticalSection 3.5.4 http://search.orbitdownloader.com/ 4 RtlpWaitForCriticalSection 3.5.3 4 RtlpWaitForCriticalSection 3.0.15 http://mail.live.com/default.aspx?wa=wsignin1.0 3 RtlpWaitForCriticalSection 3.5.5 http://www.verizonwireless.com/b2c/index.html 3 RtlpWaitForCriticalSection 3.5.5 http://www.bild.de/BILD/news/2009/11/06/Busen-brueste-unfall-video-england/maedchen-jungen-auto.html 3 RtlpWaitForCriticalSection 3.5.5 http://search.orbitdownloader.com/ 3 RtlpWaitForCriticalSection 3.5.4 http://xhamster.com/chat.php 3 RtlpWaitForCriticalSection 3.5.4 http://www.facebook.com/home.php? 3 RtlpWaitForCriticalSection 3.5.3 http://home.myspace.com/index.cfm?fuseaction=user 3 RtlpWaitForCriticalSection 3.5.3 about:sessionrestore 3 RtlpWaitForCriticalSection 3.5.3 about:blank 3 RtlpWaitForCriticalSection 3.5 about:blank 3 RtlpWaitForCriticalSection 3.0a8 http://www.facebook.com/ 3 RtlpWaitForCriticalSection 3.0.14 \N 3 RtlpWaitForCriticalSection 3.0.13 \N 3 RtlpWaitForCriticalSection 3.0.10 3 RtlpWaitForCriticalSection 3.0.1 http://www.justin.tv/survivorseries 3 RtlpWaitForCriticalSection 3.0.1
This hasn't been touched since November 9th; Damon, do we think this really still blocks release?
the analysis is lead us to believe this is a crash in flash so blocking fx3.6 doesn't make sense. it will take a fix to flash, or some new discovery to fix this.
Not blocking as per comment 17; probably needs to move to Core::Plugins or somewhere?
Flags: blocking-firefox3.6+ → blocking-firefox3.6-
Whiteboard: maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill] → maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty]
Summary: Crash at [@ RtlpWaitForCriticalSection] → Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]
Bug 520639 comment 6 leads me to think comment 17 is wrong.
ok, good catch bz. renominating. should this be duped/depend on bug 520639?
Flags: blocking-firefox3.6- → blocking-firefox3.6?
Bug 520639 is now resolved; does that give us the required insight to close this one out, too, or at least inform a blocking decision? What are the stats telling us?
It doesn't look like bbu 520639 hasn't landed in a beta yet or reach 100-200k users. here is what the profile of RtlpWaitForCriticalSection crashes looked like for 3.6b4 date #crashes #users crash/user ratio 20091125-crashdata.csv 5 159 0.031447 20091126-crashdata.csv 14 11003 0.001272 20091127-crashdata.csv 79 101832 0.000776 20091128-crashdata.csv 109 208895 0.000522 20091129-crashdata.csv 135 262879 0.000514 20091201-crashdata.csv 151 318380 0.000474 20091202-crashdata.csv 176 354012 0.000497 20091203-crashdata.csv 140 377984 0.000370 20091204-crashdata.csv 198 394451 0.000502 Once the fix out in a beta/RC then I think we could compare against the ~0.0005 crash rate.
OK, not going to block final release on this since our next milestone is RC, but we should track it for a security fix / blocker if it doesn't drop off enough in RC
Flags: blocking-firefox3.6? → blocking-firefox3.6-
Whiteboard: maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty] → [3.6.x] maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty]
Why is this bug still security sensitive? I haven't seen any comments explaining what the security issue is.
Whiteboard: [3.6.x] maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty] → [sg:investigate][3.6.x] maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty]
still hard to tell if there is any relative reduction from previous releases in beta5 here is a sample of the pct of all crashes by release checking --- 20091222-crashdata.csv RtlpWaitForCriticalSection release total-crashes RtlpWaitForCriticalSection crashes pct. all 218294 3488 0.0159785 3.0.15 5195 46 0.00885467 3.0.16 32935 658 0.0199787 3.5.5 13733 149 0.0108498 3.5.6 111865 1655 0.0147946 3.6b5 17985 268 0.0149013 3.6b4 3501 69 0.0197087 3.6b3 731 1 0.00136799 3.6b2 611 7 0.0114566 3.6b1 2121 39 0.0183876 and here is a sample of the early trend for 3.6b5 crashes #crashes #users crash/user ratio 20091219-crashdata.csv 183 50978 0.003590 20091220-crashdata.csv 184 259273 0.000710 20091221-crashdata.csv 224 na na 20091222-crashdata.csv 268 486443 0.000551 I think this was just one of cww early crash bug filings that all go marked security sensitive. probably ok to open up.
opening.
Group: core-security
still showing up at a higher rate than should be expected for early 3.6 rc1 data, and slightly higher rate than expected in 3.6b5 checking --- 20100110-crashdata.csv RtlpWaitForCriticalSection...RtlEnterCriticalSection release total-crashes RtlpWaitForCriticalSection...RtlEnterCriticalSection crashes pct. all 215352 2567 0.01192 3.0.15 1958 13 0.00663943 3.0.16 4940 46 0.00931174 3.5.5 5270 46 0.00872865 3.5.6 16510 127 0.00769231 3.5.7 102593 1037 0.0101079 3.6 10425 422 0.0404796 3.6b5 14884 228 0.0153185 3.6b4 1505 16 0.0106312 3.6b3 721 4 0.00554785 3.6b2 729 5 0.00685871 3.6b1 2102 35 0.0166508
continuing to be the #2 top crash for 3.6 and #4 for 3.5.7 checking --- 20100215-crashdata.csv RtlpWaitForCriticalSection...RtlEnterCriticalSection release total-crashes RtlpWaitForCriticalSection...RtlEnterCriticalSection crashes pct. all 254301 2747 0.0108022 3.5.7 117488 1113 0.00947331 3.6 82800 1026 0.0123913 3.7a1 358 4 0.0111732 3.7a1pre281 2 0.00711744
Whiteboard: [sg:investigate][3.6.x] maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty] → [3.6.x] maybe related to CFReadStreamGetStatus and other flash crash signatures [crashkill][crashkill-thirdparty]
so the fixes for 520639 are in 3.6 but as jst comments: I suspect that there's far more causes for this than what can be covered in any one bug. any ideas on how we can start the next round of investigations to parse out the next set of bugs that may be lurking on either side of the npapi, or entirely other areas? I looked at a sample of 100 crashes from 2/15 and here is the distribution of flash versions 9 NPSWF32.dll 10.0.45.2 38 NPSWF32.dll 10.0.42.34 18 NPSWF32.dll 10.0.32.18 11 NPSWF32.dll 10.0.22.87 1 6 NPSWF32.dll 10.0.12.36 18 no flash version appears to be loaded
looking at a few of the stacks that have no flash they look like Frame Module Signature [Expand] Source 0 ntdll.dll RtlpWaitForCriticalSection 1 ntdll.dll RtlEnterCriticalSection 2 nspr4.dll PR_Lock nsprpub/pr/src/threads/combined/prulock.c:233 3 xul.dll XPCJSRuntime::XPCJSRuntime js/src/xpconnect/src/xpcjsruntime.cpp:1119 4 xul.dll XPCJSRuntime::newXPCJSRuntime js/src/xpconnect/src/xpcjsruntime.cpp:1132 5 xul.dll nsXPConnect::nsXPConnect js/src/xpconnect/src/nsXPConnect.cpp:91 6 xul.dll nsXPConnect::GetXPConnect js/src/xpconnect/src/nsXPConnect.cpp:178 7 xul.dll nsIXPConnectConstructor js/src/xpconnect/src/xpcmodule.cpp:68 8 xul.dll nsGenericFactory::CreateInstance obj-firefox/xpcom/build/nsGenericFactory.cpp:80 9 xul.dll nsComponentManagerImpl::CreateInstanceByContractID xpcom/components/nsComponentManager.cpp:1687 10 xul.dll nsComponentManagerImpl::GetServiceByContractID xpcom/components/nsComponentManager.cpp:2253 11 xul.dll nsCOMPtr_base::assign_from_gs_contractid_with_error obj-firefox/xpcom/build/nsCOMPtr.cpp:141 12 xul.dll mozJSComponentLoader::ReallyInit js/src/xpconnect/loader/mozJSComponentLoader.cpp:573 13 xul.dll mozJSComponentLoader::LoadModule js/src/xpconnect/loader/mozJSComponentLoader.cpp:668 14 xul.dll nsComponentManagerImpl::AutoRegisterComponent xpcom/components/nsComponentManager.cpp:3042 15 xul.dll nsLocalFile::IsDirectory xpcom/io/nsLocalFileWin.cpp:2453 16 xul.dll nsComponentManagerImpl::AutoRegisterImpl xpcom/components/nsComponentManager.cpp:2916 17 xul.dll nsStaticModuleLoader::EnumerateModules xpcom/components/nsStaticComponentLoader.cpp:141 18 xul.dll nsComponentManagerImpl::AutoRegister xpcom/components/nsComponentManager.cpp:3328 I guess that might be the first bug to spin off and we could turn this into a tracking bug.
I wonder if some skip list hackerery would help this. here are a couple more stacks that seem to confirm jst's idea that this is a wide array of problems. http://crash-stats.mozilla.com/report/index/011e00b2-21a3-45c8-adf7-a93a42100215 Frame Module Signature [Expand] Source 0 ntdll.dll RtlpWaitForCriticalSection 1 ntdll.dll RtlEnterCriticalSection 2 imon.dll imon.dll@0x453d 3 @0x7252bc3 4 NPSWF32.dll NPSWF32.dll@0x150c54 5 NPSWF32.dll NPSWF32.dll@0x155294 6 ntdll.dll RtlEnterCriticalSection 7 NPSWF32.dll NPSWF32.dll@0x5dedd 8 NPSWF32.dll NPSWF32.dll@0x5ee5c 9 NPSWF32.dll NPSWF32.dll@0x14fda4 10 NPSWF32.dll NPSWF32.dll@0x14fde2 11 kernel32.dll BaseThreadStart 12 kernel32.dll GetCodePageFileInfo 13 kernel32.dll BaseThreadStart 14 NPSWF32.dll NPSWF32.dll@0x14fdd9 http://crash-stats.mozilla.com/report/index/012186c6-058b-4c48-93c4-e57992100215 Frame Module Signature [Expand] Source 0 ntdll.dll RtlpWaitForCriticalSection 1 ntdll.dll RtlEnterCriticalSection 2 quartz.dll quartz.dll@0x16d80 3 quartz.dll quartz.dll@0x1ba07 4 quartz.dll quartz.dll@0x2c538 5 quartz.dll quartz.dll@0x2d0df 6 quartz.dll quartz.dll@0x24c9a 7 quartz.dll quartz.dll@0x24fc3 8 quartz.dll quartz.dll@0x24f22 9 msdxm.ocx CdxmPlay::InternalOpen 10 msdxm.ocx CdxmPlay::PutUrlWorker 11 msdxm.ocx LaunchIfRadio 12 msdxm.ocx CdxmPlay::Play 13 oleaut32.dll DispCallFunc 14 oleaut32.dll CTypeInfo2::Invoke 15 oleaut32.dll CTypeInfo2::Invoke 16 msdxm.ocx ATL::CComObjectRootBase::_Delegate 17 msdxm.ocx ATL::IDispatchImpl<IMediaPlayerDvd,&_GUID const IID_IMediaPlayerDvd,&_GUID const LIBID_MediaPlayer,1,0,ATL::CComTypeInfoHolder>::GetIDsOfNames 18 npdsplay.dll npdsplay.dll@0x33787 19 npdsplay.dll npdsplay.dll@0x189cf 20 npdsplay.dll npdsplay.dll@0x2be4a 21 npdsplay.dll npdsplay.dll@0xac6a 22 npdsplay.dll npdsplay.dll@0xefcd 23 npdsplay.dll npdsplay.dll@0xf90d 24 npdsplay.dll npdsplay.dll@0xf81f 25 xul.dll nsNPAPIPluginStreamListener::CleanUpStream modules/plugin/base/src/nsNPAPIPluginInstance.cpp:160 26 xul.dll nsCOMPtr_base::assign_from_qi obj-firefox/xpcom/build/nsCOMPtr.cpp:98 27 xul.dll nsCOMPtr<nsINPAPIPluginStreamInfo>::nsCOMPtr<nsINPAPIPluginStreamInfo> obj-firefox/dist/include/xpcom/nsCOMPtr.h:573 28 xul.dll nsNPAPIPluginStreamListener::OnStopBinding modules/plugin/base/src/nsNPAPIPluginInstance.cpp:678 29 xul.dll nsPluginStreamListenerPeer::OnStopRequest modules/plugin/base/src/nsPluginHostImpl.cpp:2270 30 xul.dll nsBaseChannel::Cancel netwerk/base/src/nsBaseChannel.cpp:340 31 @0x3cb155f
yes, please skip list.
I have yet to reproduce this issue using the provided URLs but we have make some changes in the latest 10.1 beta release (10.1.51.95) that I would hope to see some trending down on this crash. I have been trying to use the tools to get the data but its been difficult.
ok, I spotted another correlation that might be helpful. this is 100% windows 95 in a data sample from checking --- 20100403-crashdata.csv RtlpWaitForCriticalSection os breakdown 1913 0.468184 Windows NT5.1.2600 Service Pack 2 1863 0.455947 Windows NT5.1.2600 Service Pack 3 106 0.0259422 Windows NT5.1.2600 Service Pack 1 69 0.0168869 Windows NT5.1.2600 29 0.00709741 Windows NT5.1.2600 Dodatek Service Pack 2 25 0.00611845 Windows NT5.1.2600 Szervizcsomag 3 24 0.00587372 Windows NT5.1.2600 Dodatek Service Pack 3 16 0.00391581 Windows NT5.1.2600 Szervizcsomag 2 10 0.00244738 Windows NT5.1.2600 Dodatek Service Pack. 1 7 0.00171317 Windows NT5.1.2600 Service Pack 3, v.5657 6 0.00146843 Windows NT5.1.2600 Szervizcsomag 1 5 0.00122369 Windows NT5.1.2600 Service Pack 3, v.5913 4 0.000978953 Windows NT5.1.2600 Service Pack 3, v.5857 3 0.000734214 Windows NT5.1.2600 Service Pack 3, v.3244 2 0.000489476 Windows NT5.1.2600 Service Pack 3, v.5512
Summary: Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection] → Firefox 3.6.x + win95 Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]
Blocks: 557161
NT 5.1 is xp.
Summary: Firefox 3.6.x + win95 Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection] → Firefox 3.6.x + winxp Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]
Summary: Firefox 3.6.x + winxp Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection] → Firefox 3.6.x + win9x Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]
Chris, Why did you change the subject again? NT 5.1 is WinXP as Bob said in comment #35. Moreover, Firefox 3.6 will not even start on Win9x. This bug should be closed as WONTFIX if crash is really occurs on Win9x because we does no longer support Win9x.
ok, sorry for the os version mix up.
Summary: Firefox 3.6.x + win9x Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection] → Firefox 3.6.x + winxp Crash at [@ RtlpWaitForCriticalSection][@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]
After recent upgrade to FF 3.6.3 many heiaheia.com users started reporting random crashes (definitely not Flash related) on the site. One crash log: http://crash-stats.mozilla.com/report/index/bp-e2a33e6f-cf03-41ed-8eee-793692100422 To comment #24: it seems to be crashing in SECURITY_CREDENTIALS::DereferenceCredentials - might be the reason why this bug was indicated as security related. Although there are a lot of other stacks where crash occures in totally different places. We are collecting crash logs from users on our site to see if there's any pattern and a reliable way to reproduce this problem.
Please run some of the mdmps through the submitted Flash player symbols and report back with call stack info. I can then determine if the affected code has been patched in the latest Player. BTW, this currently 'WORKSFORME' but a proper backtrace will help me get closer to a 'FIXED' diagnosis.
correlation is not causation but still a lot of instances where 10.1 is around when crashes happen at this signature.
Keywords: crash
Crash Signature: [@ RtlpWaitForCriticalSection] [@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]
Crash Signature: [@ RtlpWaitForCriticalSection] [@ RtlpWaitForCriticalSection | RtlEnterCriticalSection] → [@ RtlpWaitForCriticalSection] [@ RtlpWaitForCriticalSection | RtlEnterCriticalSection]
Version: unspecified → 3.6 Branch
Removing the top crash keyword since it's at #65 in 8.0 over the past week. Not sure what we can do about fixing this. Seems like we have a few bugs logged with this signature related to plug in issues.
Keywords: topcrash
Depends on: 720655
Now that RtlEnterCriticalSection is in the skiplist, I close it as incomplete.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: