User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120301 Firefox/13.0a1 Build ID: 20120301082139 Steps to reproduce: I went to speed-battle.com and ran the benchmark. Actual results: https://crash-stats.mozilla.com/report/index/41052e5e-deb3-4cc4-8efd-cad152120301 Expected results: Firefox should have remained stable.
Hardware: x86 → x86_64
not crash http://hg.mozilla.org/mozilla-central/rev/1c3b291d0830 Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:13.0) Gecko/20120301 Firefox/13.0a1 ID:20120301031135
I should say, it's repeated loading and not always reproducible. It had been happening with my own builds for quite some time, but, I finally got around to testing it on a hourly. Firefox will either just close down with no error or give a vague windows appcrash.
http://crash-stats.mozilla.com/report/index/bp-7a30e70f-2e48-4701-b1a0-d2ab12120301 http://crash-stats.mozilla.com/report/index/bp-c81670a4-8777-4080-9f2a-d29432120301 http://crash-stats.mozilla.com/report/index/bp-bddb692e-59bc-468e-bc9c-19e5c2120301 on http://hg.mozilla.org/mozilla-central/rev/3a7b9e61c263 So, on current m-c tip, it's fairly reproducible. I'm not sure about http://hg.mozilla.org/mozilla-central/rev/1c3b291d0830 being the culprit as it was happening before then.
After disabling IGP, I still got the following crashes: http://crash-stats.mozilla.com/report/index/bp-62cde9e2-4a3c-4bd5-9c11-d4abf2120301 http://crash-stats.mozilla.com/report/index/bp-5de47b11-5206-414d-a39e-5ca532120301 http://crash-stats.mozilla.com/report/index/bp-c010a0be-c4f2-4dd8-ab11-5f3ae2120301 http://crash-stats.mozilla.com/report/index/bp-2c5301e0-d568-457c-b977-3584d2120301 I'm sorry if this is considered spam.
I don't crash. Does it happen in Safe Mode (see https://support.mozilla.org/en-US/kb/Safe%20Mode)? Does it happen with a new profile (see https://support.mozilla.org/en-US/kb/Managing-profiles)? Can you provide a valid stacktrace (see https://developer.mozilla.org/en/How_to_get_a_stacktrace_with_WinDbg)?
Reporter, can you go to about:support in your address bar, and copy the information from there into the bug report (even as a plain text attachment will help). Also, please update your graphics card driver as well.
Crash Signature: [@ xul.dll@0xd767b5 | xul.dll@0xd76a4a | xul.dll@0xca2faf | xul.dll@0xca32af | xul.dll@0xca346e | xul.dll@0xca351d | xul.dll@0xc78520 | xul.dll@0x6e869f | xul.dll@0x10f5cf7 | nspr4.dll@0x854c ]
I've uploaded my about:support page. So far, testing in safe mode, there are no crashes. I will try with a new profile and WinDbg and report back.
There is a newer graphics card driver available, so you may want to download that from Nvidia's website. It could also be one of your addons as well, so if a fresh profile works, please try disabling your addons, then re-enable them one at a time until your find the culprit.
The graphics driver is the newest. You may be looking at the date on the Intel driver instead. WinDbg proved to be an exercise in frustration as when working with 20120301 nightly, I couldn't get it to crash at all - even with my old profile. It may have been some strange Heisenberg effect. The only thing that remains is tracking down the offending extension.
Created attachment 602247 [details] WinDbg log I don't know if it's much help, but, here's a WinDbg log created from my own build.
(In reply to Mike Pesce (:By-Tor) from comment #8) > So far, testing in safe mode, there are no crashes. It's probably caused by one of your extensions as your graphics driver is up-to-date. Please try to find it by disabling all your extensions except one.
AFAICT it seems to be the Navigational Sounds addon: http://james-ross.co.uk/mozilla/extensions/navsounds/ I'll have to see what happens with the debug version.
I retract my last comment. While I did get a long run with Navigational Sounds disabled. Once I enabled, Element Hider from ABP, there were almost instantaneous crashes. (You know ABP had to come into it somehow. :-)) (Navigational Sounds were disabled during the test).
Severity: normal → critical
Status: UNCONFIRMED → NEW
Crash Signature: [@ xul.dll@0xd767b5 | xul.dll@0xd76a4a | xul.dll@0xca2faf | xul.dll@0xca32af | xul.dll@0xca346e | xul.dll@0xca351d | xul.dll@0xc78520 | xul.dll@0x6e869f | xul.dll@0x10f5cf7 | nspr4.dll@0x854c ] → [@ js_GetScriptLineExtent(JSScript*)]
Component: Untriaged → Extension Compatibility
Ever confirmed: true
QA Contact: untriaged → extension.compatibility
Hardware: x86_64 → x86
Summary: Reloading http://speed-battle.com results in a crash → Reloading http://speed-battle.com results in a crash with Element Hiding Helper for Adblock Plus
Scoobidiver, seeing that you confirmed the bug I guess that you were able to reproduce it? I couldn't with Adblock Plus 2.0.4a.3414 and Element Hiding Helper 1.2.2a.407 (same as in the crash reports) in Gecko/20120304 Firefox/13.0a1 on Windows 7 x64. Generally, Element Hiding Helper is extremely unlikely to cause anything like that - as long as you don't activate it it will only listen for keypress/popupshowing/popuphidden events.
(In reply to Wladimir Palant from comment #15) > Scoobidiver, seeing that you confirmed the bug I guess that you were able to > reproduce it? I haven't marked it as reproducible.
Summary: Reloading http://speed-battle.com results in a crash with Element Hiding Helper for Adblock Plus → Reloading http://speed-battle.com results in a crash with Adblock Plus
Further combinations of extensions and over 500 tests on the site have shown that it is indeed ABP itself. It is definitely reproducible on my end. I would part of the STR are, reload the page in quick succession about 20 times.
Crash Signature: [@ js_GetScriptLineExtent(JSScript*)] → [@ js_GetScriptLineExtent(JSScript*)] [@ js_GetScriptLineExtent]
With WebExtensions being the only valid way of doing extensions in Firefox 57, I don't think this bug is still relevant.
Status: NEW → RESOLVED
Last Resolved: 9 months ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.