Closed Bug 820805 Opened 9 years ago Closed 3 years ago

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

Categories

(Core :: JavaScript Engine, defect)

19 Branch
ARM
Android
defect
Not set
critical

Tracking

()

RESOLVED WONTFIX
Tracking Status
firefox19 --- affected
firefox22 --- affected

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash, regression, Whiteboard: [native-crash])

Crash Data

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
(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?
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
Crash Signature: [@ js::ion::IonBailoutIterator::IonBailoutIterator(js::ion::IonActivationIterator const&, js::ion::BailoutStack*)] → [@ js::ion::IonBailoutIterator::IonBailoutIterator(js::ion::IonActivationIterator const&, js::ion::BailoutStack*)] [@ js::ion::OperatorIn(JSContext*, JS::Handle<JS::Value>, JS::Handle<JSObject*>, int*)]
Summary: crash in js::ion::IonBailoutIterator::IonBailoutIterator → crash in js::ion::IonBailoutIterator::IonBailoutIterator or js::ion::OperatorIn
(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.
Assignee: general → nicolas.b.pierron
There are currently no crashes in 19.0a2/20121212.
Crash Signature: [@ js::ion::IonBailoutIterator::IonBailoutIterator(js::ion::IonActivationIterator const&, js::ion::BailoutStack*)] [@ js::ion::OperatorIn(JSContext*, JS::Handle<JS::Value>, JS::Handle<JSObject*>, int*)] → [@ js::ion::IonBailoutIterator::IonBailoutIterator(js::ion::IonActivationIterator const&, js::ion::BailoutStack*)] [@ js::ion::OperatorIn(JSContext*, JS::Handle<JS::Value>, JS::Handle<JSObject*>, int*)] [@ js::ion::GetElementCache(JSContext* unsigned lo…
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.
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).
QA Contact: mozillamarcia.knous
Crashes completely stopped after 19.0a2/20121211.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
Crash Signature: js::CallArgsList&)] [@ js::ion::SnapshotIterator::SnapshotIterator(js::ion::IonFrameIterator const&)] [@ js::ion::SetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, bool, bool)] → js::CallArgsList&)] [@ js::ion::SnapshotIterator::SnapshotIterator(js::ion::IonFrameIterator const&)] [@ js::ion::SetProperty(JSContext*, JS::Handle<JSObject*>, JS::Handle<js::PropertyName*>, JS::Handle<JS::Value>, bool bool)] [@ StringRegExpGuard::ini…
Does this still need QA investigation given WORKSFORME status?
(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.
Assignee: nicolas.b.pierron → general
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
Status: RESOLVED → REOPENED
Keywords: topcrash
OS: Mac OS X → Android
Hardware: x86_64 → ARM
Resolution: WORKSFORME → ---
Whiteboard: [native-crash]
Depends on: 860435
Assignee: general → nobody
Crash Signature: , bool)] [@ StringRegExpGuard::init(JSContext*, JS::CallArgs, bool)] → , bool)] [@ StringRegExpGuard::init(JSContext*, JS::CallArgs, bool)] [@ js::ion::IonBailoutIterator::IonBailoutIterator] [@ js::ion::OperatorIn] [@ js::ion::GetElementCache] [@ js::ion::IonFrameIterator::script const] [@ js::ion::IonFrameIterator::s…
Closing because no crash reported since 12 weeks.
Status: REOPENED → RESOLVED
Closed: 9 years ago3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.