Closed Bug 886551 Opened 11 years ago Closed 11 years ago

GenerationalGC: Crash [@ GetGCThingRuntime] or Opt-Crash [@ tenuredZone]

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
major

Tracking

()

RESOLVED FIXED
mozilla25

People

(Reporter: decoder, Assigned: terrence)

References

Details

(Keywords: crash, testcase, Whiteboard: [jsbugmon:ignore])

Crash Data

Attachments

(1 file)

The following testcase crashes on mozilla-central built with --enable-exact-rooting --enable-gcgenerational, revision 76820c6dff7b (run with --fuzzing-safe --ion-eager): gc(); gcslice(0); var thisValues = [ "x" ]; thisValues.forEach(function (value) { var format = Intl.DateTimeFormat.call(value); });
Another test, involving WeakMaps this time: gc(); gcslice(0); function isClone(a, b) { var rmemory = new WeakMap(); rmemory.set(a,b); } isClone([]);
Attached patch v0 (deleted) — Splinter Review
It turns out that the "fix" for bug 883472 caused this and probably some other fuzz bugs. The problem is that it is fine to fire the pre-barriers if the the object has not been relocated -- which is why this didn't immediately show up -- but after it has been relocated the pre-barrier will crash. The simple solution is to turn off the runtime needsBarrier, but leave the zone needsBarrier alone so that we do not regress bug 883472. The attached patch undoes the runtime portion of bug 883472 and adds the two tests here to ensure that we don't regress again.
Assignee: general → terrence
Status: NEW → ASSIGNED
Attachment #767360 - Flags: review?(bhackett1024)
Crash Signature: [@ GetGCThingRuntime] or Opt-Crash [@ tenuredZone] → [@ js::gc::GetGCThingRuntime()] or Opt-Crash [@ tenuredZone]
Comment on attachment 767360 [details] [diff] [review] v0 Review of attachment 767360 [details] [diff] [review]: ----------------------------------------------------------------- It seems strange that the minor collector triggers pre barriers at all and it would be nice if this wasn't possible / was asserted. For now this seems fine though.
Attachment #767360 - Flags: review?(bhackett1024) → review+
(In reply to Brian Hackett (:bhackett) from comment #4) > > It seems strange that the minor collector triggers pre barriers at all and > it would be nice if this wasn't possible / was asserted. For now this seems > fine though. This is the result of two separate concessions to simplicity. (1) We want to re-use EncapsulatedPtr in HashTables rather than requiring a new type there. (2) We want to use a common implementation of the post-barrier logic for HashTable, WeakMap, Watchpoint, and probably other keys. The upshot is that HashKeyRef is currently templatized on the key and we can't easily cast out the EncapsulatedPtr to its underlying type. We can, of course, specialize all of these, but I agree that we should do that later. I've filed bug 887030 so we don't forget to revisit this. https://hg.mozilla.org/integration/mozilla-inbound/rev/0b81bf199408
Flags: in-testsuite+
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: