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

Please be more specific: rank in different versions, different stacks, component, interesting comments, STR, regression range...

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.

Adding [@ js::GCMarker::processMarkStackTop ] which is a Mac signature seen in low volume on the trunk the past two days.

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

At #30 for 11b4.

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.

Spike seems to have been temporary, probably from IGC as you say. Minusing for now, please renom if it spikes again.

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

It's #9 top browser crasher in 15.0a2 and #19 in 16.0a1.

Let's let this sit for a bit longer and make sure it's not a temporary spike before tracking.

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.

(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).

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)

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.

Thanks Bill. Untracking based on your comment.

(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.

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.

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?

(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()

Am not seeing this in 15 topcrashers and this has been around since Firefox 11 so this isn't a candidate for 15 tracking.

(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.

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

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?

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

The prevalence of about: pages seems to indicate this crash might happen after restarting Firefox, wouldn't it?

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)?

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?

[@ 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.

(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.)

Dropping QAWANTED because I don't see any new leads in this bug where QA can assist. Please re-add if this changes.

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.

It's #7 top browser crasher in 15.0b4 and b5 so bug 782825 has had no effect on this bug.

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?

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&)

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)

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).

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.

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.

(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.

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

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

> pdf testcase Testcase came from http://www.straitstimes.com/sites/straitstimes.com/files/ST_20120914_SWIPHONE14_3298937.pdf

> 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.

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.

Let's try this again. I guess Bugzilla sucks at auto identifying PDFs.

I can't reproduce on Windows 7 with the STR in comment 52.

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

(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.

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.

(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?

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.

(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=????????

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).

(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.

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.

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

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)

This is the #2 browser crash in 18.0b4 and #4 on 17.0.1

Crash Report: bp-f187eb97-a0b5-4eb3-ba5a-f13862130317

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.

(In reply to Scoobidiver from comment #74) > #26 in 23.0a1. now #14 and even #5 without fixed top crashers.

There's a new crash signature in 21.0b6: https://crash-stats.mozilla.com/report/list?signature=PushMarkStack

Let's add also ScanRope, ScanShape, ScanTypeObject and ScanLinearString that have a similar stack trace except for the one or two first frames.

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%.

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

hit this running the JS debugger in Firefox Nightly. https://crash-stats.mozilla.com/report/index/08b021f8-6390-428f-8663-207762130920

#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

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?

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

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.

(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)

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

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.

(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.

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

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?

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.

Also, this is consistently in topcrash ranges on releases and betas.

A GCMarker related PushMarkStack crash is in the top 10 crashers for Fx28 this week, with 259/6772 crashes.

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.

(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.

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.

Current Rank > Firefox 29: #5 @ 1.86% > Firefox 28: #3 @ 2.77% > Firefox 27: #1 @ 4.69% > Firefox 26: #1 @ 3.76%

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

Wontfix for Firefox 26 as it's EOL with tomorrow's Firefox 27 release.

This is showing up as a topcrasher, across several crash signatures, in the top 10 crashes for Firefox 31.

Still one of the top crashers on Fx29.

Thanks Juan to bring that to our attention.

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.

This is a top crash on Firefox for Android nightly.

I too had this crash today Crash ID : bp-1fd806e7-c0f4-4d6f-aeca-058662140608

Not sure if we want to continue to track this given this is still unactionable, but it remains a top issue.

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.

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.

Happened for me earlier in Firefox Nightkly 34.0a1: https://crash-stats.mozilla.com/report/index/59adb78c-fbc1-4849-b585-1abbc2140804

Happened for me earlier in Firefox Nightly 34.0a1: https://crash-stats.mozilla.com/report/index/59adb78c-fbc1-4849-b585-1abbc2140804

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.

Top crash positions for bug 71911 related crashes 35.0b #14 ...MarkStackTop... #16

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

¡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

(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.

i cant reproduce this crash anymore, if you have are able to reproduce, feel fee to post it here

[@ 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

[@ 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

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.

¡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!

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?

(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.

Also, this is unactionable, so I don't want to give the impression that I'm working on anything specific here.

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?

(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?

marco, can you help tease through to see if we can identify this?

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.

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

(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?

(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?

The crashes still continue: https://crash-stats.mozilla.com/report/index/7af2a0c1-56a7-4241-b1d5-f891d1170603

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

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.

[Tracking Requested - why for this release]:

@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.

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.

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

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?

(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.

Thanks Jon - I'll untrack here and track this for 62 in bug 1476239.