Closed Bug 978353 Opened 11 years ago Closed 11 years ago

GenerationalGC: Crash [@ js::DenseRangeRef::mark]

Categories

(Core :: JavaScript Engine, defect)

x86
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla30

People

(Reporter: decoder, Assigned: terrence)

References

Details

(Keywords: crash, testcase, Whiteboard: [jsbugmon:update,bisect])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central built with --enable-exact-rooting --enable-gcgenerational, revision 53dbf19f2f8d (run with --fuzzing-safe): var arr = new Float64Array(2); function test(m) { arr[1] = m; } for(var i=0; i<20000; ++i, Array('x')) test(0);
Whiteboard: [jsbugmon:ignore] → [jsbugmon:update,bisect]
The problem here is in IonBuilder.cpp in getTypedArrayElements. We bake the inline elements of a nursery-allocated array buffer object into the code. We need to either make this access non-constant or hook into TI to invalidate the code when we move the ABO.
Assignee: nobody → terrence
Status: NEW → ASSIGNED
Attachment #8385488 - Flags: review?(bhackett1024)
Comment on attachment 8385488 [details] [diff] [review] nursery_elements_in_jitcode-v0.diff Review of attachment 8385488 [details] [diff] [review]: ----------------------------------------------------------------- I don't think typed arrays in the tenured heap should have elements in the nursery. There isn't any performance benefit to this and the JIT compiler shouldn't be dealing with nursery pointers at all.
Attachment #8385488 - Flags: review?(bhackett1024)
Comment on attachment 8385488 [details] [diff] [review] nursery_elements_in_jitcode-v0.diff The case here is a nursery allocated ArrayBufferObject with inline elements.
Attachment #8385488 - Flags: review?(bhackett1024)
Comment on attachment 8385488 [details] [diff] [review] nursery_elements_in_jitcode-v0.diff Review of attachment 8385488 [details] [diff] [review]: ----------------------------------------------------------------- OK, fair enough.
Attachment #8385488 - Flags: review?(bhackett1024) → review+
Yup, I just checked and the view here actually is tenured. I guess the right, parallelizable way to do this is to use TI: we already have a constraint on the ABO, we just need to poke it from GC. I guess the only way to do that reliably is going to be to move TI to the compartment or runtime. I guess that's mostly blocked on the fact that error reporting is only on the context?
(In reply to Terrence Cole [:terrence] from comment #6) > I guess the only way > to do that reliably is going to be to move TI to the compartment or runtime. > I guess that's mostly blocked on the fact that error reporting is only on > the context? TI is enabled per Zone, not context.
Great! Then it should just be a bit of wiring to add the APIs we need.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: