User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:25.0) Gecko/20100101 Firefox/25.0 (Beta/Release) Build ID: 20131112160018 Steps to reproduce: Open the debugger Actual results: Crash
Version: 25 Branch → 29 Branch
Additional STR info: It appears that DevTools is trying to remember the state of the Events panel. If on a previous browser session the debugger has been open and viewing the Events panel, this crash is 100% repeatable (here, anyway). The workaround (for me, anyway) is to open the browser to the default home page and immediately open the debugger, close it then close the browser. Next session will allow me to open the debugger (on my app URL) without a crash. Whether this is related, I'm not sure: *sometimes* on opening the Events panel, the debugger pauses as though it is hitting a breakpoint.
I'm not able to reproduce the crash by opening the debugger in Nightly. Did you test with a clean profile? https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles
No extensions, all plugins disabled... https://crash-stats.mozilla.com/report/index/3bd3b8a3-1ef0-4676-9b50-f51de2131227
Try to provide some more specific steps to reproduce. Everything is fine to me if I open the debugger, close Firefox with the debugger running, then restart Firefox, open again the debugger.
In Comment 4 I specifically mentioned : "...the debugger has been open and viewing the Events panel."
Still no crash, 29.0a1 (2014-01-08), win 7 x64
I believe you, Paul. However, this is not a trivial test case, it's a pretty big web app (ASP.NET) with around 30 - 50 or so js files. There are also 3 iframes on the outer page (the "new" events panel is certainly having some difficulties with embedded docs under some circumstances). What would you like me to do?
Would about:config devtools.debugger.log help? What specific steps would you like me to follow?
This is hopefully something that our SpiderMonkey hackers can figure out. I don't think I've ever seen this before. Top of the stack: 0 mozjs.dll js::SN_IS_TERMINATOR(unsigned char *) js/src/frontend/SourceNotes.h 1 mozjs.dll js_GetScriptLineExtent(JSScript *) js/src/jsscript.cpp 2 mozjs.dll DebuggerScript_getLineCount js/src/vm/Debugger.cpp 3 mozjs.dll js::Invoke(JSContext *,JS::Value const &,JS::Value const &,unsigned int,JS::Value *,JS::MutableHandle<JS::Value>) js/src/vm/Interpreter.cpp 4 mozjs.dll GetPropertyOperation js/src/vm/Interpreter.cpp 5 mozjs.dll Interpret js/src/vm/Interpreter.cpp 6 mozjs.dll js::RunScript(JSContext *,js::RunState &) js/src/vm/Interpreter.cpp 7 mozjs.dll js::Invoke(JSContext *,JS::CallArgs,js::MaybeConstruct) js/src/vm/Interpreter.cpp Russ, since it's very easy for you to reproduce the crash, one thing you could do is to use a debug build and see if you get more useful output from it. The latest one I can see right now on mozilla-central is here: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-win32-debug/1389212983/ If you could use that to get a new crash, then the crash data should be more informative. Also, if you start this debug build from a command terminal you may get an assertion printed there, which should be immensely helpful.
Crash Signature: [@ js::SN_IS_TERMINATOR(unsigned char*)]
Product: Firefox → Core
Hmm... not the outcome we were looking for... Running the win32 zip linked above via >firefox.exe -no-remote -p "test-prof" does not close down completely on a normal exit from FF (terminal required Ctrl-C to get back to the prompt). Continuing, and proceeding to the known crash point FF certainly crashed but the Windows "Firefox has stopped working" dialog appeared; the moz crash reporter was nowhere to be found. Again, the console needed a Ctrl-C to get the prompt back. Last two lines in the console were:  WARNING: NS_ENSURE_TRUE(enabled) failed: file c:/builds/moz2_slave/m-cen-w32-d-000000000000000000/build/dom/bas e/Navigator.cpp, line 1869  WARNING: NS_ENSURE_TRUE(enabled) failed: file c:/builds/moz2_slave/m-cen-w32-d-000000000000000000/build/dom/bas e/Navigator.cpp, line 1710 I'm guessing the crash reporter needs to be in play for us to progress, right?
Hmm, I'm not sure what you need to do to get the stack trace from a crash on Windows, so I'll let the experts chime in. Thanks for testing!
If I start the above FF directly (double-click) it brings up its own console (which of course would not survive a crash). Regardles, having run this debug version over and over, I cannot repro the crash at all. If I switch to my regular Nightly, it's 100% repeatable as described (as is beta and Aurora). Things I should mention: 1 - I find trying to repro the exact steps in a debug (read: slow) version of firefox is difficult. It would be easy to introduce (or fail to see) problems by being "too quick". I don't know what to do about this. 2 - My Nightly has a clean profile; what few addons are present are set to "Never Activate".
Panos, I could be way off here but looking again at that stack you pasted in comment 12 anyone would be forgiven for thinking the debugger was preparing for a breakpoint. I mention this because, as I mentioned in comment 4, "...*sometimes* on opening the Events panel, the debugger pauses as though it is hitting a breakpoint". The exact steps aren't easy to pin down, but it's quite frequent here.
Created attachment 8357848 [details] CRASH-dbg.log I went ahead and created two logs via about:config, devtools.debugger.log:true Recall that the STR require two FF sessions, one immediately following the other. REFERENCE-dbg.log represents the entire first session (FF open, navigate to URL, debugger open, events panel open, close FF) CRASH-dbg.log epresents the second session up to the point where the crash occurs (FF open, navigate to URL, debugger open, crash) There are obvious differences in these two logs, even to my untrained eyes: 1 - in CRASH-dbg.log there are no DBG-FRONTEND messages 2 - CRASH-dbg.log stops when having received Packet 5 (or after having emitted packet 6 depending on how you view the threading possibilities, I guess). Test conditions: FF29, Win7/64
Attachment #8357848 - Flags: feedback+
Russ, in comment 13 it sounds like you were able to get a crash (just not the crash reporter), but comment 15 sounds like you're not seeing a crash at all. Can you clarify whether you crash with the debug build? By the way, on debug builds you'll need to set MOZ_CRASHREPORTER=1 to use the crash reporter, otherwise it'll use the default Windows handler.
David... Yes, that's ambiguous - apols. re 13: That was me trying to use the debug build to replicate the STR exactly. That was difficult to do but I did manage to hit the crash point (but no crash reporter - you're advice re that is noted). re 15: that was me basically messing about, not helpful really. I tried to just run the debug firefox WITHOUT the console/command prompt. I thought it worth pointing out that I failed to make it crash at all while doing this. Again, I don't think this is helpful info. Later (maybe tomorrow) I'll rerun with the corrected environment var as suggested. David, I have a small animated gif of the crash if you want to see my steps.
No crash using my steps and the build unzipped from the archive provided in comment 12. Retested latest nightly, aurora and beta, same steps, 100% crash rate. So, back to the debug build and test, test, test... finally, I got this (unrelated, I think) https://crash-stats.mozilla.com/report/index/58d1c5b1-f8ee-4ad8-8403-024f22140111 Last few lines in console were:  WARNING: not an nsIRDFRemoteDataSource: 'remote != nullptr', file c:/builds/moz2_slave/m-cen-w32-d-000000000000 000000/build/rdf/datasource/src/nsLocalStore.cpp, line 279  WARNING: not an nsIRDFRemoteDataSource: 'remote != nullptr', file c:/builds/moz2_slave/m-cen-w32-d-000000000000 000000/build/rdf/datasource/src/nsLocalStore.cpp, line 279  WARNING: not an nsIRDFRemoteDataSource: 'remote != nullptr', file c:/builds/moz2_slave/m-cen-w32-d-000000000000 000000/build/rdf/datasource/src/nsLocalStore.cpp, line 279  WARNING: '!compMgr', file c:/builds/moz2_slave/m-cen-w32-d-000000000000000000/build/xpcom/glue/nsComponentManag erUtils.cpp, line 59  WARNING: OOPDeinit() without successful OOPInit(): file c:/builds/moz2_slave/m-cen-w32-d-000000000000000000/bui ld/toolkit/crashreporter/nsExceptionHandler.cpp, line 2336
Yikes, we don't keep symbols for these debug builds, but your crash was an assert so I was able to dig the text out of the binary. It was "mPendingEventCount (Mismatched calls to observer methods!)" at LazyIdleThread.cpp:512. I don't know enough about this code to say whether it's related. But the good news is that I was able to reproduce the crash on an optimized build using your steps in comment 4 and cnn.com as my test site. I've saved a full heap dump in case I stop being able to repro.
I think this is a dup of bug 958980. Since that bug has a patch, I'll dup this one to it. Please reopen if it's not a dup.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 958980
@Nick/David: Just to confirm that my STR are no longer repeatable against FF 29.0a1 (2014-01-22) as published at bug 958980 comment 27.
You need to log in before you can comment on or make changes to this bug.