Open Bug 719114 Opened 8 years ago Updated 2 months ago

Crash in [@ js::GCMarker::processMarkStackTop ] from heap corruption

Categories

(Core :: JavaScript: GC, defect, critical)

38 Branch
defect
Not set
critical

Tracking

()

Tracking Status
firefox42 --- wontfix
firefox43 --- wontfix
firefox44 --- wontfix
firefox45 --- wontfix
firefox46 --- wontfix
firefox47 --- wontfix
firefox-esr38 --- wontfix
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox56 --- wontfix
firefox57 --- wontfix
firefox58 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 - wontfix
firefox62 - fix-optional

People

(Reporter: Swarnava, Unassigned)

References

(Depends on 1 open bug, Blocks 1 open bug)

Details

(4 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
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
Assignee: nobody → general
Blocks: 708382
Component: General → JavaScript Engine
Keywords: regression, topcrash
OS: Windows NT → Windows 7
Product: Firefox → Core
QA Contact: general → general
Version: unspecified → 11 Branch
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.
Crash Signature: [@ js::GCMarker::processMarkStackTop()] → [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ]
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
OS: Windows 7 → All
Hardware: x86 → All
Duplicate of this bug: 730283
Crash Signature: [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] → [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)]
Summary: Firefox Crash [@ js::GCMarker::processMarkStackTop() ] → Firefox Crash @ js::GCMarker::processMarkStackTop
At #30 for 11b4.
Blocks: 745334
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.
Blocks: 735099
Spike seems to have been temporary, probably from IGC as you say. Minusing for now, please renom if it spikes again.
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.
Blocks: 767937
Blocks: 767970
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
Blocks: 766887
Crash Signature: [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] → [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ 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?
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.
Keywords: qawanted
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&)
Attached file windbg stacktrace
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.
QA Contact: mozillamarcia.knous
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
Attached file pdf testcase
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
> 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.
Attached file PDF referenced by comment 52 (obsolete) —
Let's try this again.  I guess Bugzilla sucks at auto identifying PDFs.
Attachment #661597 - Attachment is obsolete: true
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.
Depends on: 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?
Depends on: 793257
No longer depends on: 792226
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=????????
Attached file Another WinDbg log
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.
Duplicate of this bug: 753737
Blocks: 803018
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
Depends on: 817342
This is the #2 browser crash in 18.0b4 and #4 on 17.0.1
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
Crash Signature: [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackOther ] → [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackOther ] [@ PushMarkStack ]
Let's add also ScanRope, ScanShape, ScanTypeObject and ScanLinearString that have a similar stack trace except for the one or two first frames.
Crash Signature: [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackOther ] [@ PushMarkStack ] → [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackOther ] [@ PushMarkStack ] [@ ScanRope ] [@ ScanShape ] [@ ScanTypeObject ] [@ …
Depends on: 871249
Duplicate of this bug: 878061
Crash Signature: ScanLinearString ] → ScanLinearString ] [@ ScanBaseShape ]
Duplicate of this bug: 846254
Crash Signature: ScanLinearString ] [@ ScanBaseShape ] → ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ]
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%.
Crash Signature: ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] → ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] [@ ScanString ]
Depends on: 903318
Whiteboard: [unactionable]
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
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
Duplicate of this bug: 920266
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?
Flags: needinfo?
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.
Flags: needinfo?
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.
Duplicate of this bug: 926518
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%
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.
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.
Duplicate of this bug: 1011296
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.
Assignee: general → nobody
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
Flags: needinfo?(swarnavasengupta)
(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.
Flags: needinfo?(swarnavasengupta)
i cant reproduce this crash anymore, if you have are able to reproduce, feel fee to post it here
Crash Signature: ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] [@ ScanString ] → ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] [@ ScanString ] [@ js::gc::Mark<T> ]
[@ 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
Blocks: killhard-win
Whiteboard: [unactionable] → [unactionable], KillHard
Blocks: shutdownkill
No longer blocks: killhard-win
Whiteboard: [unactionable], KillHard → [unactionable], ShutDownKill
Duplicate of this bug: 1038001
See Also: → 654196
Component: JavaScript Engine → JavaScript: GC
Version: 11 Branch → Trunk
Summary: Firefox Crash @ js::GCMarker::processMarkStackTop → Crash in [@ js::GCMarker::processMarkStackTop ]
Version: Trunk → 45 Branch
[@ 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?
Flags: needinfo?(nihsanullah)
Assignee: nobody → terrence
Flags: needinfo?(nihsanullah)
(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.
Assignee: terrence → nobody
Duplicate of this bug: 1257309
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?
Flags: needinfo?(nihsanullah)
Flags: needinfo?(milan)
(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?
Flags: needinfo?(mcastelluccio)
Duplicate of this bug: 1259214
Crash Signature: ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] [@ ScanString ] [@ js::gc::Mark<T> ] → ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] [@ ScanString ] [@ js::gc::Mark<T> ] [@ js::GCMarker::lazilyMarkChildren ]
See Also: → 1265566
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?
Flags: needinfo?(lindsay.robert)
(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?
Flags: needinfo?(milan)
Duplicate of this bug: 1348531
Crash Signature: ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] [@ ScanString ] [@ js::gc::Mark<T> ] [@ js::GCMarker::lazilyMarkChildren ] → ScanLinearString ] [@ ScanBaseShape ] [@ js::gc::Mark<JSAtom> ] [@ ScanString ] [@ js::gc::Mark<T> ] [@ js::GCMarker::lazilyMarkChildren ] [@ js::DispatchTyped<T> ]
Depends on: 1366083
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.
Flags: needinfo?(nihsanullah)
Flags: needinfo?(lindsay.robert)
[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.
Summary: Crash in [@ js::GCMarker::processMarkStackTop ] → Crash in [@ js::GCMarker::processMarkStackTop ] from heap corruption
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.
See Also: → 815141
Crash Signature: [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackOther ] [@ PushMarkStack ] [@ ScanRope ] [@ ScanShape ] [@ ScanTypeObject ] [@ … → [@ js::GCMarker::processMarkStackTop()] [@ js::GCMarker::processMarkStackTop ] [@ js::GCMarker::processMarkStackTop(js::SliceBudget&)] [@ js::GCMarker::processMarkStackOther ] [@ static class js::NativeObject* CallTraceHook<T>] [@ PushMarkStack ] [@…
Duplicate of this bug: 1470949
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?
Flags: needinfo?(jcoppeard)
(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.
Flags: needinfo?(jcoppeard)
Depends on: 1476239
Thanks Jon - I'll untrack here and track this for 62 in bug 1476239.
You need to log in before you can comment on or make changes to this bug.