Closed
Bug 1344315
Opened 8 years ago
Closed 8 years ago
Assertion failure: CurrentThreadCanAccessRuntime(cx->runtime()), at js/src/threading/ProtectedData.cpp:47 with evalInCooperativeThread
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla55
| Tracking | Status | |
|---|---|---|
| firefox51 | --- | unaffected |
| firefox52 | --- | unaffected |
| firefox-esr52 | --- | unaffected |
| firefox53 | --- | unaffected |
| firefox54 | --- | disabled |
| firefox55 | --- | fixed |
People
(Reporter: decoder, Assigned: bhackett1024)
Details
(4 keywords, Whiteboard: [jsbugmon:update,bisect])
Attachments
(1 file)
|
2.67 KB,
patch
|
jandem
:
review+
|
Details | Diff | Splinter Review |
The following testcase crashes on mozilla-central revision e91de6fb2b3d (build with --enable-posix-nspr-emulation --enable-valgrind --enable-gczeal --disable-tests --enable-stdcxx-compat --disable-profiling --enable-debug --without-intl-api --enable-optimize --target=i686-pc-linux-gnu, run with --fuzzing-safe):
evalInCooperativeThread('cooperativeYield(); var dbg = new Debugger();');
Backtrace:
received signal SIGSEGV, Segmentation fault.
#0 0x0866d8ee in js::CheckThreadLocal::check (this=0xf793a9d4) at js/src/threading/ProtectedData.cpp:47
#1 0x0867b177 in js::ProtectedData<js::CheckThreadLocal, bool>::ref (this=0xf793a9d0) at js/src/threading/ProtectedData.h:101
#2 js::ProtectedData<js::CheckThreadLocal, bool>::operator bool const& (this=0xf793a9d0) at js/src/threading/ProtectedData.h:81
#3 js::OnHelperThread<(js::AllowedHelperThread)1> () at js/src/threading/ProtectedData.cpp:30
#4 js::CheckActiveThread<(js::AllowedHelperThread)1>::check (this=0xf7933398) at js/src/threading/ProtectedData.cpp:61
#5 0x085d3773 in js::ProtectedData<js::CheckActiveThread<(js::AllowedHelperThread)1>, mozilla::Vector<js::ZoneGroup*, 4u, js::SystemAllocPolicy> >::ref (this=0xf7933374) at js/src/threading/ProtectedData.h:101
#6 js::ZoneGroupsIter::ZoneGroupsIter (this=0xffffd520, rt=0xf7933000) at js/src/gc/Zone.h:617
#7 0x0879b2e5 in CheckCanChangeActiveContext (rt=rt@entry=0xf7933000) at js/src/vm/Runtime.cpp:349
#8 0x0879d371 in JSRuntime::setActiveContext (this=0xf7933000, cx=0xf793a800) at js/src/vm/Runtime.cpp:357
#9 0x0854b677 in js::ResumeCooperativeContext (cx=0xf793a800) at js/src/jscntxt.cpp:205
#10 0x0807ef64 in CooperativeEndWait (cx=<optimized out>) at js/src/shell/js.cpp:3415
#11 0x08077454 in KillWorkerThreads (cx=<optimized out>) at js/src/shell/js.cpp:3946
#12 main (argc=3, argv=0xffffd8c4, envp=0xffffd8d4) at js/src/shell/js.cpp:8449
eax 0x0 0
ebx 0x8cfcff4 147836916
ecx 0xf7da4864 -136689564
edx 0x0 0
esi 0xf793a9d4 -141317676
edi 0x8cfcff4 147836916
ebp 0xffffd4b8 4294956216
esp 0xffffd490 4294956176
eip 0x866d8ee <js::CheckThreadLocal::check() const+174>
=> 0x866d8ee <js::CheckThreadLocal::check() const+174>: movl $0x0,0x0
0x866d8f8 <js::CheckThreadLocal::check() const+184>: ud2
| Assignee | ||
Comment 1•8 years ago
|
||
This is a bogus assert, but the issue is that when handing off the runtime from one cooperative thread to another there is a period of time where the runtime has no active context and no accesses to ActiveThreadData are permitted. Previously we worked around this by making the sanity-check fields Atomic<> so they can be accessed by any thread, but now that we iterate the zone groups to make sure none are owned by a context when in single threaded mode this workaround doesn't really suffice anymore. This patch suppresses protected data checks when we are handing off the runtime.
Assignee: nobody → bhackett1024
Attachment #8843931 -
Flags: review?(jdemooij)
Updated•8 years ago
|
Updated•8 years ago
|
Attachment #8843931 -
Flags: review?(jdemooij) → review+
Pushed by bhackett@mozilla.com:
https://hg.mozilla.org/integration/mozilla-inbound/rev/89d1150ef4f3
Suppress protected data checks when handing off runtimes between cooperative threads, r=jandem.
Comment 3•8 years ago
|
||
| bugherder | ||
Status: NEW → RESOLVED
Closed: 8 years ago
status-firefox55:
--- → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla55
Updated•8 years ago
|
You need to log in
before you can comment on or make changes to this bug.
Description
•