1) Clone Firebug repo: git@github.com:firebug/firebug.git and switch to jsd2 branch. https://github.com/firebug/firebug/tree/jsd2 2) Install Firebug from the source 3) Select and enable the Console panel 4) Load http://softwareishard.com/har/viewer/ 4) Press Profile button in Firebug's Console panel 5) Just move mouse over the page content area 6) The browser crashes --- #0 0x0000003ee52bb44d in nanosleep () from /lib64/libc.so.6 #1 0x0000003ee52bb2f1 in sleep () from /lib64/libc.so.6 #2 0x00007f2856f4f47c in ah_crap_handler (signum=11) at /home/jimb/moz/dbg/toolkit/xre/nsSigHandlers.cpp:88 #3 0x00007f2856f5ac94 in nsProfileLock::FatalSignalHandler (signo=11, info=0x7fff408971b0, context=0x7fff40897080) at /home/jimb/moz/dbg/obj-bug/toolkit/profile/nsProfileLock.cpp:190 #4 <signal handler called> #5 0x00007f2859be44f2 in js::gc::Cell::chunk (this=0x5a5a5a5a5a5a5a5a) at /home/jimb/moz/dbg/js/src/gc/Heap.h:1032 #6 0x00007f2859be4372 in js::gc::Cell::runtime (this=0x5a5a5a5a5a5a5a5a) at /home/jimb/moz/dbg/js/src/gc/Heap.h:960 #7 0x00007f2859c10623 in js::RelocatablePtr<JSObject>::~RelocatablePtr (this=0x7f283006df20, __in_chrg=<optimized out>) at /home/jimb/moz/dbg/js/src/gc/Barrier.h:264 #8 0x00007f2859c0b06c in js::HashMapEntry<js::AbstractFramePtr, js::RelocatablePtr<JSObject> >::~HashMapEntry (this=0x7f283006df18, __in_chrg=<optimized out>) at ./../../dist/include/js/HashTable.h:568 #9 0x00007f2859c17d10 in js::detail::HashTableEntry<js::HashMapEntry<js::AbstractFramePtr, js::RelocatablePtr<JSObject> > >::clearLive (this=0x7f283006df10) at ./../../dist/include/js/HashTable.h:657 #10 0x00007f2859c12d13 in js::detail::HashTable<js::HashMapEntry<js::AbstractFramePtr, js::RelocatablePtr<JSObject> >, js::HashMap<js::AbstractFramePtr, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::AbstractFramePtr>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::remove (this=0x7f283005b8a0, e=...) at ./../../dist/include/js/HashTable.h:1215 #11 0x00007f2859c0fba0 in js::detail::HashTable<js::HashMapEntry<js::AbstractFramePtr, js::RelocatablePtr<JSObject> >, js::HashMap<js::AbstractFramePtr, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::AbstractFramePtr>, js::RuntimeAllocPolicy>::MapHashPolicy, js::RuntimeAllocPolicy>::remove (this=0x7f283005b8a0, p=...) at ./../../dist/include/js/HashTable.h:1457 #12 0x00007f2859c0a9db in js::HashMap<js::AbstractFramePtr, js::RelocatablePtr<JSObject>, js::DefaultHasher<js::AbstractFramePtr>, js::RuntimeAllocPolicy>::remove (this=0x7f283005b8a0, p=...) at ./../../dist/include/js/HashTable.h:102 #13 0x00007f2859bec809 in js::Debugger::FrameRange::removeFrontFrame (this=0x7fff40897640) at /home/jimb/moz/dbg/js/src/vm/Debugger.cpp:207 #14 0x00007f2859bfb80f in js::Debugger::handleBaselineOsr (cx=0x7f283c8330c0, from=0x7f284cffe3a8, to=0x7fff40897b48) at /home/jimb/moz/dbg/js/src/vm/Debugger.cpp:3410 #15 0x00007f2859f3c154 in js::ion::BaselineFrame::initForOsr (this=0x7fff40897b48, fp=0x7f284cffe3a8, numStackValues=1) at /home/jimb/moz/dbg/js/src/ion/BaselineFrame.cpp:161 #16 0x00007f285a0ca031 in js::ion::InitBaselineFrameForOsr (frame=0x7fff40897b48, interpFrame=0x7f284cffe3a8, numStackValues=1) at /home/jimb/moz/dbg/js/src/ion/VMFunctions.cpp:821 #17 0x00007f284f5583e7 in ?? () #18 0x00007fff40897b20 in ?? () #19 0x00007fff40897b10 in ?? () #20 0x00007f2848a29f13 in ?? () #21 0x00007fff40897b48 in ?? () #22 0x0000000000000000 in ?? () (gdb)

jandem tells me js::ion::InitBaselineFrameForOsr is how SpiderMonkey enters BC code from the interpreter, and adds, "the stack frames below InitBaselineForOsr look bogus". jandem also observes: "wild guess, but maybe the problem is that in Debugger::handleBaselineOsr the r.removeFrontFrame call is invalid after the putNew reallocates or something". Given that the comments for FrameRange read: * We keep an index into the compartment's debugger list, and a * FrameMap::Ptr into the current debugger's frame map. Thus, if the set of * debuggers in |fp|'s compartment changes, this range becomes invalid. * Similarly, if stack frames are added to or removed from frontDebugger(), * then the range's front is invalid until popFront is called. and that handleBaselineOsr is indeed calling dbg->frames.putNew followed by r.removeFrontFrame, which uses a FrameMap::Ptr value created before the putNew, it does seem possible that that's the problem.

Fix for the issue in comment 1. I didn't try to reproduce the crash, but I'm pretty sure this will fix it. If not, there's another bug here, but it seems unlikely.

Comment on attachment 761335 [details] [diff] [review] Patch Review of attachment 761335 [details] [diff] [review]: ----------------------------------------------------------------- Lovely. How could I refuse so simple a fix?

Comment on attachment 761335 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): Baseline Compiler (Firefox 23) User impact if declined: Crashes when using the debugger. Testing completed (on m-c, etc.): On m-i. Risk to taking this patch (and alternatives if risky): Very low. String or IDL/UUID changes made by this patch: None.

Works for me now, thanks! Honza

(In reply to Jan Honza Odvarko from comment #9) > Works for me now, thanks! Honza, which version of Firefox did you verify this with? Can you make sure Firefox 23 and 24 are fixed for you?

(In reply to Anthony Hughes, Mozilla QA (:ashughes) from comment #10) > (In reply to Jan Honza Odvarko from comment #9) > Honza, which version of Firefox did you verify this with? Can you make sure > Firefox 23 and 24 are fixed for you? I have been testing on Nightly (it was 24 at that time). I tried to retest, but I am blocked by a crash described in Bug 885388 Honza

I tried to reproduce the initial crash by following the STR from Comment 0 in a 2013-06-10 Nightly, but Firefox does not crash for me. All I get is a hang (I don't see the same hang on Firefox 23 beta 8). Honza, any thoughts? Could you please give any suggestions that will help me reproduce the initial issue?