crash in js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::trace(js::gc::StoreBuffer*, js::TenuringTracer&)




JavaScript: GC
3 years ago
3 years ago


(Reporter: ashughes, Unassigned)


({crash, regression})

crash, regression

Firefox Tracking Flags

(Not tracked)


(crash signature)



3 years ago
This bug was filed from the Socorro interface and is 
report bp-30c8d311-8cdb-49aa-adaa-2ec492150519.
0 	XUL 	js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::trace(js::gc::StoreBuffer*, js::TenuringTracer&) 	js/src/jsgcinlines.h
1 	XUL 	js::Nursery::collect(JSRuntime*, JS::gcreason::Reason, js::Vector<js::ObjectGroup*, 0ul, js::SystemAllocPolicy>*) 	js/src/gc/StoreBuffer.h
2 	XUL 	js::gc::GCRuntime::minorGC(JSContext*, JS::gcreason::Reason) 	js/src/jsgc.cpp
3 	XUL 	JSObject* js::Allocate<JSObject, (js::AllowGC)1>(js::ExclusiveContext*, js::gc::AllocKind, unsigned long, js::gc::InitialHeap, js::Class const*) 	js/src/gc/Allocator.cpp
4 	XUL 	js::ArrayObject::createArrayInternal(js::ExclusiveContext*, js::gc::AllocKind, js::gc::InitialHeap, JS::Handle<js::Shape*>, JS::Handle<js::ObjectGroup*>) 	js/src/vm/ArrayObject-inl.h
5 	XUL 	js::NewDenseFullyAllocatedArray(js::ExclusiveContext*, unsigned int, JS::Handle<JSObject*>, js::NewObjectKind) 	js/src/vm/ArrayObject-inl.h
6 	XUL 	js::NewDenseArray(js::ExclusiveContext*, unsigned int, JS::Handle<js::ObjectGroup*>, js::AllocatingBehaviour, bool) 	js/src/jsarray.cpp
7 		@0x12144bbfd 	
More reports:

I've hit this crash three times today. Every time it seems to have been while on Google Maps, searching for or altering directions between two points on the map.

Comment 1

3 years ago
Looking at the reports, Google Maps shows up the most in URLs. All crashes are with Firefox 41.0a1 20150519030202 on Mac OSX 10.10 so this might be a very recent regression.
Keywords: regression
google maps crashes within seconds when I do some zooming.
I can consistently reproduce this on google maps with nightly when trying to adjust my arrival time for some directions. Doing the same operation on aurora from 2015-05-19 works perfectly.
Could you look into this, Terrence?
Flags: needinfo?(terrence)
So, that's either bug 1163485, bug 1156708 or bug 1154881.
Flags: needinfo?(jyavenard)
Flags: needinfo?(ajones)
Go to
Type in 220 Yonge Street (choose Toronto one)
Click directions
Click pedestrian
They'll be a major zoom out and a crash.
10.9.5, Retina display.
Flags: needinfo?(terrence)
[Tracking Requested - why for this release]: new crash on Google Maps.
tracking-firefox41: --- → ?
Appears to reproduce on MacOSX 10.10, but not linux. Taking a closer look.
Err, nevermind. Seems I'm off the hook!
Bug 1166730 looks similar and might be related.
Assigning to Jean-Yves as all three of the bugs from comment 6 were his.
Assignee: nobody → jyavenard
and how would a MP4 player be related to Google maps and JS again?

At no time would that code path be entered.
Flags: needinfo?(jyavenard)
Naveed - any chance this is a JS issue?
Flags: needinfo?(nihsanullah)
It would certainly make more sense if it was a JS issue, from the crash signature. Somebody else could try doing the regression and see if it turns up something else.

Comment 16

3 years ago
I get a slightly different inbound window than Milan reported above.

Last good revision: dcc84a242cde
First bad revision: 356231081116

This would seem to blame bug 1162199 - ccing Brian Hackett.
Blocks: 1162199
Flags: needinfo?(bhackett1024)
OS: Mac OS X → All
Hardware: Unspecified → All
Flags: needinfo?(nihsanullah)
Flags: needinfo?(ajones)
(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #16)

> This would seem to blame bug 1162199 - ccing Brian Hackett.

This is also what Alice found for bug 1166730 :
Assignee: jyavenard → nobody
Is this a dupe of bug 1166277?
Flags: needinfo?(bhackett1024)

Comment 19

3 years ago
(In reply to Brian Hackett (:bhackett) from comment #18)
> Is this a dupe of bug 1166277?

It looks like the same signature and the same regression window. Marking this as a dupe.
Last Resolved: 3 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1166277
No longer blocks: 1162199
status-firefox41: affected → ---
tracking-firefox41: ? → ---
Crash Signature: [@ js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::trace(js::gc::StoreBuffer*, js::TenuringTracer&)]

Comment 20

3 years ago
Please do not remove crash signatures, even from dupes.
Crash Signature: [@ js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::trace(js::gc::StoreBuffer*, js::TenuringTracer&)]
but they pollute the "Bugzilla" tab in crash log report,
it's especially visible on many Adobe crash bugs like bug #774281 and bug #789379,
you should also get about 3 week ago email from Benjamin Smedberg explaining some things about it.

Comment 22

3 years ago
(In reply to Virtual_ManPL [:Virtual] from comment #21)
> but they pollute the "Bugzilla" tab in crash log report

This is not a "pollution", it's a track record of how things were reported. In various reports, we also mark anyway which bugs are still open and which resolved in some way, duplicate or other, so it ends up as a minor nuisance. Note that I'm one of the main people at Mozilla working with crash stats and have been for a while.

Comment 23

3 years ago
(In reply to Virtual_ManPL [:Virtual] from comment #21)
> but they pollute the "Bugzilla" tab in crash log report

I agree with KaiRo in this case. Further discussion about this should happen outside of this bug - probably on one of our mailing lists.
You need to log in before you can comment on or make changes to this bug.