Assertion failure: IsMarkedOrAllocated(static_cast<Cell *>(*thingp)), at jsgc.cpp:4351

RESOLVED FIXED in mozilla14



JavaScript Engine
5 years ago
5 years ago


(Reporter: decoder, Assigned: billm)


(Blocks: 1 bug, {assertion, testcase})

assertion, testcase

Firefox Tracking Flags

(firefox12 unaffected, firefox13 affected, firefox-esr10 unaffected)


(Whiteboard: [sg:nse] js-triage-done [jsbugmon:update,reconfirm,ignore])


(2 attachments)



5 years ago
Created attachment 610610 [details]
Test case for shell (run with -n -m -a)

The attached test asserts on mozilla-central revision fb23c30e3d60 (options -m -n -a). Assuming s-s due to GC related assertion.
For the record in case bug summary changes:

Assertion failure: IsMarkedOrAllocated(static_cast<Cell *>(*thingp)), at jsgc.cpp:435

Is this a recent regression? Is the ESR affected?
Whiteboard: js-triage-needed → [sg:critical] js-triage-needed

Comment 2

5 years ago
Thus is only a problem if incremental GC is enabled, and it's currently off by default.
Assignee: general → wmccloskey


5 years ago
Whiteboard: [sg:critical] js-triage-needed → [sg:critical] js-triage-needed [jsbugmon:update,reconfirm]

Comment 3

5 years ago
JSBugMon: This bug has been automatically confirmed to be still valid (reproduced on revision da0d07b5ca1e).


5 years ago
Whiteboard: [sg:critical] js-triage-needed [jsbugmon:update,reconfirm] → [sg:critical] js-triage-needed [jsbugmon:update,reconfirm,ignore]

Comment 4

5 years ago
Created attachment 614209 [details] [diff] [review]

The write barrier verifier is pretty finicky and it needs to see every reachable object at all times. This fixes a case with type objects where we don't trace some properties since, during GC, they'll be thrown away.
Attachment #614209 - Flags: review?(bhackett1024)

Comment 5

5 years ago
Also, this is not sensitive since it only affects the verifier.
Group: core-security
Whiteboard: [sg:critical] js-triage-needed [jsbugmon:update,reconfirm,ignore] → [sg:critical] js-triage-done [jsbugmon:update,reconfirm,ignore]
Attachment #614209 - Flags: review?(bhackett1024) → review+

Comment 6

5 years ago
Target Milestone: --- → mozilla14
Reducing the severity to "moderate" based on a non-default configuration (incremental GC is disabled, comment 2). Incremental GC didn't even exist until Firefox 13 so we'd never need this on ESR10.

(In reply to Bill McCloskey (:billm) from comment #5)
> Also, this is not sensitive since it only affects the verifier.

The verifier is shell only? Or is there something non-obvious in decoder's testcase that's triggering the verifier that regular web content couldn't? Or is this assertion something a web-content-triggered verifier might notice but wouldn't actually affect GC in any way, even if the user has incremental GC enabled? Help me understand this so we can avoid bothering you with bogus security bugs in the future.
status-firefox-esr10: --- → unaffected
status-firefox12: --- → unaffected
status-firefox13: --- → affected
Whiteboard: [sg:critical] js-triage-done [jsbugmon:update,reconfirm,ignore] → [sg:moderate] js-triage-done [jsbugmon:update,reconfirm,ignore]

Comment 8

5 years ago
Sorry for being so brief. The write barrier verifier is basically a gigantic assertion to check that we don't leave out GC write barriers. Like an assertion, the verifier only runs in debug builds. In some cases, when the verifier asserts, it points to a serious problem, but only if incremental GC is enabled. This was not one of those cases. In the case of this bug, the problem was in the verifier itself. That is, the assertion was tripping even though nothing bad has happened. So this bug has no security relevance at all because it only affects debug-mode browsers.
Thanks, now I get it.
Whiteboard: [sg:moderate] js-triage-done [jsbugmon:update,reconfirm,ignore] → [sg:nse] js-triage-done [jsbugmon:update,reconfirm,ignore]
Last Resolved: 5 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.