Closed
Bug 885607
Opened 11 years ago
Closed 11 years ago
GenerationalGC: Crash [@ js::gc::GetGCThingRuntime]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
mozilla24
People
(Reporter: gkw, Assigned: terrence)
References
Details
(Keywords: crash, testcase)
Crash Data
Attachments
(3 files)
16.29 KB,
text/plain
|
Details | |
10.95 KB,
patch
|
bhackett1024
:
review+
|
Details | Diff | Splinter Review |
947 bytes,
patch
|
luke
:
review+
|
Details | Diff | Splinter Review |
The upcoming testcase crashes js debug shell (tested with a threadsafe deterministic 64-bit debug build) on m-i changeset 0d4b46a6de4c without any CLI arguments at js::gc::GetGCThingRuntime.
I sent the testcase to Terrence and he is able to reproduce it.
Updated•11 years ago
|
Crash Signature: [@ js::gc::GetGCThingRuntime] → [@ js::gc::GetGCThingRuntime()]
Assignee | ||
Comment 3•11 years ago
|
||
I hit a slightly different assert on this testcase. The attached patch fixes this first assertion. If I run for another few minutes with the attached patch we hit the assert in the bug.
The problem is the same as bug 880816: the fix we pushed there was incorrect. That patch traces IonScript::method_, which is the owner code, not the IC's code. The crash there was probably fixed by luck. The attached patch stores |embedsNurseryPointers_| to IonMacroAssembler when we see a nursery pointer in the IC and adds a single barrier for the entire code after linking.
Assignee: general → terrence
Status: NEW → ASSIGNED
Attachment #766186 -
Flags: review?(bhackett1024)
Updated•11 years ago
|
Attachment #766186 -
Flags: review?(bhackett1024) → review+
Assignee | ||
Comment 4•11 years ago
|
||
The second crash appears to be from AsmJSModule::exports_, which is a JS::Vector of AsmJSModule::ExportedFunction, which contains several HeapPtr<T> fields. These must be RelocatablePtr, not HeapPtr, because they are on the stack and in a Vector.
Attachment #766197 -
Flags: review?(luke)
Comment 5•11 years ago
|
||
Comment on attachment 766197 [details] [diff] [review]
Part2 - ExportedFunction post barrier - v0
D'oh! From IRL: can you also make Global::name_ a RelocatablePtr<PropertyName>?
Attachment #766197 -
Flags: review?(luke) → review+
Assignee | ||
Comment 6•11 years ago
|
||
Assignee | ||
Comment 7•11 years ago
|
||
And this testcase uncovered yet a third crasher after another hour of running.
The problem here is that our HashKeyRef for the WatchpointMap is using the WatchKey implicitly through type T on the stack. This is firing the pre-barrier on WatchKey::object, but the object has already been moved. The pre-barrier's attempt to get obj->zone() is trying to find the zone on shape_, but shape is the relocation magic at this point.
#0 0x000000000040711b in js::gc::GetGCThingRuntime (thing=0xbad0bad1) at ../dist/include/js/HeapAPI.h:101
#1 0x0000000000407416 in js::gc::Cell::isTenured (this=0xbad0bad1) at ../../gc/Heap.h:1014
#2 0x00000000004073b5 in js::gc::Cell::tenuredZone (this=0xbad0bad1) at ../../gc/Heap.h:999
#3 0x0000000000408b9a in js::Shape::zone (this=0xbad0bad1) at ../../vm/Shape.h:831
#4 0x0000000000409e6b in js::ObjectImpl::zone (this=0x7ffff5201270) at ../../vm/ObjectImpl-inl.h:359
#5 0x00000000004340bb in js::ObjectImpl::writeBarrierPre (obj=0x7ffff5201270) at ../vm/ObjectImpl-inl.h:416
#6 0x000000000044f2e3 in js::EncapsulatedPtr<JSObject, unsigned long>::pre (this=0x7fffffff8530) at ../gc/Barrier-inl.h:23
#7 0x0000000000478c96 in js::EncapsulatedPtr<JSObject, unsigned long>::~EncapsulatedPtr (this=0x7fffffff8530, __in_chrg=<optimized out>) at ../gc/Barrier.h:133
#8 0x000000000066e372 in js::WatchKey::~WatchKey (this=0x7fffffff8530, __in_chrg=<optimized out>) at /home/terrence/moz/branch/__clean__/mozilla/js/src/jswatchpoint.h:20
#9 0x000000000080c959 in js::gc::HashKeyRef<js::HashMap<js::WatchKey, js::Watchpoint, js::DefaultHasher<js::WatchKey>, js::SystemAllocPolicy>, js::WatchKey>::mark (this=0x857b144, trc=0x7fffffff8610) at /home/terrence/moz/branch/__clean__/mozilla/js/src/gc/StoreBuffer.h:64
#10 0x00000000005ac5fa in js::gc::StoreBuffer::GenericBuffer::mark (this=0x7ffff7e30008, trc=0x7fffffff8610) at /home/terrence/moz/branch/__clean__/mozilla/js/src/gc/StoreBuffer.cpp:244
#11 0x00000000005acc1e in js::gc::StoreBuffer::mark (this=0x7ffff7e2fd08, trc=0x7fffffff8610) at /home/terrence/moz/branch/__clean__/mozilla/js/src/gc/StoreBuffer.cpp:375
#12 0x0000000000abea6c in js::Nursery::markStoreBuffer (this=0x7ffff7e0fc98, trc=0x7fffffff8610) at /home/terrence/moz/branch/__clean__/mozilla/js/src/gc/Nursery.cpp:471
#13 0x0000000000abec5e in js::Nursery::collect (this=0x7ffff7e0fc98, rt=0x7ffff7e0f010, reason=JS::gcreason::FULL_STORE_BUFFER) at /home/terrence/moz/branch/__clean__/mozilla/js/src/gc/Nursery.cpp:517
#14 0x00000000006b68f5 in js::MinorGC (rt=0x7ffff7e0f010, reason=JS::gcreason::FULL_STORE_BUFFER) at /home/terrence/moz/branch/__clean__/mozilla/js/src/jsgc.cpp:4641
#15 0x000000000065ff35 in js_InvokeOperationCallback (cx=0x10dc390) at /home/terrence/moz/branch/__clean__/mozilla/js/src/jscntxt.cpp:1108
#16 0x000000000065ffb3 in js_HandleExecutionInterrupt (cx=0x10dc390) at /home/terrence/moz/branch/__clean__/mozilla/js/src/jscntxt.cpp:1133
#17 0x0000000000a41960 in js::ion::InterruptCheck (cx=0x10dc390) at /home/terrence/moz/branch/__clean__/mozilla/js/src/ion/VMFunctions.cpp:434
#18 0x0000000000a40321 in js::ion::CheckOverRecursed (cx=0x10dc390) at /home/terrence/moz/branch/__clean__/mozilla/js/src/ion/VMFunctions.cpp:105
Comment 8•11 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/3df4624381b7
https://hg.mozilla.org/mozilla-central/rev/0211a7e4bec6
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
Reporter | ||
Comment 9•11 years ago
|
||
I cloned comment 7 out to bug 886909.
You need to log in
before you can comment on or make changes to this bug.
Description
•