Closed
Bug 1322468
Opened 9 years ago
Closed 9 years ago
Assertion when attempting to profile DOM worker threads: js::CurrentThreadCanAccessRuntime(asRuntime()) || js::CurrentThreadIsPerformingGC(),
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
DUPLICATE
of bug 1345262
| Tracking | Status | |
|---|---|---|
| firefox53 | --- | affected |
People
(Reporter: mstange, Unassigned)
References
(Blocks 2 open bugs)
Details
STR:
1. Run a debug build, probably needs --enable-profiling as well.
2. Execute the following in the error console (requires devtools.chrome.enabled = true):
> Components.classes["@mozilla.org/tools/profiler;1"].getService(Components.interfaces.nsIProfiler).StartProfiler(10000000, 1, ["js", "stackwalk", "threads"], 3, ["Worker"], 1);
You'll get this assertion:
> Assertion failure: js::CurrentThreadCanAccessRuntime(asRuntime()) || js::CurrentThreadIsPerformingGC(), at /Users/mstange/code/obj-m-debug/dist/include/jspubtd.h:178
> #01: JS::shadow::Runtime::heapState() const[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0xd300c]
> #02: JS::shadow::Runtime::isHeapBusy() const[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7ab0625]
> #03: js::gc::ZoneCellIter<js::gc::TenuredCell>::initForTenuredIteration(JS::Zone*, js::gc::AllocKind)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7763894]
> #04: js::gc::ZoneCellIter<js::gc::TenuredCell>::init(JS::Zone*, js::gc::AllocKind)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x776379c]
> #05: js::gc::ZoneCellIter<JSScript>::ZoneCellIter(JS::Zone*)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7787f2d]
> #06: js::gc::ZoneCellIter<JSScript>::ZoneCellIter(JS::Zone*)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7787edd]
> #07: js::gc::ZoneCellIter<JSScript> JS::Zone::cellIter<JSScript>()[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x774374c]
> #08: JS::Zone::discardJitCode(js::FreeOp*, bool)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7f2abfd]
> #09: js::ReleaseAllJITCode(js::FreeOp*)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x77c0c48]
> #10: js::SPSProfiler::enable(bool)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7b2d7b8]
> #11: js::EnableContextProfilingStack(JSContext*, bool)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x7b30d03]
> #12: PseudoStack::enableJSSampling()[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x2435f7]
> #13: mozilla_sampler_start(int, double, char const**, unsigned int, char const**, unsigned int)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x58ca6f4]
> #14: profiler_start(int, double, char const**, unsigned int, char const**, unsigned int)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x58e0ebb]
> #15: nsProfiler::StartProfiler(unsigned int, double, char const**, unsigned int, char const**, unsigned int)[/Users/mstange/code/obj-m-debug/dist/NightlyDebug.app/Contents/MacOS/XUL +0x58e0e69]
In release builds it usually doesn't crash right away; sometimes it only happens the second time you try to start the profiler with this thread filter, sometimes it only crashes once you collect the profile, sometimes it only crashes the content process and sometimes it crashes the parent process.
There might be multiple issues here.
Comment 1•9 years ago
|
||
I added this assertion in bug 1313098. It seems that js::EnableContextProfilingStack can get called on threads other than the thread running JS for that context/runtime (e.g. here for worker threads this gets called on the gecko main thread IIUC). This is totally racy! We need to find another way of doing this.
| Reporter | ||
Updated•9 years ago
|
Blocks: sm-profiler
Comment 2•9 years ago
|
||
Bug 1340193 comment 5 is very similar -- we call EnableContextProfilingStack() on lots of threads from the main thread, and we get assertion failures, though in a different place.
Comment 3•9 years ago
|
||
This is a slightly different manifestation of the basic problem covered by bug 1345262.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•