Closed Bug 1166542 Opened 9 years ago Closed 9 years ago

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

Categories

(Core :: JavaScript: GC, defect)

defect
Not set
critical

Tracking

()

RESOLVED DUPLICATE of bug 1166277

People

(Reporter: u279076, Unassigned)

Details

(Keywords: crash, regression)

Crash Data

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:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=js%3A%3Agc%3A%3AStoreBuffer%3A%3AMonoTypeBuffer%3Cjs%3A%3Agc%3A%3AStoreBuffer%3A%3AWholeCellEdges%3E%3A%3Atrace%28js%3A%3Agc%3A%3AStoreBuffer%2A%2C+js%3A%3ATenuringTracer%26%29

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.
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)
My STR:
Go to maps.google.com
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.
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.
I get a slightly different inbound window than Milan reported above.

Last good revision: dcc84a242cde
First bad revision: 356231081116
Pushlog:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=dcc84a242cde&tochange=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 : https://bugzilla.mozilla.org/show_bug.cgi?id=1166730#c11
Assignee: jyavenard → nobody
Is this a dupe of bug 1166277?
Flags: needinfo?(bhackett1024)
(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.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
Crash Signature: [@ js::gc::StoreBuffer::MonoTypeBuffer<js::gc::StoreBuffer::WholeCellEdges>::trace(js::gc::StoreBuffer*, js::TenuringTracer&)]
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.
(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.
(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.