Crash in [@ js::GCMarker::processMarkStackTop ] from heap corruption
Categories
(Core :: JavaScript: GC, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox42 | --- | wontfix |
firefox43 | --- | wontfix |
firefox44 | --- | wontfix |
firefox45 | --- | wontfix |
firefox46 | --- | wontfix |
firefox47 | --- | wontfix |
firefox-esr38 | --- | wontfix |
firefox-esr52 | --- | wontfix |
firefox-esr60 | --- | wontfix |
firefox-esr91 | --- | wontfix |
firefox56 | --- | wontfix |
firefox57 | --- | wontfix |
firefox58 | --- | wontfix |
firefox59 | --- | wontfix |
firefox60 | --- | wontfix |
firefox61 | - | wontfix |
firefox62 | - | wontfix |
firefox95 | --- | wontfix |
People
(Reporter: Swarnava, Unassigned)
References
(Depends on 2 open bugs, Blocks 1 open bug)
Details
(7 keywords, Whiteboard: [unactionable], ShutDownKill)
Crash Data
Attachments
(4 files, 1 obsolete file)
This bug was filed from the Socorro interface and is report bp-bae5f557-0c48-4e17-9248-85d812120116 . ============================================================= 0 mozjs.dll js::GCMarker::processMarkStackTop js/src/jsgcmark.cpp:1133 1 mozjs.dll js::GCMarker::drainMarkStack js/src/jsgcmark.cpp:1171 2 mozjs.dll EndMarkPhase js/src/jsgc.cpp:2547 3 mozjs.dll MarkAndSweep js/src/jsgc.cpp:2710 4 mozjs.dll GCCycle js/src/jsgc.cpp:2941 5 mozjs.dll js_GC js/src/jsgc.cpp:3010 6 mozjs.dll JS_GC js/src/jsapi.cpp:2750 7 xul.dll nsXPConnect::Collect js/xpconnect/src/nsXPConnect.cpp:412 8 xul.dll nsXPConnect::GarbageCollect js/xpconnect/src/nsXPConnect.cpp:420 9 xul.dll nsJSContext::GarbageCollectNow dom/base/nsJSEnvironment.cpp:3231 10 xul.dll mozilla::Preferences::RemoveObserver obj-firefox/dist/include/mozilla/Preferences.h:76 11 xul.dll nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:428 12 xul.dll nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:524 13 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:660 14 nspr4.dll PR_Unlock nsprpub/pr/src/threads/combined/prulock.c:347 15 xul.dll MessageLoop::RunHandler ipc/chromium/src/base/message_loop.cc:201 16 xul.dll _SEH_epilog4 17 xul.dll MessageLoop::Run ipc/chromium/src/base/message_loop.cc:175 18 xul.dll mozilla::imagelib::RasterImage::UnlockImage image/src/RasterImage.cpp:2673 19 xul.dll nsBaseAppShell::Run widget/src/xpwidgets/nsBaseAppShell.cpp:189 20 xul.dll xul.dll@0xb7400b 21 xul.dll nsAppShell::Run widget/src/windows/nsAppShell.cpp:258
Comment 1•12 years ago
|
||
Please be more specific: rank in different versions, different stacks, component, interesting comments, STR, regression range...
Comment 2•12 years ago
|
||
It's #27 top browser crasher in 11.0b2, #41 in 12.0a2 and #72 in 13.0a1. It first appeared in 11.0a1/20111213. The regression range is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5c64fb241d4e&tochange=3c321d2c9884 It's likely a regression from bug 708382. More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3AGCMarker%3A%3AprocessMarkStackTop%28%29
This is just another example of GC marking crashes. However, it's interesting that all the crashes seem to happen during gray marking.
Comment 4•12 years ago
|
||
Adding [@ js::GCMarker::processMarkStackTop ] which is a Mac signature seen in low volume on the trunk the past two days.
Comment 5•12 years ago
|
||
The Mac crashes have the following stack: Frame Module Signature Source 0 XUL js::GCMarker::processMarkStackTop js/src/jsgc.h:674 1 XUL js::GCMarker::drainMarkStack js/src/jsgcmark.cpp:1154 2 XUL GCCycle js/src/jsgc.cpp:3481 3 XUL Collect js/src/jsgc.cpp:3683 4 XUL js::NotifyDidPaint js/src/jsfriendapi.cpp:725 5 XUL nsXPConnect::NotifyDidPaint js/xpconnect/src/nsXPConnect.cpp:2841 6 XUL PresShell::Paint layout/base/nsPresShell.cpp:5441 7 XUL nsViewManager::Refresh view/src/nsViewManager.cpp:377 8 XUL nsViewManager::DispatchEvent view/src/nsViewManager.cpp:813 9 XUL HandleEvent view/src/nsView.cpp:158 10 XUL nsChildView::DispatchEvent widget/cocoa/nsChildView.mm:1512 11 XUL nsChildView::DispatchWindowEvent widget/cocoa/nsChildView.mm:1522 12 XUL -[ChildView drawRect:inContext:] widget/cocoa/nsChildView.mm:2588 13 XUL -[ChildView drawRect:] widget/cocoa/nsChildView.mm:2487 14 AppKit AppKit@0x54baa 15 AppKit AppKit@0x4f59a 16 AppKit AppKit@0x509b9
Updated•12 years ago
|
Comment 7•12 years ago
|
||
At #30 for 11b4.
Comment 8•12 years ago
|
||
There's a spike in crashes (4 crashes an hour) from 15.0a1/20120513. The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=22a58090fa70&tochange=c758cc9b60e5 It's likely a regression from bug 735099 which has been backed out since.
Comment 9•12 years ago
|
||
Spike seems to have been temporary, probably from IGC as you say. Minusing for now, please renom if it spikes again.
Comment 10•12 years ago
|
||
It spiked again starting from 15.0a1/20120601. The regression range for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3aa566994890&tochange=73783bf75c4c More reports at: https://crash-stats.mozilla.com/report/list?signature=js%3A%3AGCMarker%3A%3AprocessMarkStackTop%28js%3A%3ASliceBudget%26%29
Comment 11•12 years ago
|
||
It's #9 top browser crasher in 15.0a2 and #19 in 16.0a1.
Comment 12•12 years ago
|
||
Let's let this sit for a bit longer and make sure it's not a temporary spike before tracking.
Comment 13•12 years ago
|
||
Two weeks after the last spike, it's still high, #13 top browser crasher in 15.0a2 and #10 in 16.0a1 while "only" #26 in 14.0b7.
Comment 14•12 years ago
|
||
(In reply to Scoobidiver from comment #13) > Two weeks after the last spike, it's still high, #13 top browser crasher in > 15.0a2 and #10 in 16.0a1 while "only" #26 in 14.0b7. Let's see what the engineering team can turn up here based upon the suspicious range in comment 10. It would also be good to get correlations (if there are any, including Naoki).
Comment 15•12 years ago
|
||
Here are correlations in 15.0a2: js::GCMarker::processMarkStackTop(js::SliceBudget&)|EXCEPTION_ACCESS_VIOLATION_READ (45 crashes) 13% (6/45) vs. 5% (344/6967) avg@toolbar 7% (3/45) vs. 1% (78/6967) mozilla_cc@internetdownloadmanager.com (IDM CC, https://addons.mozilla.org/addon/6973)
Comment 16•12 years ago
|
||
Nothing in the regression range jumped out at me. The level is still pretty high. Bill, what do you think we can do with these?
I'm having a hard time interpreting the results. There seem to be a few spikes. Do we ship a new Aurora build ever day? I see spikes on 6/1 and 6/9, with significantly fewer crashes in between. I also compared GC top crashes between 14 and 15. In 14, PushMarkStack is ranked #15 and accounts for 0.84% of all crashes. In 15, it doesn't show up at all. Instead, processMarkStackTop is the top GC crash, at #13, and accounts for 0.77% of all crashes. Overall, it's worrisome that we don't have an explanation of why this is happening. It's probably something to do with incremental GC, except that doesn't really account for the spikes. Also, as bug 761739 states, incremental GCs are very rare in Firefox 15--they almost never happen. However, comparing the total crash rate between 14 and 15 suggests that there's nothing to be overly concerned about.
Comment 19•12 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #17) > I also compared GC top crashes between 14 and 15. In 14, PushMarkStack is > ranked #15 and accounts for 0.84% of all crashes. In 15, it doesn't show up > at all. Instead, processMarkStackTop is the top GC crash, at #13, and > accounts for 0.77% of all crashes. I have to disagree. First, it's js::GCMarker::processMarkStackTop(js::SliceBudget&) both in 14.0b7 and 15.0a2. Then, in 14.0b7 it's #25 top browser crasher and accounts for 0.5% of all crashes while in 15.0a2 the respective figures are #11 and 1% (probably 1.5% after the fix of bug 760118 that accounted for 33% of crashes).
(In reply to Scoobidiver from comment #19) > First, it's js::GCMarker::processMarkStackTop(js::SliceBudget&) both in > 14.0b7 and 15.0a2. > Then, in 14.0b7 it's #25 top browser crasher and accounts for 0.5% of all > crashes while in 15.0a2 the respective figures are #11 and 1% (probably 1.5% > after the fix of bug 760118 that accounted for 33% of crashes). I didn't realize that there was such a big topcrasher biasing the 15 stats. That does change things. However, I stand by my analysis. It's not possible to compare signatures directly between 14 and 15. Because of inlining differences, the same crash will get recorded as a different signature. The only thing we can do is to count all the GC marking crashes together. I went through more thoroughly and found all the marking crashes in the top 50 for both FF14 and FF15. They are as follows: FF14: js::gc::PushMarkStack - 0.8% js::gc::ScanShape - 0.59% js::gc::MarkInternal(JSTracer*, JSString**) - 0.52% js::GCMarker::processMarkStackTop(js::SliceBudget&) - 0.49% js::gc::ScanTypeObject - 0.31% js::gc::MarkInternal(JSTracer*, JSObject**) - 0.24% TOTAL - 2.95% FF15: js::GCMarker::processMarkStackTop(js::SliceBudget&) - 0.97% JSScript::markChildren(JSTracer*) - 0.42% TOTAL - 1.39% If we subtract out the topcrasher accounting for 33% of crashes in FF15, GC marking crashes should account for roughly 2.1% of the total. This analysis is somewhat imprecise because a few of the signatures also count cycle collector crashes. However, I don't think that should substantially affect things. Especially since those CC crashes are probably caused by the same underlying issues, whatever they are.
Comment 21•12 years ago
|
||
I got this crash recently on a Try run : https://tbpl.mozilla.org/php/getParsedLog.php?id=12948341&tree=Try . Can someone tell me if this is related or is this some separate problem. Thanks.
(In reply to Saurabh Anand [:sawrubh] from comment #21) > I got this crash recently on a Try run : > https://tbpl.mozilla.org/php/getParsedLog.php?id=12948341&tree=Try . Can > someone tell me if this is related or is this some separate problem. Please file as a separate bug. It's easier to keep oranges separate from topcrashes.
Updated•12 years ago
|
Comment 23•12 years ago
|
||
I compared the ranks of signatures containing js::gc: * Overall: * 14.0.1: 2.95% * 15.0b1: 4.68% including 2.57% for js::GCMarker::processMarkStackTop * Mac: * 14.0.1: 2.06% * 15.0b1: 8.32% including 4.09% for js::GCMarker::processMarkStackOther
Scoobidiver, can you list out the crashes that you counted?
Comment 25•12 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #24) > Scoobidiver, can you list out the crashes that you counted? * 14.0.1: js::gc::PushMarkStack js::gc::ScanShape js::gc::MarkInternal<JSLinearString>(JSTracer*, JSLinearString**) js::GCMarker::processMarkStackTop(js::SliceBudget&) js::gc::ScanTypeObject js::gc::MarkInternal<JSObject>(JSTracer*, JSObject**) je_free | js::gc::Arena::finalize<JSString>(js::FreeOp*, js::gc::AllocKind, unsigned int) js::gc::MarkRange<JSObject> js::gc::ScanRope js::gc::Arena::finalize<JSObject>(js::FreeOp*, js::gc::AllocKind, unsigned int) js::GCThingIsMarkedGray(void*) js::gc::Chunk::releaseArena(js::gc::ArenaHeader*) je_free | js::GCHelperThread::doSweep() js::gc::MarkChildren RtlEnterCriticalSection | je_free | js::GCHelperThread::doSweep() js::gc::MarkCycleCollectorChildren(JSTracer*, js::Shape*) js::gc::Arena::finalize<JSExternalString>(js::FreeOp*, js::gc::AllocKind, unsigned int) RtlUlonglongByteSwap | RtlpDeCommitFreeBlock | je_free | js::gc::FinalizeTypedArenas<JSString>(js::FreeOp*, js::gc::ArenaLists::ArenaList*, js::gc::AllocKind) js::gc::MarkInternal<js::Shape>(JSTracer*, js::Shape**) js::gc::ScanBaseShape js::gc::Chunk::allocateArena(JSCompartment*, js::gc::AllocKind) js::gc::MarkInternal<JSScript>(JSTracer*, JSScript**) js::gc::MarkValueRootRange(JSTracer*, unsigned int, JS::Value*, char const*) *15.0b1: js::GCMarker::processMarkStackTop(js::SliceBudget&) je_free | js::GCHelperThread::doSweep() js::gc::Arena::finalize<JSObject>(js::FreeOp*, js::gc::AllocKind, unsigned int) arena_dalloc_small | je_free | js::gc::Arena::finalize<JSString>(js::FreeOp*, js::gc::AllocKind, unsigned int) je_free | js::gc::Arena::finalize<JSString>(js::FreeOp*, js::gc::AllocKind, unsigned int) je_free | js::GCHelperThread::freeElementsAndArray(void**, void**) | js::GCHelperThread::doSweep() js::gc::ScanRope js::gc::Mark<JSAtom> arena_dalloc_small | je_free | js::GCHelperThread::freeElementsAndArray(void**, void**) | js::GCHelperThread::doSweep() js::gc::Chunk::releaseArena(js::gc::ArenaHeader*) js::GCThingIsMarkedGray(void*) js::gc::ArenaLists::allocateFromArena(JSCompartment*, js::gc::AllocKind) js::GCMarker::processMarkStackOther arena_dalloc_small | _MD_CURRENT_THREAD | js::gc::Arena::finalize<JSString>(js::FreeOp*, js::gc::AllocKind, unsigned int) js::gc::MarkUnbarriered<JSScript> js::NewObjectWithClassProto(JSContext*, js::Class*, JSObject*, JSObject*, js::gc::AllocKind) js::gc::Arena::finalize<js::BaseShape>(js::FreeOp*, js::gc::AllocKind, unsigned int) js::EmptyShape::getInitialShape(JSContext*, js::Class*, JSObject*, JSObject*, js::gc::AllocKind, unsigned int) js::gc::MarkInternal<JSObject>(JSTracer*, JSObject**) arena_dalloc_small | je_free | PL_DHashFreeTable | js::gc::Arena::finalize<JSExternalString>(js::FreeOp*, js::gc::AllocKind, unsigned int) js::gc::MarkInternal<JSString>(JSTracer*, JSString**) js::gc::PushMarkStack arena_dalloc_small | je_free | js::GCHelperThread::doSweep() arena_dalloc_small | _MD_CURRENT_THREAD | js::GCHelperThread::doSweep() js::GCMarker::markBufferedGrayRoots()
Comment 26•12 years ago
|
||
Am not seeing this in 15 topcrashers and this has been around since Firefox 11 so this isn't a candidate for 15 tracking.
Comment 27•12 years ago
|
||
(In reply to Lukas Blakk [:lsblakk] from comment #26) > Am not seeing this in 15 topcrashers and this has been around since Firefox > 11 so this isn't a candidate for 15 tracking. It's #8 top browser crasher in 15.0b2 and #3 on Mac OS X while in 14.0.1 it's only #27 and #34 respectively.
Comment 28•12 years ago
|
||
Appologies, I searched for the first crash signatures and missed that js::GCMarker::processMarkStackTop(js::SliceBudget&) is indeed the #8 topcrasher. Looking at the comments, pretty much all of them mention printing or trying to print - Dave or Bill does this help give a new avenue to investigate? The crash is much higher on 15 than on 16 or 17 at present. I'll add qawanted too to see if we can get some STR for this signature when trying to print from a website. https://crash-stats.mozilla.com/report/list?range_value=7&range_unit=days&date=2012-08-01&signature=js%3A%3AGCMarker%3A%3AprocessMarkStackTop%28js%3A%3ASliceBudget%26%29&version=Firefox%3A15.0b2
Comment 29•12 years ago
|
||
Tried some different scenarios to trigger this crash but was unsuccessful: * Firefox 15.0b1 on Windows XP (it had the highest pool of reports) * Scroll-zooming a print preview page * Printing to file, local, and network printers * NYTimes article, several Wikipedia pages, a couple pages from AMO * Changing page format and settings * Going into stand-by before, after, and during Firefox printing * Restoring from stand-by, checking for updates, and printing * Printing with PrintEdit 8.6 and PrintPreview 0.7.7 add-ons installed Note the last point about add-ons. One of the comments mentions "Print Tools" add-on which is only available for Thunderbird. Interesting that it showed up in the Firefox report. Could be a mistake on the reporter's part. I'll continue to dogfood this but it might be good to get someone else's perspective on this. Does printing even touch JS GC?
Comment 30•12 years ago
|
||
URLs, but not much to go on. 425 about:blank 140 http://www.facebook.com/ 84 https://www.facebook.com/ 16 http://www.slacker.com/ 16 http://www.facebook.com/?ref=tn_tnmn 15 about:home 15 about:newtab 12 https://www.facebook.com/login.php?login_attempt=1
Comment 31•12 years ago
|
||
The prevalence of about: pages seems to indicate this crash might happen after restarting Firefox, wouldn't it?
Comment 32•12 years ago
|
||
Tried doing some printing from different Facebook content and restarting Firefox between prints, did not reproduce this bug. Is it possible to reach out to any of these users to see if there are any commonalities we can test (ex. correlation to a particular print driver/vendor)?
Comment 33•12 years ago
|
||
I tried this several times throughout the last few days and have still been unable to reproduce this. Is there any other leads QA can follow or some outreach to be performed?
Comment 34•12 years ago
|
||
[@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] is still the leading signature, but all of those URLs seem to be pretty generic. Here are some from the other signatures: 33 http://www.facebook.com/ 21 about:blank 17 https://www.facebook.com/ 4 https://www.facebook.com/login.php?login_attempt=1 4 http://www.google.co.in/ 3 https://mail.google.com/mail/?shva=1#inbox 3 about:home 2 http://www.boadica.com.br/pesquisa/compu%5fnotebook/precos?ClasseProdutoX=1&CodC 2 http://site5.way2sms.com/Main.action?id=31A2D2050D39AC7317FA89818B6D1DAE.w810 2 about:sessionrestore 1 http://www1.watchop.com/watch/one-piece-episode-186-english-dubbed/ 1 http://ismsmessages.com/collection/hindi-love-quotes 1 http://bl166w.blu166.mail.live.com/mail/InboxLight.aspx?n=1595311957&fid=5 1 http://www.orkut.com.br/Main#Scrapbook?uid=17876913867188827111 1 http://www.elaioun24.com/?cat=3269 1 http://www.facebook.com/sobah.fauzi/photos 1 wyciwyg://429/http://www.mapquest.com/cdn/_uac/adpage.htm 1 http://vk.com/ 1 http://radar.meteopress.cz/ 1 http://twitter/ 1 http://netconect.objectdata.com.br/intranet/main 1 http://aihdownload.adobe.com/bin/install_flashplayer11x32_mssd_aih.exe 1 http://www.widgetserver.com/syndication/get_widget.html?widget.appId=80104939-c7 1 http://www.searchremagnified.com/?dn=mercardolivre.com&pid=9PO6B1W9X 1 http://www.google.de/search?q=tarantel%20halten&ie=utf-8&oe=utf-8&aq=t&rls=org.m 1 http://www.yahoo.com/?ilc=8 1 http://www.google.co.in/#hl=en&sclient=psy-ab&q=online+inox+booking+visakhapatna 1 http://www.youtube.com/ 1 http://in.mg61.mail.yahoo.com/neo/launch?.rand=8t6s2pbtdm15t 1 http://www.orkut.com.br/Main#Profile?uid=9703369906402518139 1 http://www.youtube.com/results?search_query=abelbeetle+house&oq=abelbeetle+house 1 http://www.yandex.ru/ 1 https://betcityru.com/ 1 http://oadsrv.com/www/delivery/afr.php?zoneid=132&refresh=120&cb=0.2875017602808 1 http://www.selectornews.com/?publisher=popunder&p=2 1 http://www.alan4.com/video/14616/watch.html 1 https://getcocoon.com/access_denied 1 https://twitter.com/download/?lang=id&logged_out=1 1 http://bryansk.brn.slando.ru/nedvizhimost/prodazha-domov/?page=2 1 http://software-files-a.cnet.com/s/software/12/45/10/54/FreeYouTubeDownloaderIns 1 http://www.panet.co.il/Ext/series.php?name=folder&id=922 1 http://www.4shared.com/mp3/RTJ6kNxQ/Kotak_-_Cinta_Jangan_Pergi.htm 1 http://drhtv.tv/channel-3.html 1 http://www.akhbarak.net/sections/criminal 1 http://www.militaria-berlin.de/shopgallerie.php?sid=mdWYmOXe0qegmajM0tTZ0NvVyaba 1 http://entertainment.in.msn.com/gallery/2012-highest-paid-tv-actresses#image=21 I am also wading through the comments now to see what else I can find.
The two main GC-related things that could be causing this are compartment-per-global and compartmental GC. Unfortunately, compartment-per-global probably caused some new compartment mismatch bugs. Some of them have been fixed, but there are probably a few more outstanding. Compartmental GC makes the problem worse, because it makes it more likely that a compartment mismatch will lead to a crash. Backing out CPG is pretty much not an option. One concrete thing I can think of doing here is to back out bug 716014, which enabled compartment GC in FF15. However, it seems like our crash rate in FF16 is also high, and compartmental GC is disabled in FF16. So maybe that wouldn't help. Another idea is to enable compartment asserts in nightly builds for a week or so. That might flush out some bugs that we could then fix on beta.
Comment 36•12 years ago
|
||
(In reply to Bill McCloskey (:billm) from comment #35) > Another idea is to enable compartment asserts in nightly builds for a week > or so. That might flush out some bugs that we could then fix on beta. That sounds like a good idea. (I've been meaning to file a bug about trying harder to prevent or catch compartment mismatches.)
Comment 37•12 years ago
|
||
Dropping QAWANTED because I don't see any new leads in this bug where QA can assist. Please re-add if this changes.
Comment 38•12 years ago
|
||
Starting to doubt that we're going to get much headway on this one in 15, it's at #7 in the FF15 top-crashers (though only causing 2.3% of crashes) and 141 in the FF16 top-crashers. Going to mark for tracking-firefox16 so we can see what happens to this when 16 goes to Beta.
Comment 39•12 years ago
|
||
It's #7 top browser crasher in 15.0b4 and b5 so bug 782825 has had no effect on this bug.
Comment 40•12 years ago
|
||
This surprisingly does not have many comments in crash-stats, so user outreach isn't going to be easy. Hopefully that means this isn't too painful (although it is the #7 top crasher in beta 5). If we were to have a 2-way conversation with an affected user, what would we ask?
Comment 41•12 years ago
|
||
my crash bp-5cc5a06c-297d-4985-8d90-264932120828 I frequently crash - mostly with @ EMPTY. But this is my first time with js::GCMarker::processMarkStackTop(js::SliceBudget&)
Comment 42•12 years ago
|
||
just prior to bp-5cc5a06c-297d-4985-8d90-264932120828 I happened to be in windbg. (I couldn't get dump because not enough disk space)
Comment 43•12 years ago
|
||
Bill, can you do anything useful with Wayne's crash report? Is it likely to be a compartment-related crash? Also, do we have any way of telling whether disabling the per-compartment GCs helped? For Beta in Socorro I just see one build date. Wayne - I can think of a couple of things that you could try. One would be to run a memory tester: we've seen cases before where people were crashing frequently due to a faulty memory chip. The other is that I notice in your crash report that you have several add-ons. It's possible that one of those is triggering a compartment-related bug (either a bug in the add-on, or a bug in Firefox that is heavily exposed by the add-on). If you happened to learn that disabling a particular add-on made your browser more stable, that could be helpful for this bug (and of course your usage!).
The GC where Wayne crashed was triggered from an nsMemoryPressureObserver. That suggests that the machine was low on memory. We tend not to deal well with OOMs, and that could be the problem (as well as the source of the empty crash reports).
Comment 45•12 years ago
|
||
The crash comments aren't very enlightening, but now that this is on Beta, we should grab correlation reports again. Setting Marcia as the QA contact.
Comment 46•12 years ago
|
||
I just got this crash (https://crash-stats.mozilla.com/report/index/bp-60705c0a-fe95-490c-9779-d2fe02120912) at http://www.flightradar24.com/. I clicked on a random flight, clicked on Cockpit View and crash. Doesn't happen every time though.
Comment 47•12 years ago
|
||
(In reply to Alex Keybl [:akeybl] from comment #45) > The crash comments aren't very enlightening, but now that this is on Beta, > we should grab correlation reports again. Setting Marcia as the QA contact. Sadly, Wayne believes he had reproduced this once in safe mode more with all addons disabled.
Comment 48•12 years ago
|
||
js::GCMarker::processMarkStackTop(js::SliceBudget&) is the high volume crash signature that is happening on 16. Here is some module correlations from 16 - the correlation data looks about the same for 15.0.1 - one thing I noticed is a 19% correlation to Avast, and 7.0.1466.549 comes up in the detailed report: js::GCMarker::processMarkStackTop(js::SliceBudget&)|EXCEPTION_ACCESS_VIOLATION_READ (900 crashes) 100% (898/900) vs. 60% (32251/53974) nssckbi.dll 71% (635/900) vs. 31% (16969/53974) wldap32.dll 70% (634/900) vs. 32% (17055/53974) lz32.dll 90% (807/900) vs. 51% (27751/53974) t2embed.dll 100% (898/900) vs. 62% (33261/53974) freebl3.dll 100% (898/900) vs. 62% (33277/53974) nssdbm3.dll 100% (898/900) vs. 62% (33280/53974) softokn3.dll 71% (635/900) vs. 33% (17729/53974) xpsp2res.dll 65% (588/900) vs. 28% (15217/53974) cryptui.dll 100% (899/900) vs. 64% (34293/53974) winrnr.dll 99% (895/900) vs. 63% (34151/53974) feclient.dll 94% (843/900) vs. 59% (31745/53974) shdocvw.dll 100% (899/900) vs. 66% (35591/53974) browsercomps.dll 64% (576/900) vs. 30% (16336/53974) tapi32.dll 99% (892/900) vs. 65% (35338/53974) rasadhlp.dll 71% (635/900) vs. 37% (20038/53974) wshtcpip.dll 71% (635/900) vs. 37% (20040/53974) hnetcfg.dll 100% (900/900) vs. 67% (35933/53974) firefox.exe 100% (900/900) vs. 67% (35953/53974) xpcom.dll 85% (768/900) vs. 52% (28040/53974) rasapi32.dll 85% (768/900) vs. 52% (28042/53974) rasman.dll 85% (769/900) vs. 52% (28170/53974) rtutils.dll 100% (900/900) vs. 67% (36314/53974) dbghelp.dll 80% (718/900) vs. 48% (25683/53974) mpr.dll 100% (900/900) vs. 71% (38086/53974) dnsapi.dll 70% (629/900) vs. 41% (21919/53974) comres.dll 71% (635/900) vs. 41% (22350/53974) ws2help.dll 71% (635/900) vs. 41% (22355/53974) iphlpapi.dll 73% (657/900) vs. 45% (24024/53974) netapi32.dll 76% (683/900) vs. 48% (26099/53974) imagehlp.dll 87% (784/900) vs. 61% (32661/53974) rsaenh.dll 100% (901/900) vs. 75% (40274/53974) mswsock.dll 46% (413/900) vs. 21% (11319/53974) sensapi.dll 100% (900/900) vs. 76% (41070/53974) wintrust.dll 48% (436/900) vs. 26% (14061/53974) MSCTF.dll 43% (389/900) vs. 23% (12178/53974) msv1_0.dll 48% (433/900) vs. 28% (15345/53974) samlib.dll 39% (348/900) vs. 20% (10830/53974) winsta.dll 42% (376/900) vs. 24% (12841/53974) wtsapi32.dll 87% (781/900) vs. 71% (38101/53974) secur32.dll 32% (288/900) vs. 16% (8618/53974) atl.dll 27% (247/900) vs. 13% (6824/53974) activeds.dll 27% (247/900) vs. 13% (6824/53974) adsldpc.dll 27% (247/900) vs. 13% (6842/53974) mprapi.dll 25% (222/900) vs. 11% (6206/53974) wmi.dll 25% (222/900) vs. 11% (6206/53974) wzcsvc.dll 25% (222/900) vs. 11% (6207/53974) netman.dll 25% (222/900) vs. 11% (6207/53974) esent.dll 25% (223/900) vs. 12% (6302/53974) wzcsapi.dll 25% (224/900) vs. 12% (6395/53974) credui.dll 25% (224/900) vs. 12% (6398/53974) netshell.dll 29% (263/900) vs. 17% (9072/53974) MSCTFIME.IME 49% (439/900) vs. 37% (20183/53974) msacm32.drv 49% (437/900) vs. 37% (20199/53974) midimap.dll 49% (439/900) vs. 38% (20355/53974) wdmaud.drv 49% (440/900) vs. 38% (20698/53974) msacm32.dll 19% (168/900) vs. 8% (4406/53974) idmmkb.dll 19% (167/900) vs. 9% (4825/53974) msvcp60.dll 19% (168/900) vs. 10% (5448/53974) AavmRpch.dll 19% (168/900) vs. 10% (5448/53974) Aavm4h.dll 19% (168/900) vs. 10% (5448/53974) ashTask.dll 19% (168/900) vs. 10% (5448/53974) aswAux.dll 19% (168/900) vs. 10% (5448/53974) aswProperty.dll 19% (168/900) vs. 10% (5448/53974) aswEngLdr.dll 19% (168/900) vs. 10% (5448/53974) ashBase.dll 19% (168/900) vs. 10% (5449/53974) aswCmnOS.dll 19% (168/900) vs. 10% (5449/53974) aswCmnBS.dll 19% (168/900) vs. 10% (5449/53974) aswCmnIS.dll 16% (140/900) vs. 8% (4117/53974) dot3api.dll 15% (139/900) vs. 8% (4080/53974) eapolqec.dll 15% (139/900) vs. 8% (4080/53974) qutil.dll 15% (139/900) vs. 8% (4096/53974) dot3dlg.dll 15% (139/900) vs. 8% (4114/53974) onex.dll 15% (139/900) vs. 8% (4114/53974) eappprxy.dll 15% (139/900) vs. 8% (4115/53974) eappcfg.dll 18% (160/900) vs. 10% (5530/53974) cscui.dll 18% (160/900) vs. 10% (5545/53974) cscdll.dll 20% (183/900) vs. 13% (6933/53974) cryptdll.dll 74% (668/900) vs. 68% (36462/53974) winspool.drv 41% (366/900) vs. 34% (18355/53974) dhcpcsvc.dll 24% (218/900) vs. 18% (9627/53974) msvcp90.dll 31% (280/900) vs. 25% (13430/53974) msvcr90.dll 100% (899/900) vs. 95% (51124/53974) mscms.dll 95% (858/900) vs. 90% (48726/53974) wininet.dll
Comment 49•12 years ago
|
||
I can somewhat reproduce this crash with pdf.js 0.4.11 with a new profile on 2012-09-15 nightly. From Finder, drag the file into a new tab. pdf.js should say that it is unable to render this file. Keep dragging it into the same / a new tab, and play around with closing the tab(s). Crash: bp-4cb2a08a-bfa0-4e32-b0fe-8cdf62120916 or crash: bp-ea14df72-d8a9-47e6-a36e-c49112120916
Comment 50•12 years ago
|
||
> pdf testcase Testcase came from http://www.straitstimes.com/sites/straitstimes.com/files/ST_20120914_SWIPHONE14_3298937.pdf
Comment 51•12 years ago
|
||
> Crash: bp-4cb2a08a-bfa0-4e32-b0fe-8cdf62120916 > or crash: bp-ea14df72-d8a9-47e6-a36e-c49112120916 One of it was tested on 2012-09-14's nightly. Playing around some more, the procedure is fairly reproducible, but it also crashes at a lot of other crash signatures: bp-975f5602-eb82-4177-809d-8b9352120916 bp-8c44f300-81f9-4993-8105-4254f2120916 bp-8bc931f6-e12a-4758-ae1f-0cd012120916 I could get this method to crash only with the testcase being the topmost most recent file in Fan mode on Mac OS X Lion, and dragging in to the browser window.
Comment 52•12 years ago
|
||
Since the landing of IonMonkey, I'm now getting this crash: bp-2f74cdaa-2edc-4c13-b4b4-5d4302120916 The bug breaks pdf.js for some PDFs and leads to crashing. Here's the PDF link: http://www.endress.com/eh/productDBs/homeDBs/resourceadditional.nsf/imgref/Download_SIL_brochure_en.pdf/$FILE/SIL_brochure_en.pdf To reproduce: 1. Install a nightly build with IonMonkey 2. Configure Firefox to preview PDFs 3. Open the above link in a new tab. Note that the PDF fails to display 4. Scroll all the way up and down the blank displayed PDF a few times. 5. Close the tab. 6. If you haven't yet crashed, you should as soon as you navigate and scroll other tabs. With IonMonkey disabled ("javascript.options.ion.content" set to false) the PDF displays correctly and there is no crashing This is reproducible on Windows 7 and XP. I haven't tried other platforms.
Comment 53•12 years ago
|
||
Comment 54•12 years ago
|
||
Let's try this again. I guess Bugzilla sucks at auto identifying PDFs.
Comment 55•12 years ago
|
||
I can't reproduce on Windows 7 with the STR in comment 52.
Comment 56•12 years ago
|
||
Browser crashes 100% reproducible. And I can sometime with the signatures bp-cb9a5c50-f47d-4179-8d84-bdd332120916 Steps to reproduce: 1. Install a nightly build with IonMonkey 2. Configure Firefox to preview PDFs 3. Open the above link comment 52 in a new tab. Note that the PDF fails to display 4. Scroll all the way up and down the blank displayed PDF 2-30 times. And also browser crashes with several crash signatures: bp-674bf703-ead1-4fef-ad6f-691382120916 bp-82e3c51b-836e-49f3-ae9a-03e172120916 bp-083da69a-83b2-4ae3-bdd3-19bcd2120916 bp-84332fb6-2a6a-41f2-b464-de5d72120916 bp-d9e19bdb-b000-4af2-909f-f00a02120916
Comment 57•12 years ago
|
||
(In reply to Alice0775 White from comment #56) > Browser crashes 100% reproducible. Thanks so much Alice! Will follow up with the JS team and make sure to get this investigation prioritized given these STR.
Comment 58•12 years ago
|
||
I think it's a meta bug and the STR in comment 56 are only one kind of crashes.
Thank you IU and Alice, I can reproduce that particular crash. It looks like a memory corruption bug somewhere in IonMonkey. I've filed bug 792226.
Comment 60•12 years ago
|
||
(In reply to David Anderson [:dvander] from comment #59) > Thank you IU and Alice, I can reproduce that particular crash. It looks like > a memory corruption bug somewhere in IonMonkey. I've filed bug 792226. Does that test case repro in JM as well, or only in IM?
Updated•12 years ago
|
Comment 61•12 years ago
|
||
Too late for 16 at this point with no tested fix in sight. This is the #7 topcrasher on 16.0b4 at 2.2% and also #7 topcrasher on Aurora 17 right now so we'll carry the tracking forward to 17 in the hopes that some work can be done on this in the next 6 weeks.
Comment 62•12 years ago
|
||
(In reply to Scoobidiver from comment #58) > I think it's a meta bug and the STR in comment 56 are only one kind of > crashes. I've gotten a few similar crashes, preceded by some OOM errors, so that might be mixed up in it: [JavaScript Error: "TelemetryStopwatch: key "FX_SESSION_RESTORE_SERIALIZE_DATA_MS" was already initialized" {file: "resource://gre/modules/TelemetryStopwatch.jsm" line: 53}] [JavaScript Error: "out of memory" {file: "resource:///modules/sessionstore/SessionStore.jsm" line: 4150}] [JavaScript Error: "out of memory" {file: "resource:///modules/sessionstore/SessionStore.jsm" line: 4150}] (1a5c.54c): Access violation - code c0000005 (first chance) First chance exceptions are reported before any exception handling. This exception may be expected and handled. eax=3c501b00 ebx=0704d110 ecx=00000010 edx=59e24118 esi=00000000 edi=77b5f5c0 eip=59c778a4 esp=0028ca18 ebp=0704d128 iopl=0 nv up ei pl nz na pe nc cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00210206 *** WARNING: Unable to verify checksum for C:\Program Files\Aurora\mozjs.dll mozjs!js::GCMarker::processMarkStackTop+0xb14: 59c778a4 8b00 mov eax,dword ptr [eax] ds:0023:3c501b00=????????
Comment 63•12 years ago
|
||
18b4fb20 5c18b559 mozjs!Collect(struct JSRuntime * rt = 0x18ad0001, bool incremental = false, int64 budget = 0n3853532893779329024, js::JSGCInvocationKind gckind = 0n3 (No matching enumerant), js::gcreason::Reason reason = LAST_DITCH (0n4))+0xe0 [e:\builds\moz2_slave\m-aurora-w32-ntly\build\js\src\jsgc.cpp @ 4500] Maybe that "LAST_DITCH" indicates another OOM case. According to Process Hacker, the peak virtual size was 1.92 GB (running on a 32-bit box).
Comment 64•12 years ago
|
||
(In reply to David Mandelin [:dmandelin] from comment #60) > (In reply to David Anderson [:dvander] from comment #59) > > Thank you IU and Alice, I can reproduce that particular crash. It looks like > > a memory corruption bug somewhere in IonMonkey. I've filed bug 792226. > > Does that test case repro in JM as well, or only in IM? David - what are the next steps here? I see you reproduced in IM, but JM is present in all the other affected versions. We'd still like to try for a fix in FF17.
(In reply to Alex Keybl [:akeybl] from comment #64) > (In reply to David Mandelin [:dmandelin] from comment #60) > > (In reply to David Anderson [:dvander] from comment #59) > > > Thank you IU and Alice, I can reproduce that particular crash. It looks like > > > a memory corruption bug somewhere in IonMonkey. I've filed bug 792226. > > > > Does that test case repro in JM as well, or only in IM? > > David - what are the next steps here? I see you reproduced in IM, but JM is > present in all the other affected versions. We'd still like to try for a fix > in FF17. The test cases reported in comments #52 and #56 were IonMonkey bugs that sometimes crashed with the same stack. That was fixed, and would only affect Firefox 18. This bug, as reported, is most likely a collection of random crashes that happen to have the same stack, so there aren't really any (new) next steps.
Comment 66•12 years ago
|
||
Given that this is a collection of random crashes and there are no new next steps from the JS team, I'm untracking this for 17.
Updated•12 years ago
|
Comment 68•12 years ago
|
||
crashed yesterday bp-429d8ec5-fb07-418e-bad7-e4e282121020 0 mozjs.dll js::GCMarker::processMarkStackTop js/src/gc/Marking.cpp:1199 1 mozjs.dll js::GCMarker::drainMarkStack js/src/gc/Marking.cpp:1299 2 mozjs.dll IncrementalCollectSlice js/src/jsgc.cpp:4345 3 mozjs.dll GCCycle js/src/jsgc.cpp:4549 4 mozjs.dll Collect js/src/jsgc.cpp:4663 5 mozjs.dll js::GC js/src/jsgc.cpp:4688 6 mozjs.dll js::GCForReason js/src/jsfriendapi.cpp:160 7 xul.dll xul.dll@0x32f13e 8 xul.dll xul.dll@0xa790bd 9 xul.dll xul.dll@0x3857f4 10 xul.dll xul.dll@0x273729
Comment 69•12 years ago
|
||
Crashed 10/7 in Aurora with https://crash-stats.mozilla.com/report/index/bp-e1542b9d-e98f-47cb-a4ed-df8e12121007 (was going through my about:crashes)
Comment 70•11 years ago
|
||
This is the #2 browser crash in 18.0b4 and #4 on 17.0.1
Comment 71•11 years ago
|
||
https://tbpl.mozilla.org/php/getParsedLog.php?id=18913198&tree=Mozilla-Inbound
Comment 72•11 years ago
|
||
https://tbpl.mozilla.org/php/getParsedLog.php?id=20313819&tree=Mozilla-Beta
Comment 73•11 years ago
|
||
Crash Report: bp-f187eb97-a0b5-4eb3-ba5a-f13862130317
Comment 74•11 years ago
|
||
It's #2 top browser crasher in 20.0.1 and 21.0b3, #3 in 22.0a2, and #26 in 23.0a1.
We really need the ability to see total GC crash volume (bug 803209) to know if anything actually improved in 23. It's possible this just got broken up into multiple signatures if we stopped inlining certain functions. Optimistically, turning off JM might have solved a bunch of GC crashes. In that case, there's nothing to backport.
Comment 76•11 years ago
|
||
(In reply to Scoobidiver from comment #74) > #26 in 23.0a1. now #14 and even #5 without fixed top crashers.
Comment 77•11 years ago
|
||
There's a new crash signature in 21.0b6: https://crash-stats.mozilla.com/report/list?signature=PushMarkStack
Comment 78•11 years ago
|
||
Let's add also ScanRope, ScanShape, ScanTypeObject and ScanLinearString that have a similar stack trace except for the one or two first frames.
Updated•11 years ago
|
Updated•11 years ago
|
Comment 81•11 years ago
|
||
It accounts for 13% of crashes in 17.0.7esr while only 1.3% in 17.0.6esr. The regression range for the spike: http://hg.mozilla.org/releases/mozilla-esr17/pushloghtml?fromchange=07676308cb02&tochange=ce8b744660b6 Note that it might be previously empty crashes that fall off from 20.8% to 12.2%.
Updated•11 years ago
|
Updated•11 years ago
|
Comment 82•11 years ago
|
||
I crashed Thunderbird bp-1fca6b38-7495-4cd1-8ac7-aa2382130917 while using Gecko Profiler. Not able to reproduce in 4 attempts. (And it's a "clean" thunderbird system - last crash 7 months ago) - daily 26.0a1 (2013-09-13) - installed 1.12.7 profiler from geckoprofiler.xpi link of https://github.com/bgirard/Gecko-Profiler-Addon - restarted thunderbird, - enable profiler - dump profile crash 0 mozjs.dll ScanTypeObject js/src/gc/Marking.cpp 1 mozjs.dll js::GCMarker::processMarkStackOther(js::SliceBudget &,unsigned int,unsigned int) js/src/gc/Marking.cpp 2 mozjs.dll js::GCMarker::processMarkStackTop(js::SliceBudget &) js/src/gc/Marking.cpp 3 mozjs.dll js::GCMarker::drainMarkStack(js::SliceBudget &) js/src/gc/Marking.cpp 4 mozjs.dll IncrementalCollectSlice js/src/jsgc.cpp 5 mozjs.dll GCCycle js/src/jsgc.cpp 6 mozjs.dll Collect js/src/jsgc.cpp 7 mozjs.dll js::GC(JSRuntime *,js::JSGCInvocationKind,JS::gcreason::Reason) js/src/jsgc.cpp 8 mozjs.dll JS::ShrinkingGC(JSRuntime *,JS::gcreason::Reason) js/src/jsfriendapi.cpp 9 xul.dll mozilla::dom::workers::WorkerPrivate::GarbageCollectInternal(JSContext *,bool,bool) dom/workers/WorkerPrivate.cpp 10 xul.dll `anonymous namespace'::GarbageCollectRunnable::WorkerRun(JSContext *,mozilla::dom::workers::WorkerPrivate *) dom/workers/WorkerPrivate.cpp 11 xul.dll mozilla::dom::workers::WorkerRunnable::Run() dom/workers/WorkerPrivate.cpp 12 xul.dll mozilla::dom::workers::WorkerPrivate::DoRunLoop(JSContext *) dom/workers/WorkerPrivate.cpp 13 xul.dll `anonymous namespace'::WorkerThreadRunnable::Run() dom/workers/RuntimeService.cpp
Comment 83•11 years ago
|
||
hit this running the JS debugger in Firefox Nightly. https://crash-stats.mozilla.com/report/index/08b021f8-6390-428f-8663-207762130920
Comment 84•11 years ago
|
||
#3 topcrash in Firefox 25.0b1 with an explosiveness rating of 3.4: https://crash-analysis.mozilla.com/rkaiser/2013-09-22/2013-09-22.firefox.25.explosiveness.html
Comment 85•11 years ago
|
||
js::GCMarker::processMarkStackTop(js::SliceBudget&) is #2 (8.64% on Release (Fx24) #2 (5.75%) on Beta (Fx25) #4 (2.35%) on Aurora (Fx26) #8 (1.8%) on Nightly (Fx27) Across Firefox channels this is our worse crasher behind the Empty signature. Doesn't even include other listed signatures, several of which appear to no longer occur. robcee: Was yours a random crash while in JS debugger, or reproducible?
Comment 86•11 years ago
|
||
There does not appear to be a clear regression on nightly any time recently. Note that this is a GC heap corruption signature, so addons which are misusing the JSAPI can cause it, as well as internal bugs corrupting the GC heap. https://crash-analysis.mozilla.com/bsmedberg/ProcessMarkStackTop-nightly.svg
Comment 87•11 years ago
|
||
I don't think it's really higher than in previous releases, is it? If it isn't higher, there's no reason to track. Also, given that "misusing the JSAPI can cause it", the current problem with Norton might play into this.
Comment 88•11 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #87) > Also, given that "misusing the JSAPI can cause it", the current problem with > Norton might play into this. There might be something to that looking at the add-on correlations: > 20% (293/1487) vs. 9% (3474/40186) {2D3F3651-74B9-4795-BDEC-6DA2F431CB62} (Norton Toolbar) > 17% (253/1487) vs. 7% (2987/40186) {BBDA0591-3099-440a-AA10-41764D9DB4DB} (Norton Vulnerability Protection)
Comment 89•11 years ago
|
||
There are some sumo threads where Norton is confirmed to have caused crashes (or at least they cease on disabling the Norton toolbar) and crash signatures have been provided. See bug 917792#c29&#c33 https://bugzilla.mozilla.org/show_bug.cgi?id=917792#c29
Comment 91•11 years ago
|
||
I'll note that many of the processMarkStackTop crashes can't possibly have involved Norton, including the intermittents here. Likely it's just a marker of a particular type of GC/etc corruption; or maybe a GC bug where a particular sequence of data being GC'd leads to a failure (and thus the intermittent). Norton could either be triggering a corruption via a bug, or just by causing a particular pattern of data to be collected.
Comment 92•11 years ago
|
||
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #87) > I don't think it's really higher than in previous releases, is it? > If it isn't higher, there's no reason to track. To KaiRo's point, please renominate only if this is worse than in previous releases.
Comment 93•11 years ago
|
||
I hit this during general browsing using Mac Aurora today, and I definitely don't have Norton on this machine: https://crash-stats.mozilla.com/report/index/e00a3466-dcbc-46fa-a6bf-02cf52131016
Updated•11 years ago
|
Comment 94•11 years ago
|
||
The crash signature js::GCMarker::processMarkStackTop(js::SliceBudget&) spiked heavily for build 2013111408, with 3848 crashes, and then with the next build dropped to a more reasonable level of 54/11063 crashes. So while it's still showing up in the top 10 crashes for Firefox 28, that seems to be the effect of something that broke on the 14th and was fixed by the 15th. Should we leave the topcrash keywords in place or remove them?
Comment 95•11 years ago
|
||
lizzard, this is another of those "special" cases. This one seems to oscillate in and out of topcrash range. Rather than regularly updating the keyword, let's just leave the keywording as is.
Comment 96•11 years ago
|
||
Also, this is consistently in topcrash ranges on releases and betas.
Comment 97•11 years ago
|
||
A GCMarker related PushMarkStack crash is in the top 10 crashers for Fx28 this week, with 259/6772 crashes.
Comment 98•11 years ago
|
||
If bug 708382 is suspected to be the beginning of the crash, would it not be a good idea to back that out of all affected builds, test for regressions, and push an update to users. Monitor the situation for 1 to 2 weeks and if you get no more crashes, you know you need to spend time carefully audit the bug 708382 patches.
Comment 99•11 years ago
|
||
(In reply to IU from comment #98) > If bug 708382 is suspected to be the beginning of the crash, would it not be > a good idea to back that out of all affected builds, There are always a variety of GC crashes. That patch just changed the name of the function that these crashes hit, so it probably caused some other signature to go away. Furthermore, it isn't really possible to back out 2 year old patches in an area of code like this that changes a lot.
Comment 101•10 years ago
|
||
Ranks #4 on Aurora 28 at 2.93% Ranks #8 on Nightly 29 at 1.27% WONTFIX for Firefox 24 and 25 since those are EOL with the release of Firefox 26.
Comment 102•10 years ago
|
||
Current Rank
> Firefox 29: #5 @ 1.86%
> Firefox 28: #3 @ 2.77%
> Firefox 27: #1 @ 4.69%
> Firefox 26: #1 @ 3.76%
Comment 103•10 years ago
|
||
I have crashes with "PushMarkStack" signature in FF 29a1 (64-bit): http://crash-stats.mozilla.com/report/index/bp-a18486d0-18a1-4073-9c88-95de42140117 http://crash-stats.mozilla.com/report/index/bp-532e579e-e6ca-4b6b-82f3-894a52140117 http://crash-stats.mozilla.com/report/index/bp-274845c3-98cb-4d79-83a4-2ed8e2140117 Those are come around few seconds after I visit this page: http://www.huffingtonpost.com/2014/01/17/prince-harry-helicopter-pilot_n_4616743.html
Comment 104•10 years ago
|
||
Wontfix for Firefox 26 as it's EOL with tomorrow's Firefox 27 release.
Updated•10 years ago
|
Comment 105•10 years ago
|
||
This is showing up as a topcrasher, across several crash signatures, in the top 10 crashes for Firefox 31.
Comment 106•10 years ago
|
||
Still one of the top crashers on Fx29.
Comment 107•10 years ago
|
||
Thanks Juan to bring that to our attention.
Comment 108•10 years ago
|
||
This has been around in top ranks for quite a while, there's no way to know where the actual reason for the crashes come from without any concrete STR. It's probably memory corruption that GC just happens to stumble over. As the whiteboard says, this is unactionable, so marking wontfix for all versions it's tracked for. If we have concrete evidence on how we can trigger it, patches are always nice, but the stacks don't tell us much.
Comment 110•10 years ago
|
||
This is a top crash on Firefox for Android nightly.
Comment 111•10 years ago
|
||
I too had this crash today Crash ID : bp-1fd806e7-c0f4-4d6f-aeca-058662140608
Comment 112•10 years ago
|
||
Not sure if we want to continue to track this given this is still unactionable, but it remains a top issue.
Comment 113•10 years ago
|
||
I'm not going to track for current Firefox releases as we don't seem to have any path forward. We will definitely consider an uplift if progress is made on this.
Assignee | ||
Updated•10 years ago
|
Comment 114•10 years ago
|
||
I started having this crash several times a day. For me it was caused by a Flashblock add-on. After removing it, no crashes any more. This probably doesn't help everyone.
Comment 115•10 years ago
|
||
Happened for me earlier in Firefox Nightkly 34.0a1: https://crash-stats.mozilla.com/report/index/59adb78c-fbc1-4849-b585-1abbc2140804
Comment 116•10 years ago
|
||
Happened for me earlier in Firefox Nightly 34.0a1: https://crash-stats.mozilla.com/report/index/59adb78c-fbc1-4849-b585-1abbc2140804
Comment 117•10 years ago
|
||
This continues to be a fairly high volume crash signature (currently as @ ScanShape) in Firefox 34.0b. The stacks look similar to reports above. But, possibly good news, I'm not seeing it in 35 and 36.
Comment 118•9 years ago
|
||
Top crash positions for bug 71911 related crashes 35.0b #14 ...MarkStackTop... #16
Comment 119•9 years ago
|
||
FF 38 beta7 Fresh profile only FEBE and last pass addon Install FEBE and restore bookmarks(html) from backup. FF restore bookmarks and crash after some seconds. FF crash report: https://crash-stats.mozilla.com/report/index/53785408-d6f1-48b8-b282-96aea2150426
Comment 120•9 years ago
|
||
¡Hola Swarnava! Got this on Nightly 41 is it this same bug or shall I file a new one? ¡Gracias! Alex Report ID Date Submitted bp-e71f8d81-29f3-4e2c-bd31-59b882150603 03/06/2015 01:57 p.m. Crashing Thread Frame Module Signature Source 0 xul.dll js::GCMarker::processMarkStackTop(js::SliceBudget&) js/src/gc/Marking.cpp 1 xul.dll js::GCMarker::drainMarkStack(js::SliceBudget&) js/src/gc/Marking.cpp 2 xul.dll js::gc::GCRuntime::drainMarkStack(js::SliceBudget&, js::gcstats::Phase) js/src/jsgc.cpp 3 xul.dll js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 4 xul.dll js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 5 xul.dll js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) js/src/jsgc.cpp 6 xul.dll FinishAnyIncrementalGC dom/base/nsJSEnvironment.cpp 7 xul.dll FireForgetSkippable dom/base/nsJSEnvironment.cpp 8 xul.dll CCTimerFired dom/base/nsJSEnvironment.cpp 9 xul.dll nsTimerImpl::Fire() xpcom/threads/nsTimerImpl.cpp 10 xul.dll nsTimerEvent::Run() xpcom/threads/nsTimerImpl.cpp 11 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 12 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 13 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 14 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 15 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 16 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 17 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 18 xul.dll XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp 19 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 20 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 21 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 22 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp 23 plugin-container.exe content_process_main(int, char** const) ipc/contentproc/plugin-container.cpp 24 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp 25 plugin-container.exe __tmainCRTStartup f:/dd/vctools/crt/crtw32/startup/crt0.c:255 26 kernel32.dll BaseThreadInitThunk 27 ntdll.dll RtlUserThreadStart
Comment 121•9 years ago
|
||
(In reply to alex_mayorga from comment #120) > Got this on Nightly 41 is it this same bug or shall I file a new one? I don't believe Swarnava is with us any longer. This bug is a catch-all for js::GCMarker::processMarkStackTop(js::SliceBudget&) crashes. It's been a long-time topcrash with absolutely zero leads we can investigate (hence the [unactionable] whiteboard tag). If you have some new information then please add it here.
Reporter | ||
Comment 122•9 years ago
|
||
i cant reproduce this crash anymore, if you have are able to reproduce, feel fee to post it here
Updated•9 years ago
|
Comment 124•9 years ago
|
||
[@ js::GCMarker::processMarkStackTop ] Win7, FF44.0a1, 64bit, killhard: https://crash-stats.mozilla.com/report/index/7167ae96-f6eb-44d3-b52a-f12b52151027 Crashing Thread Frame Module Signature Source 0 xul.dll js::GCMarker::processMarkStackTop(js::SliceBudget&) js/src/gc/Marking.cpp 1 xul.dll js::GCMarker::drainMarkStack(js::SliceBudget&) js/src/gc/Marking.cpp 2 xul.dll js::gc::GCRuntime::drainMarkStack(js::SliceBudget&, js::gcstats::Phase) js/src/jsgc.cpp 3 xul.dll js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 4 xul.dll js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 5 xul.dll js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) js/src/jsgc.cpp 6 xul.dll FinishAnyIncrementalGC dom/base/nsJSEnvironment.cpp 7 xul.dll FireForgetSkippable dom/base/nsJSEnvironment.cpp 8 xul.dll CCTimerFired dom/base/nsJSEnvironment.cpp 9 xul.dll nsTimerImpl::Fire() xpcom/threads/nsTimerImpl.cpp 10 xul.dll nsTimerEvent::Run() xpcom/threads/TimerThread.cpp 11 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 12 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 13 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 14 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 15 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 16 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 17 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 18 xul.dll XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp 19 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 20 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 21 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 22 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp 23 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp 24 plugin-container.exe __tmainCRTStartup f:/dd/vctools/crt/crtw32/startup/crt0.c:255 Ø 25 kernel32.dll kernel32.dll@0x159dc Ø 26 ntdll.dll ntdll.dll@0x2a630
Updated•9 years ago
|
Updated•9 years ago
|
Updated•9 years ago
|
Comment 126•8 years ago
|
||
[@ js::GCMarker::processMarkStackTop ] Win7, FF45.0a1, 64bit https://crash-stats.mozilla.com/report/index/5484b640-b2fd-4a36-97ad-f74d92151119 Crashing Thread Frame Module Signature Source 0 xul.dll js::GCMarker::processMarkStackTop(js::SliceBudget&) js/src/gc/Marking.cpp 1 xul.dll js::GCMarker::drainMarkStack(js::SliceBudget&) js/src/gc/Marking.cpp 2 xul.dll js::gc::GCRuntime::drainMarkStack(js::SliceBudget&, js::gcstats::Phase) js/src/jsgc.cpp 3 xul.dll js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 4 xul.dll js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 5 xul.dll js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) js/src/jsgc.cpp 6 xul.dll js::gc::GCRuntime::startGC(JSGCInvocationKind, JS::gcreason::Reason, __int64) js/src/jsgc.cpp 7 xul.dll js::gc::GCRuntime::maybePeriodicFullGC() js/src/jsgc.cpp 8 xul.dll JS_MaybeGC(JSContext*) js/src/jsapi.cpp 9 xul.dll mozilla::dom::AutoEntryScript::~AutoEntryScript() dom/base/ScriptSettings.cpp 10 xul.dll nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJS*, unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJSClass.cpp 11 xul.dll nsXPCWrappedJS::CallMethod(unsigned short, XPTMethodDescriptor const*, nsXPTCMiniVariant*) js/xpconnect/src/XPCWrappedJS.cpp 12 xul.dll PrepareAndDispatch xpcom/reflect/xptcall/md/win32/xptcstubs_x86_64.cpp 13 xul.dll SharedStub xpcom/reflect/xptcall/md/win32/xptcstubs_asm_x86_64.asm 14 xul.dll MakeRemoteObject js/ipc/WrapperOwner.cpp 15 xul.dll mozilla::jsipc::WrapperOwner::toObjectVariant(JSContext*, JSObject*, mozilla::jsipc::ObjectVariant*) js/ipc/WrapperOwner.cpp 16 xul.dll mozilla::jsipc::JavaScriptShared::toVariant(JSContext*, JS::Handle<JS::Value>, mozilla::jsipc::JSVariant*) js/ipc/JavaScriptShared.cpp 17 xul.dll mozilla::jsipc::WrapperAnswer::RecvGet(mozilla::jsipc::ObjectId const&, mozilla::jsipc::JSVariant const&, mozilla::jsipc::JSIDVariant const&, mozilla::jsipc::ReturnStatus*, mozilla::jsipc::JSVariant*) js/ipc/WrapperAnswer.cpp 18 xul.dll mozilla::jsipc::JavaScriptBase<mozilla::jsipc::PJavaScriptChild>::RecvGet(unsigned __int64 const&, mozilla::jsipc::JSVariant const&, mozilla::jsipc::JSIDVariant const&, mozilla::jsipc::ReturnStatus*, mozilla::jsipc::JSVariant*) js/ipc/JavaScriptBase.h 19 xul.dll mozilla::jsipc::PJavaScriptChild::OnMessageReceived(IPC::Message const&, IPC::Message*&) obj-firefox/ipc/ipdl/PJavaScriptChild.cpp 20 xul.dll mozilla::plugins::PPluginModuleChild::OnMessageReceived(IPC::Message const&, IPC::Message*&) obj-firefox/ipc/ipdl/PPluginModuleChild.cpp 21 xul.dll mozilla::ipc::MessageChannel::DispatchSyncMessage(IPC::Message const&, IPC::Message*&) ipc/glue/MessageChannel.cpp 22 xul.dll mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) ipc/glue/MessageChannel.cpp 23 xul.dll mozilla::ipc::MessageChannel::ProcessPendingRequest(IPC::Message const&) ipc/glue/MessageChannel.cpp 24 xul.dll mozilla::ipc::MessageChannel::ProcessPendingRequests() ipc/glue/MessageChannel.cpp 25 xul.dll mozilla::ipc::MessageChannel::Send(IPC::Message*, IPC::Message*) ipc/glue/MessageChannel.cpp 26 xul.dll mozilla::dom::PContentChild::SendRpcMessage(nsString const&, mozilla::dom::ClonedMessageData const&, nsTArray<mozilla::jsipc::CpowEntry> const&, IPC::Principal const&, nsTArray<mozilla::dom::ipc::StructuredCloneData>*) obj-firefox/ipc/ipdl/PContentChild.cpp 27 xul.dll ChildProcessMessageManagerCallback::DoSendBlockingMessage(JSContext*, nsAString_internal const&, mozilla::dom::ipc::StructuredCloneData&, JS::Handle<JSObject*>, nsIPrincipal*, nsTArray<mozilla::dom::ipc::StructuredCloneData>*, bool) dom/base/nsFrameMessageManager.cpp 28 xul.dll nsFrameMessageManager::SendMessage(nsAString_internal const&, JS::Handle<JS::Value>, JS::Handle<JS::Value>, nsIPrincipal*, JSContext*, unsigned char, JS::MutableHandle<JS::Value>, bool) dom/base/nsFrameMessageManager.cpp 29 xul.dll nsFrameMessageManager::SendRpcMessage(nsAString_internal const&, JS::Handle<JS::Value>, JS::Handle<JS::Value>, nsIPrincipal*, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) dom/base/nsFrameMessageManager.cpp 30 xul.dll mozilla::dom::ProcessGlobal::SendRpcMessage(nsAString_internal const&, JS::Handle<JS::Value>, JS::Handle<JS::Value>, nsIPrincipal*, JSContext*, unsigned char, JS::MutableHandle<JS::Value>) dom/base/ProcessGlobal.h 31 xul.dll XPTC__InvokebyIndex xpcom/reflect/xptcall/md/win32/xptcinvoke_asm_x86_64.asm 32 @0x2a7e107 33 xul.dll XPCWrappedNative::CallMethod(XPCCallContext&, XPCWrappedNative::CallMode) js/xpconnect/src/XPCWrappedNative.cpp 34 xul.dll XPC_WN_CallMethod(JSContext*, unsigned int, JS::Value*) js/xpconnect/src/XPCWrappedNativeJSOps.cpp 35 xul.dll js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp 36 xul.dll js::CrossCompartmentWrapper::call(JSContext*, JS::Handle<JSObject*>, JS::CallArgs const&) js/src/proxy/CrossCompartmentWrapper.cpp 37 xul.dll js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp 38 xul.dll js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 39 xul.dll js::jit::DoCallFallback js/src/jit/BaselineIC.cpp 40 @0x77faa71a5c
Updated•8 years ago
|
Comment 127•8 years ago
|
||
From the crash signature [@ js::GCMarker::processMarkStackTop ], the affected versions are: - Beta: 44.0b1, 44.0b99, 44.0b4, 44.0b6, 44.0b9, 44.0b2, 44.0b8, 45.0b2, 45.0b1 - Firefox: 44.0 In the crash signature [@ js::GCMarker::processMarkStackOther ] there are no reports for versions higher than 39. In the crash signature [@ js::GCMarker::processMarkStackTop() ] there are no reports in the last 7 days. In the crash signature [@ js::GCMarker::processMarkStackTop(js::SliceBudget&) ] there are no reports in the last 7 days. In the crash signature [@ PushMarkStack ] there are no reports for versions higher than 39. In the crash signature [@ ScanRope ] there are no reports for versions higher than 39. In the crash signature [@ ScanShape ] there are no reports for versions higher than 38. In the crash signature [@ ScanTypeObject ] there are no reports for versions higher than 35. In the crash signature [@ ScanLinearString ] there are no reports for versions higher than 38. In the crash signature [@ ScanBaseShape ] there are no reports for versions higher than 38. In the crash signature [@ js::gc::Mark<JSAtom> ] there are no reports in the last 7 days. In the crash signature [@ ScanString ] there are no reports for versions higher than 38. In the crash signature @ js::gc::Mark<T> ] there are no reports for versions higher than 39.
Comment 128•8 years ago
|
||
¡Hola! bp-bdb10851-7bc0-4651-b70e-00fbe2160221 Crashing Thread (0) Frame Module Signature Source 0 xul.dll js::GCMarker::processMarkStackTop(js::SliceBudget&) js/src/gc/Marking.cpp 1 xul.dll js::GCMarker::drainMarkStack(js::SliceBudget&) js/src/gc/Marking.cpp 2 xul.dll js::gc::GCRuntime::drainMarkStack(js::SliceBudget&, js::gcstats::Phase) js/src/jsgc.cpp 3 xul.dll js::gc::GCRuntime::incrementalCollectSlice(js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 4 xul.dll js::gc::GCRuntime::gcCycle(bool, js::SliceBudget&, JS::gcreason::Reason) js/src/jsgc.cpp 5 xul.dll js::gc::GCRuntime::collect(bool, js::SliceBudget, JS::gcreason::Reason) js/src/jsgc.cpp 6 xul.dll js::gc::GCRuntime::gcSlice(JS::gcreason::Reason, __int64) js/src/jsgc.cpp 7 xul.dll nsJSContext::GarbageCollectNow(JS::gcreason::Reason, nsJSContext::IsIncremental, nsJSContext::IsShrinking, __int64) dom/base/nsJSEnvironment.cpp 8 xul.dll nsTimerImpl::Fire() xpcom/threads/nsTimerImpl.cpp 9 xul.dll nsTimerEvent::Run() xpcom/threads/TimerThread.cpp 10 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 11 xul.dll NS_ProcessNextEvent(nsIThread*, bool) xpcom/glue/nsThreadUtils.cpp 12 xul.dll nsPrintingProxy::ShowPrintDialog(mozIDOMWindowProxy*, nsIWebBrowserPrint*, nsIPrintSettings*) embedding/components/printingui/ipc/nsPrintingProxy.cpp 13 xul.dll nsPrintEngine::DoCommonPrint(bool, nsIPrintSettings*, nsIWebProgressListener*, nsIDOMDocument*) layout/printing/nsPrintEngine.cpp 14 xul.dll nsPrintEngine::CommonPrint(bool, nsIPrintSettings*, nsIWebProgressListener*, nsIDOMDocument*) layout/printing/nsPrintEngine.cpp 15 xul.dll nsPrintEngine::Print(nsIPrintSettings*, nsIWebProgressListener*) layout/printing/nsPrintEngine.cpp 16 xul.dll nsDocumentViewer::Print(nsIPrintSettings*, nsIWebProgressListener*) layout/base/nsDocumentViewer.cpp 17 xul.dll nsGlobalWindow::PrintOuter(mozilla::ErrorResult&) dom/base/nsGlobalWindow.cpp 18 xul.dll nsGlobalWindow::Print(mozilla::ErrorResult&) dom/base/nsGlobalWindow.cpp 19 xul.dll mozilla::dom::WindowBinding::print obj-firefox/dom/bindings/WindowBinding.cpp 20 xul.dll mozilla::dom::WindowBinding::genericMethod obj-firefox/dom/bindings/WindowBinding.cpp 21 xul.dll js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp 22 xul.dll Interpret js/src/vm/Interpreter.cpp 23 xul.dll js::RunScript(JSContext*, js::RunState&) js/src/vm/Interpreter.cpp 24 xul.dll js::Invoke(JSContext*, JS::CallArgs const&, js::MaybeConstruct) js/src/vm/Interpreter.cpp 25 xul.dll js::Invoke(JSContext*, JS::Value const&, JS::Value const&, unsigned int, JS::Value const*, JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 26 xul.dll mozilla::dom::EventListener::HandleEvent(JSContext*, JS::Handle<JS::Value>, mozilla::dom::Event&, mozilla::ErrorResult&) obj-firefox/dom/bindings/EventListenerBinding.cpp 27 xul.dll mozilla::dom::EventListener::HandleEvent<mozilla::dom::EventTarget*>(mozilla::dom::EventTarget* const&, mozilla::dom::Event&, mozilla::ErrorResult&, char const*, mozilla::dom::CallbackObject::ExceptionHandling, JSCompartment*) obj-firefox/dist/include/mozilla/dom/EventListenerBinding.h 28 xul.dll mozilla::EventListenerManager::HandleEventInternal(nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent**, mozilla::dom::EventTarget*, nsEventStatus*) dom/events/EventListenerManager.cpp 29 xul.dll mozilla::EventTargetChainItem::HandleEventTargetChain(nsTArray<mozilla::EventTargetChainItem>&, mozilla::EventChainPostVisitor&, mozilla::EventDispatchingCallback*, mozilla::ELMCreationDetector&) dom/events/EventDispatcher.cpp 30 xul.dll mozilla::EventDispatcher::Dispatch(nsISupports*, nsPresContext*, mozilla::WidgetEvent*, nsIDOMEvent*, nsEventStatus*, mozilla::EventDispatchingCallback*, nsTArray<mozilla::dom::EventTarget*>*) dom/events/EventDispatcher.cpp 31 xul.dll PresShell::DispatchEventToDOM(mozilla::WidgetEvent*, nsEventStatus*, nsPresShellEventCB*) layout/base/nsPresShell.cpp 32 xul.dll PresShell::HandleEventInternal(mozilla::WidgetEvent*, nsEventStatus*, bool) layout/base/nsPresShell.cpp 33 xul.dll PresShell::HandleEventWithTarget(mozilla::WidgetEvent*, nsIFrame*, nsIContent*, nsEventStatus*) layout/base/nsPresShell.cpp 34 xul.dll mozilla::EventStateManager::CheckForAndDispatchClick(mozilla::WidgetMouseEvent*, nsEventStatus*) dom/events/EventStateManager.cpp 35 xul.dll mozilla::EventStateManager::PostHandleEvent(nsPresContext*, mozilla::WidgetEvent*, nsIFrame*, nsEventStatus*) dom/events/EventStateManager.cpp 36 xul.dll PresShell::HandleEventInternal(mozilla::WidgetEvent*, nsEventStatus*, bool) layout/base/nsPresShell.cpp 37 xul.dll PresShell::HandlePositionedEvent(nsIFrame*, mozilla::WidgetGUIEvent*, nsEventStatus*) layout/base/nsPresShell.cpp 38 xul.dll PresShell::HandleEvent(nsIFrame*, mozilla::WidgetGUIEvent*, bool, nsEventStatus*, nsIContent**) layout/base/nsPresShell.cpp 39 xul.dll nsViewManager::DispatchEvent(mozilla::WidgetGUIEvent*, nsView*, nsEventStatus*) view/nsViewManager.cpp 40 xul.dll nsView::HandleEvent(mozilla::WidgetGUIEvent*, bool) view/nsView.cpp 41 xul.dll mozilla::widget::PuppetWidget::DispatchEvent(mozilla::WidgetGUIEvent*, nsEventStatus&) widget/PuppetWidget.cpp 42 xul.dll mozilla::layers::APZCCallbackHelper::DispatchWidgetEvent(mozilla::WidgetGUIEvent&) gfx/layers/apz/util/APZCCallbackHelper.cpp 43 xul.dll mozilla::dom::TabChild::RecvRealMouseButtonEvent(mozilla::WidgetMouseEvent const&, mozilla::layers::ScrollableLayerGuid const&, unsigned __int64 const&) dom/ipc/TabChild.cpp 44 xul.dll mozilla::dom::PBrowserChild::OnMessageReceived(IPC::Message const&) obj-firefox/ipc/ipdl/PBrowserChild.cpp 45 xul.dll mozilla::dom::PContentChild::OnMessageReceived(IPC::Message const&) obj-firefox/ipc/ipdl/PContentChild.cpp 46 xul.dll mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) ipc/glue/MessageChannel.cpp 47 xul.dll mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) ipc/glue/MessageChannel.cpp 48 xul.dll mozilla::ipc::MessageChannel::OnMaybeDequeueOne() ipc/glue/MessageChannel.cpp 49 xul.dll RunnableMethod<mozilla::ipc::MessageChannel, bool ( mozilla::ipc::MessageChannel::*)(void), mozilla::Tuple<> >::Run() ipc/chromium/src/base/task.h 50 xul.dll MessageLoop::DoWork() ipc/chromium/src/base/message_loop.cc 51 xul.dll mozilla::ipc::DoWorkRunnable::Run() ipc/glue/MessagePump.cpp 52 xul.dll nsThread::ProcessNextEvent(bool, bool*) xpcom/threads/nsThread.cpp 53 xul.dll mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 54 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 55 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 56 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 57 xul.dll nsBaseAppShell::Run() widget/nsBaseAppShell.cpp 58 xul.dll nsAppShell::Run() widget/windows/nsAppShell.cpp 59 xul.dll XRE_RunAppShell toolkit/xre/nsEmbedFunctions.cpp 60 xul.dll mozilla::ipc::MessagePumpForChildProcess::Run(base::MessagePump::Delegate*) ipc/glue/MessagePump.cpp 61 xul.dll MessageLoop::RunHandler() ipc/chromium/src/base/message_loop.cc 62 xul.dll MessageLoop::Run() ipc/chromium/src/base/message_loop.cc 63 xul.dll XRE_InitChildProcess toolkit/xre/nsEmbedFunctions.cpp 64 plugin-container.exe wmain toolkit/xre/nsWindowsWMain.cpp 65 plugin-container.exe __tmainCRTStartup f:/dd/vctools/crt/crtw32/startup/crt0.c:255 66 kernel32.dll BaseThreadInitThunk 67 ntdll.dll RtlUserThreadStart 68 kernel32.dll BasepReportFault 69 kernel32.dll BasepReportFault ¡Gracias!
Updated•8 years ago
|
Comment 129•8 years ago
|
||
Hey naveed, can you give us some information on what you want to do with this? should we continue to track or let it drop off the radar?
Updated•8 years ago
|
Comment 130•8 years ago
|
||
(In reply to Jim Mathies [:jimm] from comment #129) > Hey naveed, can you give us some information on what you want to do with > this? should we continue to track or let it drop off the radar? This is another signature where any sort of heap corruption will show up. I'm not seeing any recent spikes in crash stats, so I don't think there is anything new here. E.g. we're still just seeing the noise floor of misbehaving hardware. Let's leave the bug open to track spikes, but we certainly shouldn't be blocking anything on it.
Comment 131•8 years ago
|
||
Also, this is unactionable, so I don't want to give the impression that I'm working on anything specific here.
Comment 133•7 years ago
|
||
Hi Milan, Naveed, This crash is getting worse in Beta51. It becomes #6 topcrash. Do we have any idea how to get this one move forward?
Comment 134•7 years ago
|
||
(In reply to Gerry Chang [:gchang] from comment #133) As others have said, this is a catch-all crash that can be triggered by any kind of heap corruption. Do we have any information about when this started spiking that might indicate what's caused this?
Comment 135•7 years ago
|
||
marco, can you help tease through to see if we can identify this?
Comment 136•7 years ago
|
||
The signature is somewhat periodic on Beta: https://crash-stats.mozilla.com/signature/?release_channel=beta&product=Firefox&signature=js%3A%3AGCMarker%3A%3AprocessMarkStackTop&date=%3E%3D2016-07-04T19%3A05%3A18.000Z&date=%3C2017-01-04T19%3A05%3A18.000Z#graphs The latest spike is around Dec 14: https://crash-stats.mozilla.com/signature/?product=Firefox&version=51.0b&signature=js%3A%3AGCMarker%3A%3AprocessMarkStackTop&date=%3E%3D2016-12-04T19%3A04%3A06.000Z&date=%3C2017-01-04T19%3A04%3A06.000Z#graphs Before Dec 14, the crash was basically non-existent on 51.0b. If you look at the graph for "js::GCMarker::lazilyMarkChildren", it's basically the complementary, so I think the two signatures are related: https://crash-stats.mozilla.com/signature/?product=Firefox&release_channel=beta&signature=js%3A%3AGCMarker%3A%3AlazilyMarkChildren&date=%3E%3D2016-07-04T19%3A16%3A38.000Z&date=%3C2017-01-04T19%3A16%3A38.000Z#graphs.
Updated•7 years ago
|
Comment 138•7 years ago
|
||
Have gotten a number of crashes here lately, mostly in lazilymarkchildren. Also a couple in ProcessMarkStackTop. Regular crash here. https://crash-stats.mozilla.com/report/index/4452b8d3-b218-4218-af8d-b2dc12170206 https://crash-stats.mozilla.com/report/index/b459571a-ce82-4c3e-bf19-b357a2170204
Comment 139•7 years ago
|
||
(In reply to Robert Lindsay from comment #138) > Have gotten a number of crashes here lately, mostly in lazilymarkchildren. > Also a couple in ProcessMarkStackTop. Regular crash here. > > https://crash-stats.mozilla.com/report/index/4452b8d3-b218-4218-af8d- > b2dc12170206 > > https://crash-stats.mozilla.com/report/index/b459571a-ce82-4c3e-bf19- > b357a2170204 Do you have steps to reproduce the crash?
Comment 140•7 years ago
|
||
(In reply to Marco Castelluccio [:marco] from comment #139) > (In reply to Robert Lindsay from comment #138) > > Have gotten a number of crashes here lately, mostly in lazilymarkchildren. > > Also a couple in ProcessMarkStackTop. Regular crash here. > > > > https://crash-stats.mozilla.com/report/index/4452b8d3-b218-4218-af8d- > > b2dc12170206 > > > > https://crash-stats.mozilla.com/report/index/b459571a-ce82-4c3e-bf19- > > b357a2170204 No, sorry, but I am still getting these crashes. They do not seem to be related to much of anything. But they often happen when I am beginning to scroll down a new page, say a new email in Gmail or if I got to a webpage, as soon as I start scrolling down, it crashes. A lot of the crashes happen on Gmail too. > > Do you have steps to reproduce the crash?
Updated•7 years ago
|
Updated•7 years ago
|
Comment 142•7 years ago
|
||
The crashes still continue: https://crash-stats.mozilla.com/report/index/7af2a0c1-56a7-4241-b1d5-f891d1170603
Comment 143•7 years ago
|
||
There's a new spike for the js::GCMarker::lazilyMarkChildren signature on beta and nightly, as the number of crashes jumped from Friday to Saturday from about 5 per day to 55: https://crash-stats.mozilla.com/search/?release_channel=beta&signature=%3Djs%3A%3AGCMarker%3A%3AlazilyMarkChildren&product=Firefox&version=54.0b13&version=54.0b12&version=54.0b11&version=54.0b10&version=54.0b9&version=54.0b8&version=54.0b7&version=54.0b6&version=54.0b5&version=54.0b4&version=54.0b3&version=54.0b2&version=54.0b1&date=%3E%3D2017-06-03T00%3A00%3A00.000Z&date=%3C2017-06-04T00%3A00%3A00.000Z&_sort=-date&_facets=url&_facets=user_comments&_facets=install_time&_facets=version&_facets=address&_facets=moz_crash_reason&_facets=reason&_facets=build_id&_facets=platform_pretty_version&_columns=date&_columns=signature&_columns=product&_columns=version&_columns=build_id&_columns=platform#crash-reports
Comment 144•7 years ago
|
||
Philipp mentioned that the [@ js::DispatchTyped<T> ] signature that is also attached to this bug is declining, so it is a 0-sum-game in total: https://crash-stats.mozilla.com/signature/?release_channel=beta&product=Firefox&signature=js%3A%3ADispatchTyped%3CT%3E#graphs Since this is a pretty low volume change I'll just consider this work in progress.
Updated•7 years ago
|
Comment 145•7 years ago
|
||
[Tracking Requested - why for this release]:
Updated•6 years ago
|
Comment 146•6 years ago
|
||
@js::GCMarker::lazilyMarkChildren is showing up as a top crash in 59.b0 (dev edition) with ~7000 crashes in the last week, but they are from only 33 installations. I don't think this is a blocking issue for further beta versions.
Comment hidden (spam) |
Updated•6 years ago
|
Comment 148•6 years ago
|
||
I have been getting these crashes for a long time on every new iteration of FF such that I was stuck way back on an old version, the only one that would not crash, I think FF 52. After that version, I started getting this crash. I would like to point out that I am now on FF 58 and I have not gotten one single crash in ProcessMarkStackTop or LazilyMarkChildren, and I definitely should have gotten them by now. So they've stopped for me at least and AFAICT, FF 58 has fixed this crash. Not sure if this helps you. Started at 52x - fixed by 58.
Comment 149•6 years ago
|
||
Looks like this is back in 59.0.1. Please, take a look: https://crash-stats.mozilla.com/signature/?_sort=-date&signature=js%3A%3AGCMarker%3A%3AlazilyMarkChildren&date=%3E%3D2018-03-19T15%3A13%3A24.000Z&date=%3C2018-03-26T17%3A13%3A24.000Z
Updated•6 years ago
|
Updated•6 years ago
|
Comment 151•6 years ago
|
||
This crash is showing up in moderate volume in 62 beta and very high volume on release 61. Jon, can you take another look or is this addressed already in a different bug?
Comment 152•6 years ago
|
||
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #151) This is a perennial GC crash but volumes do seem to have increased recently. I'm going to file a separate bug to investigate.
Updated•6 years ago
|
Comment 153•6 years ago
|
||
Thanks Jon - I'll untrack here and track this for 62 in bug 1476239.
Comment hidden (spam) |
Comment hidden (spam) |
Comment hidden (spam) |
Updated•3 years ago
|
Comment 157•2 years ago
|
||
Removing signatures for code that doesn't exist any more.
Updated•2 years ago
|
Comment 159•2 years ago
|
||
¡Hola y'all!
Found this crash over at https://support.mozilla.org/questions/1360629#answer-1465751
Updated flags per https://crash-stats.mozilla.org/signature/?product=Firefox&signature=js%3A%3AGCMarker%3A%3AprocessMarkStackTop
Hope this is helpful.
¡Gracias!
Comment 160•2 years ago
|
||
I hit this crash on 105 RC1 with 3 tabs open while I was in Thunderbird composing a message: https://crash-stats.mozilla.org/report/index/8674df40-871d-4311-977b-d93f30220913
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•2 years ago
|
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•1 year ago
|
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Comment hidden (obsolete) |
Updated•1 year ago
|
Comment 173•11 months ago
|
||
Sorry for removing the keyword earlier but there is a recent change in the ranking, so the bug is again linked to a topcrash signature, which matches the following criteria:
- Top 20 desktop browser crashes on release (startup)
- Top 20 desktop browser crashes on beta
- Top 10 content process crashes on beta
- Top 10 content process crashes on release
For more information, please visit BugBot documentation.
Comment 174•10 months ago
|
||
Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.
For more information, please visit BugBot documentation.
Comment 175•10 months ago
|
||
Sorry for removing the keyword earlier but there is a recent change in the ranking, so the bug is again linked to a topcrash signature, which matches the following criteria:
- Top 20 desktop browser crashes on release (startup)
- Top 20 desktop browser crashes on beta
- Top 10 content process crashes on beta
- Top 10 content process crashes on release
For more information, please visit BugBot documentation.
Updated•9 months ago
|
Comment 177•9 months ago
|
||
Copying crash signatures from duplicate bugs.
Comment 178•7 months ago
|
||
Based on the topcrash criteria, the crash signatures linked to this bug are not in the topcrash signatures anymore.
For more information, please visit BugBot documentation.
Comment 179•6 months ago
|
||
Sorry for removing the keyword earlier but there is a recent change in the ranking, so the bug is again linked to topcrash signatures, which match the following criteria:
- Top 20 desktop browser crashes on release (startup)
- Top 10 content process crashes on beta
- Top 10 content process crashes on release
- Top 20 desktop browser crashes on beta
- Top 10 desktop browser crashes on nightly
- Top 5 desktop browser crashes on Linux on release
- Top 5 desktop browser crashes on Mac on release
- Top 5 desktop browser crashes on Windows on release (startup)
For more information, please visit BugBot documentation.
Comment 180•6 months ago
|
||
Marking as stalled since there's no way to directly take action on this bug, at least currently
Comment 181•4 months ago
|
||
Seems https://tsdiagram.com/ reliably reproduce the crash on Firefox 122.0a1 build 20231204214432 on Mac OS X 10.15.
I get mutli crash report with same signature on same site in minutes
https://crash-stats.mozilla.org/report/index/96c58bf9-43a6-4729-89dc-17b790231205
https://crash-stats.mozilla.org/report/index/7fde3c66-3e5e-45b6-90d1-3f9960231205
https://crash-stats.mozilla.org/report/index/3967bb14-ba00-447e-9711-2a6ff0231205
Comment 182•4 months ago
|
||
(In reply to mmis1000 from comment #181)
I haven't been able to reproduce this locally. Any hints on how to reproduce? I'm using the build you mention, macOS (a later version) and a local version of tsdiagram.com without the latest patch that was added to fix this issue.
Can I also ask you to run Apple diagnostics / hardware test to rule out any memory problems on your machine?
Comment 183•4 months ago
|
||
(In reply to Jon Coppeard (:jonco) from comment #182)
(In reply to mmis1000 from comment #181)
I haven't been able to reproduce this locally. Any hints on how to reproduce? I'm using the build you mention, macOS (a later version) and a local version of tsdiagram.com without the latest patch that was added to fix this issue.Can I also ask you to run Apple diagnostics / hardware test to rule out any memory problems on your machine?
It seems reproducible to me on local build, (hash: fad088c
, run pnpm run build
and serve the /dist
directory using npx serve
.
About the system info.
機型名稱: MacBook Pro
機型識別碼: MacBookPro18,1
機型型號: MK1E3TA/A
晶片: Apple M1 Pro
總核心數目: 10(8效能和2效率)
記憶體: 16 GB
系統韌體版本: 10151.41.12
OS裝載程式版本: 10151.41.12
序號(系統): MHYQWR7247
硬體UUID: C955E691-EC46-55A6-9F5D-F209EF0C729E
佈建UDID: 00006000-000C20512EC3801E
啟用鎖定狀態: 已停用
The machine is in zh-TW locale, so is the information.
Comment 184•4 months ago
|
||
And I also run it with a new profile to ensure the crash is not caused by the extensions. And same crash happened.
Notice: you need to rerun pnpm install
after checkout the specific commit because it changed the dependency. And checkout commit alone do not rerun the pnpm install
Description
•