Closed Bug 885607 Opened 11 years ago Closed 11 years ago

GenerationalGC: Crash [@ js::gc::GetGCThingRuntime]

Categories

(Core :: JavaScript Engine, defect)

x86_64
All
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla24

People

(Reporter: gkw, Assigned: terrence)

References

Details

(Keywords: crash, testcase)

Crash Data

Attachments

(3 files)

Attached file stack
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.
Crash Signature: [@ js::gc::GetGCThingRuntime] → [@ js::gc::GetGCThingRuntime()]
Attached patch v0Splinter Review
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)
Attachment #766186 - Flags: review?(bhackett1024) → review+
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 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+
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
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla24
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: