820805 - crash in js::ion::IonBailoutIterator::IonBailoutIterator or js::ion::OperatorIn

Status: RESOLVED WONTFIX

(Core :: JavaScript Engine, defect)

Description

[Scoobidiver (away)]

It began spiking in 19.0a2/20121211 and is #3 top browser crasher over the last day. The regression range for the spike is:
http://hg.mozilla.org/releases/mozilla-aurora/pushloghtml?fromchange=a264305757b9&tochange=c042ea08a2b4
It might be caused by bug 791214.

Signature 	js::ion::IonBailoutIterator::IonBailoutIterator(js::ion::IonActivationIterator const&, js::ion::BailoutStack*) More Reports Search
UUID	9f0907bd-0d97-48e1-99cd-b60222121211
Date Processed	2012-12-11 16:56:08
Uptime	4149
Install Age	1.2 hours since version was first installed.
Install Time	2012-12-11 15:46:43
Product	Firefox
Version	19.0a2
Build ID	20121211042015
Release Channel	aurora
OS	Mac OS X
OS Version	10.7.5 11G63
Build Architecture	amd64
Build Architecture Info	family 6 model 42 stepping 7
Crash Reason	EXC_BAD_ACCESS / KERN_INVALID_ADDRESS
Crash Address	0xa8
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x 126GL Context? GL Context+ GL Layers? GL Layers+ 
Processor Notes 	/data/socorro/stackwalk/bin/exploitable: ERROR: unable to analyze dump
EMCheckCompatibility	True
Adapter Vendor ID	0x8086
Adapter Device ID	0x 126

Frame 	Module 	Signature 	Source
0 	XUL 	js::ion::IonBailoutIterator::IonBailoutIterator 	Bailouts-x64.cpp:64
1 	XUL 	js::ion::Bailout 	Bailouts.cpp:365
2 		@0x121da1ef1 	

More reports at:
https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3AIonBailoutIterator%3A%3AIonBailoutIterator%28js%3A%3Aion%3A%3AIonActivationIterator+const%26%2C+js%3A%3Aion%3A%3ABailoutStack*%29

Comment 1

[Nicolas B. Pierron [:nbp]]

(In reply to Scoobidiver from comment #0)
> It began spiking in 19.0a2/20121211 and is #3 top browser crasher over the
> last day. The regression range for the spike is:
> http://hg.mozilla.org/releases/mozilla-aurora/
> pushloghtml?fromchange=a264305757b9&tochange=c042ea08a2b4
> It might be caused by bug 791214.

I don't think so, unless MacOSX is defining MSC macros and interprets its pragmas too.
Is there a way to hook additional information to the crash report?

Comment 2

[Scoobidiver (away)]

There's another crash signature on Mac OS X: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3AOperatorIn%28JSContext*%2C+JS%3A%3AHandle%3CJS%3A%3AValue%3E%2C+JS%3A%3AHandle%3CJSObject*%3E%2C+int*%29

Comment 3

[Alex Keybl [:akeybl]]

(In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #1)
> (In reply to Scoobidiver from comment #0)
> > It began spiking in 19.0a2/20121211 and is #3 top browser crasher over the
> > last day. The regression range for the spike is:
> > http://hg.mozilla.org/releases/mozilla-aurora/
> > pushloghtml?fromchange=a264305757b9&tochange=c042ea08a2b4
> > It might be caused by bug 791214.
> 
> I don't think so, unless MacOSX is defining MSC macros and interprets its
> pragmas too.
> Is there a way to hook additional information to the crash report?

Yep - we can use the appnotes if you'd like to provide additional debug info. bsmedberg would be a good resource for how to do that.

Comment 4

[Scoobidiver (away)]

There are currently no crashes in 19.0a2/20121212.

Comment 5

[Benjamin Smedberg]

What information do you want to hook in? http://mxr.mozilla.org/mozilla-central/source/toolkit/crashreporter/nsExceptionHandler.h has the APIs:

37 // AnnotateCrashReport and AppendAppNotesToCrashReport may be called from any
38 // thread in a chrome process, but may only be called from the main thread in
39 // a content process.
40 nsresult AnnotateCrashReport(const nsACString& key, const nsACString& data);
41 nsresult AppendAppNotesToCrashReport(const nsACString& data);

appnotes are publicly visible and included in the nightly .csv files, while annotations are not, so for debugging annotations that aren't privacy-sensitive, appnotes are probably better.

Comment 6

[Robert Kaiser]

Yes, if you're adding something temporary for debugging and that can be public, use app notes. If it's something to be around permanently and have reports generated on it, then I prefer things as separate annotations, which we then can expose on Socorro crash-stats (if security-sensitive, to logged-in people only).

Comment 7

[Scoobidiver (away)]

Crashes completely stopped after 19.0a2/20121211.

Comment 8

[u279076]

Does this still need QA investigation given WORKSFORME status?

Comment 9

[Nicolas B. Pierron [:nbp]]

(In reply to Alex Keybl [:akeybl] from comment #3)
> (In reply to Nicolas B. Pierron [:pierron] [:nbp] from comment #1)
> > (In reply to Scoobidiver from comment #0)
> > > It began spiking in 19.0a2/20121211 and is #3 top browser crasher over the
> > > last day. The regression range for the spike is:
> > > http://hg.mozilla.org/releases/mozilla-aurora/
> > > pushloghtml?fromchange=a264305757b9&tochange=c042ea08a2b4
> > > It might be caused by bug 791214.
> > 
> > I don't think so, unless MacOSX is defining MSC macros and interprets its
> > pragmas too.
> > Is there a way to hook additional information to the crash report?
> 
> Yep - we can use the appnotes if you'd like to provide additional debug
> info. bsmedberg would be a good resource for how to do that.

Removed my-self from the assigned person, because:
1/ The bugs might be unnoticed for a long while when somebody assigned me to a bug because this does not appear in my workflow.
2/ I have no intend to do investigate until we find a better regression range.
3/ This bug is marked as resolved without any actions from my part.

PS: Do not assigned me bugs, they will just got less attentions as their status does not match my workflow.

Comment 10

[Scoobidiver (away)]

It still happens at a low volume in Fennec: https://crash-stats.mozilla.com/report/list?signature=js%3A%3Aion%3A%3AIonFrameIterator%3A%3Ascript%28%29+const

Comment 11

[Sylvestre Ledru [:Sylvestre]]

Closing because no crash reported since 12 weeks.