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)

defect
Not set
normal

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.
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.
Blocks: sm-profiler
Blocks: 1329181
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.
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.