Closed
Bug 820805
Opened 10 years ago
Closed 4 years ago
crash in js::ion::IonBailoutIterator::IonBailoutIterator or js::ion::OperatorIn
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
WONTFIX
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
Comment 1•10 years ago
|
||
(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?
Reporter | ||
Comment 2•10 years ago
|
||
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
Comment 3•10 years ago
|
||
(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
Reporter | ||
Comment 4•10 years ago
|
||
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…
Comment 5•10 years ago
|
||
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•10 years ago
|
||
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).
Updated•10 years ago
|
QA Contact: mozillamarcia.knous
Updated•10 years ago
|
Keywords: qawanted,
steps-wanted
Reporter | ||
Comment 7•10 years ago
|
||
Crashes completely stopped after 19.0a2/20121211.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Updated•10 years ago
|
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…
Reporter | ||
Updated•10 years ago
|
Keywords: qawanted,
steps-wanted
Comment 9•10 years ago
|
||
(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
Reporter | ||
Comment 10•10 years ago
|
||
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
status-firefox20:
unaffected → ---
status-firefox22:
--- → affected
Keywords: topcrash
OS: Mac OS X → Android
Hardware: x86_64 → ARM
Resolution: WORKSFORME → ---
Whiteboard: [native-crash]
Reporter | ||
Updated•10 years ago
|
tracking-firefox19:
? → ---
Assignee | ||
Updated•9 years ago
|
Assignee: general → nobody
Updated•7 years ago
|
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…
Comment 11•4 years ago
|
||
Closing because no crash reported since 12 weeks.
Status: REOPENED → RESOLVED
Closed: 10 years ago → 4 years ago
Resolution: --- → WONTFIX
You need to log in
before you can comment on or make changes to this bug.
Description
•