Closed Bug 728705 Opened 10 years ago Closed 9 years ago
Crash @ js
_Value To Atom
It's a low volume crash but there's an increase of crashes from 13.0a1/20120216: 2012021803 12 2012021703 4 2012021603 3 2012021503 1 2012021403 1 The regression range is unclear but might be: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d45c7d7b0079&tochange=a853f4017192 Signature js_ValueToAtom(JSContext*, JS::Value const&, JSAtom**) More Reports Search UUID 39b2550d-4ef2-40fe-980c-2c3132120219 Date Processed 2012-02-19 00:47:30 Uptime 2170 Last Crash 1.9 weeks before submission Install Age 7.0 hours since version was first installed. Install Time 2012-02-18 20:50:50 Product Firefox Version 13.0a1 Build ID 20120218031156 Release Channel nightly OS Windows NT OS Version 6.1.7600 Build Architecture x86 Build Architecture Info AuthenticAMD family 15 model 79 stepping 2 Crash Reason EXCEPTION_ACCESS_VIOLATION_READ Crash Address 0x0 User Comments Was watching a livestream. App Notes AdapterVendorID: 0x10de, AdapterDeviceID: 0x0241, AdapterSubsysID: 01f41028, AdapterDriverVersion: 22.214.171.12421 D3D10 Layers? D3D10 Layers- D3D9 Layers? D3D9 Layers- EMCheckCompatibility False Total Virtual Memory 2147352576 Available Virtual Memory 1727520768 System Memory Use Percentage 57 Available Page File 1891094528 Available Physical Memory 654848000 Frame Module Signature [Expand] Source 0 mozjs.dll js_ValueToAtom js/src/jsatominlines.h:73 1 mozjs.dll js::FetchElementId js/src/jsinterpinlines.h:695 2 mozjs.dll js::mjit::stubs::GetElem js/src/methodjit/StubCalls.cpp:199 3 mozjs.dll js::mjit::stubs::SetElem<0> js/src/methodjit/StubCalls.cpp:231 More reports at: https://crash-stats.mozilla.com/report/list?signature=js_ValueToAtom%28JSContext*%2C%20JS%3A%3AValue%20const%26%2C%20JSAtom**%29
I can reproduce this in the latest Firefox 11 beta, with these steps to reproduce: - In a Google Docs document, choose "Mail Contributers" - From that 'dialog', choose 'Choose from contact persons' - Choose one of the contacts you want to add, then press 'Done' Result: crash https://crash-stats.mozilla.com/report/index/bp-3a87bad9-8d22-473f-8eeb-127532120312
Ok, it turns out you need to have the about:config preference browser.link.open_newwindow.restriction set to 0, to trigger this crash.
The spike in 13 is gone. There are only 164 crashes across all versions over the last week.
Confirmed STR in Beta 11. It doesn't crash in 13, though. Need to check 12 too.
This is the changeset that fixed the problem: changeset: 83501:0d684c34d1e4 user: Olli Pettay <Olli.Pettay@helsinki.fi> date: Fri Dec 30 12:47:23 2011 +0200 summary: Bug 714162 - Don't traverse certainly alive selections, r=mccr8 I'm not sure it actually fixed the bug--given the title it might just be reducing the amount of CC traversals and thus giving fewer opportunities to crash. I'll look for the regressor next.
The bug appears to have been introduced here: changeset: 79966:366d80e91816 user: Chris Leary <email@example.com> date: Mon Nov 07 13:42:31 2011 -0800 summary: Bug 634654 - Add RegExpPrivate cache. (r=Waldo) I say "appears" because it repros in a different way for me: Firefox doesn't crash, it just exits. But it works fine on a build from the previous rev.
(In reply to David Mandelin from comment #5) > This is the changeset that fixed the problem: > > changeset: 83501:0d684c34d1e4 > user: Olli Pettay <Olli.Pettay@helsinki.fi> > date: Fri Dec 30 12:47:23 2011 +0200 > summary: Bug 714162 - Don't traverse certainly alive selections, r=mccr8 > > I'm not sure it actually fixed the bug--given the title it might just be > reducing the amount of CC traversals and thus giving fewer opportunities to > crash. I'll look for the regressor next. I would be very surprised if that bug really fixed this one.
Spinning off the reproducible crash as bug 735917, so this can be reserved for the topcrash.
There have been no crashes for the last four weeks after 15.0.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.