This bug was filed from the Socorro interface and is report bp-797b0869-7da2-4071-b8ea-a51312140616. ============================================================= Nightly 33 from June 12th crashes on startup every time. It looks to be related to the Gecko Profiler being turned on.
Do you know if someone can look into this? AFAIK I'm calling this from the main thread to the main thread context and I'm calling it after the JS engine has been initialized so this shouldn't crash.
I'm getting this crash too. The profiler appears to be using a JSRuntime associated with a DOM worker, instead of the main thread JSRuntime.
Getting it on MacOS too.
OS: Windows NT → All
I am not going to be able to look in to this. There's simply too much juggling going on. I can prioritize this above other profiler bugs if I need to... How high-pri is this? Is it happening all the time?
(In reply to Kannan Vijayan [:djvj] from comment #4) > How high-pri is this? Is it happening all the time? You simply can't start if profiler is enabled.
The problem is DOM workers register their JS runtimes with the profiler. When enabling the profiler, the profiler tries to release JIT code associated with these runtimes on the main thread . However, AFAICT this is not thread safe because it involves a GC step, and the thread check at  fails. I have no idea how to fix this or if it's even fixable.  http://mxr.mozilla.org/mozilla-central/source/js/src/vm/SPSProfiler.cpp#85  http://mxr.mozilla.org/mozilla-central/source/js/src/gc/Nursery.cpp#743
This bug still exists, as soon as you have a thread filter that includes DOM worker threads. Steps to reproduce: 1. Create a new Firefox profile and launch Firefox. 2. Go to about:config and open the Web Console, e.g. using Cmd+Opt+K. 3. Execute this: Components.classes["@mozilla.org/tools/profiler;1"].getService(Components.interfaces.nsIProfiler) .StartProfiler(1000, 1, ["js", "threads"], 2, [""], 1); I'd like to be able to profile web workers again. Kannan, do you think you could take this on at some point?
Ok, I have some time now. Looking at this.
Created attachment 8565758 [details] [diff] [review] patch This fixes the crash but I'm seeing it when dumping the profile. I think it might be because we access the JSRuntime when dumping the profile and we might do it from the wrong thread. Need to confirm with the debugger.
Assignee: nobody → bgirard
Status: NEW → ASSIGNED
Crash Signature: [@ JS_AbortIfWrongThread(JSRuntime*)] → [@ JS_AbortIfWrongThread(JSRuntime*)] [@ JS_AbortIfWrongThread]
Crash volume for signature 'JS_AbortIfWrongThread': - nightly(version 50):0 crashes from 2016-06-06. - aurora (version 49):0 crashes from 2016-06-07. - beta (version 48):21 crashes from 2016-06-06. - release(version 47):47 crashes from 2016-05-31. - esr (version 45):4 crashes from 2016-04-07. Crash volume on the last weeks: W. N-1 W. N-2 W. N-3 W. N-4 W. N-5 W. N-6 W. N-7 - nightly 0 0 0 0 0 0 0 - aurora 0 0 0 0 0 0 0 - beta 3 0 1 7 1 1 8 - release 7 10 5 6 7 9 1 - esr 0 0 0 0 0 0 2 Affected platforms: Windows, Mac OS X, Linux
status-firefox47: --- → affected
status-firefox48: --- → affected
status-firefox-esr45: --- → affected
You need to log in before you can comment on or make changes to this bug.