Closed Bug 740509 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: JavaScript Engine, defect)

x86_64
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED
mozilla14
Tracking Status
firefox12 --- unaffected
firefox13 --- affected
firefox-esr10 --- unaffected

People

(Reporter: decoder, Assigned: billm)

Details

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

Attachments

(2 files)

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
Thus is only a problem if incremental GC is enabled, and it's currently off by default.
Assignee: general → wmccloskey
Whiteboard: [sg:critical] js-triage-needed → [sg:critical] js-triage-needed [jsbugmon:update,reconfirm]
JSBugMon: This bug has been automatically confirmed to be still valid (reproduced on revision da0d07b5ca1e).
Whiteboard: [sg:critical] js-triage-needed [jsbugmon:update,reconfirm] → [sg:critical] js-triage-needed [jsbugmon:update,reconfirm,ignore]
Attached patch patchSplinter 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)
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+
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.
Whiteboard: [sg:critical] js-triage-done [jsbugmon:update,reconfirm,ignore] → [sg:moderate] js-triage-done [jsbugmon:update,reconfirm,ignore]
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]
https://hg.mozilla.org/mozilla-central/rev/e3a77f2630c3
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: