User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_10_4) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/44.0.2403.130 Safari/537.36 Steps to reproduce: 1. Open http://digitalfeed.net/firefox_issue_2.html in Firefox 2. Right-click in IFrame and select Inspect Element 3. Choose the 'Debugger' tab in dev tools 4. Select 'firefox_issue_2.js' in Debugger 5. Press 'Stop blackboxing this source' 6. Press the pretty-print button 7. Set a breakpoint (must be somewhere that will actually be called, which is everywhere except the first function) 8. Refresh the broswer (which runs the code) 9. Wait for your browser to crash This only appears to affect: 1. Minified code 2. Code that is executed when the page is loading: if you put a breakpoint in the function called by the button click (creatively called firedOnButtonClick) then click the button, it will not cause a crash. However, *it will not stop at the breakpoint either* Actual results: The browser crashed Expected results: Execution should have stopped at the breakpoint
Also occurs on: Win7, FF39 Win7, FF40 Win7, FF41 Doesn't occur if: Breakpoint is set on the single minified line without pressing pretty-print (although it doesn't break at that breakpoint either...) Seems to be specific to pretty-printed source code.
On my side, the browser doesn't crash but hangs so I need to kill it. But I tested with Nightly and I'm not able to reproduce the hang. Could you test with FF42, please. https://nightly.mozilla.org/
Sorry, you're right: the browser hangs rather than crashes. I was able to reproduce it in Nightly, but only inconsistently (it didn't hang a much greater proportion of times than it did hang). It may be unrelated, but every time I was able to reproduce it, the list of scripts on the left in the debugger only displayed the jquery script, not the firefox_issue_2.min.js. The exact steps I followed: 1. Open the browser 2. Enter the URL 3. Right-click on the IFrame, select Inspect Element 4. When the dev tools load, select the 'Debugger' tab 5. Click 'Stop black boxing this source' 6. Click the pretty print icon 7. Click to the left of the 'var a;' line to add a breakpoint 8. Use the browser refresh button in the URL bar If it didn't hang the first time I refreshed, it would never hang across many refreshes (I think). If it didn't hang, I closed the browser window and dev tools, then selected 'File/New Tab', entered the URL, and tried again. Sometimes I would hang the second time. Rinse, repeat, enough cycles and it would always eventually hang. (Usually took 3-4 attempts) That is Nightly on OSX.
Yes, it hangs sometimes, maybe related to GC. But it's less frequent in Nightly.
Interesting, Instruments says we are spending 99% of our time in js::HashTable > Running Time Self (ms) Symbol Name > 25951.0ms 98.6% 0.0 js::detail::HashTable<js::AtomStateEntry const, js::HashSet<js::AtomStateEntry, js::AtomHasher, js::SystemAllocPolicy>::SetOps, js::SystemAllocPolicy>::readonlyThreadsafeLookup const 0x2d64a1
Which seems to be this use: https://dxr.mozilla.org/mozilla-central/rev/22476236b3e1173e03078dc076258f36e67f7040/js/src/vm/Runtime.h#1262 Wonder if that is just Instruments not seeing JS code, although I can't use our builtin profiler while Firefox is beachballed.
At the risk of introducing noise: could it be related to https://bugzilla.mozilla.org/show_bug.cgi?id=1191195 In this issue, the browser hangs but I think it may only be the case if the outer window has no scripts. If the outer window has a script, that other issue occurs (i.e. the debugger stops in the outer window code) If the outer window doesn't have scripts the browser hangs. (That was my experience anyway).