Closed Bug 1300210 Opened 5 years ago Closed 5 years ago

Initialize nsCCUncollectableMarker::sGeneration to 1


(Core :: DOM: Core & HTML, defect)

Not set



Tracking Status
firefox51 --- fixed


(Reporter: mccr8, Assigned: mccr8)




(1 file)

Otherwise we treat our GCs before the first CC like shutdown which is weird.
The immediate reason we need to fix this is that Terrence added a verifier that there are no black-gray edges in the JS heap, and this causes that to fail, due to mozilla::dom::TraceBlackJS(). If something is a black root, I believe the verifier requires that it be marked black. This makes sense, because a black root is something that is definitely alive, and if the object is marked gray, the CC might free it.

However, Boris was seeing a case where the browser starts, we GC and mark the whatever stuff at the bottom of TraceBlackJS grey. Then we run the CC, which flips sGeneration to 1. Now, the verifier runs, and it sees that the stuff in TraceBlackJS claims to be black, but is grey, causing a failure.

In this particular case the code is actually safe. The purpose of the black-gray invariant is to ensure that the CC does not incorrectly free any gray objects that are reachable from black JS roots. The objects in TraceBlackJS should all be reachable directly from a C++ object, and the CC knows that those C++ objects are alive (because of refcounting). Therefore, the CC will not unlink any objects that are reachable from black JS roots.

Anyways, the easiest fix here is to simply start at 1 instead of 0.
Blocks: 1299911
Comment on attachment 8787795 [details]
Bug 1300210 - Initialize nsCCUncollectableMarker::sGeneration to 1.
Attachment #8787795 - Flags: review?(bugs) → review+
Pushed by
Initialize nsCCUncollectableMarker::sGeneration to 1. r=smaug
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla51
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.