Last Comment Bug 740509 - Assertion failure: IsMarkedOrAllocated(static_cast<Cell *>(*thingp)), at jsgc.cpp:4351
: Assertion failure: IsMarkedOrAllocated(static_cast<Cell *>(*thingp)), at jsgc...
Status: RESOLVED FIXED
[sg:nse] js-triage-done [jsbugmon:upd...
: assertion, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: mozilla14
Assigned To: Bill McCloskey (:billm)
:
Mentors:
Depends on:
Blocks: langfuzz
  Show dependency treegraph
 
Reported: 2012-03-29 11:19 PDT by Christian Holler (:decoder)
Modified: 2012-04-13 04:25 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
affected
unaffected


Attachments
Test case for shell (run with -n -m -a) (2.42 KB, application/javascript)
2012-03-29 11:19 PDT, Christian Holler (:decoder)
no flags Details
patch (4.45 KB, patch)
2012-04-11 16:03 PDT, Bill McCloskey (:billm)
bhackett1024: review+
Details | Diff | Splinter Review

Description Christian Holler (:decoder) 2012-03-29 11:19:49 PDT
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.
Comment 1 Daniel Veditz [:dveditz] 2012-04-05 13:42:20 PDT
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?
Comment 2 Bill McCloskey (:billm) 2012-04-05 14:16:20 PDT
Thus is only a problem if incremental GC is enabled, and it's currently off by default.
Comment 3 Christian Holler (:decoder) 2012-04-05 16:15:54 PDT
JSBugMon: This bug has been automatically confirmed to be still valid (reproduced on revision da0d07b5ca1e).
Comment 4 Bill McCloskey (:billm) 2012-04-11 16:03:33 PDT
Created attachment 614209 [details] [diff] [review]
patch

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.
Comment 5 Bill McCloskey (:billm) 2012-04-11 16:04:35 PDT
Also, this is not sensitive since it only affects the verifier.
Comment 7 Daniel Veditz [:dveditz] 2012-04-12 13:23:57 PDT
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.
Comment 8 Bill McCloskey (:billm) 2012-04-12 13:51:40 PDT
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.
Comment 9 Daniel Veditz [:dveditz] 2012-04-12 13:55:08 PDT
Thanks, now I get it.
Comment 10 Marco Bonardo [::mak] 2012-04-13 04:25:24 PDT
https://hg.mozilla.org/mozilla-central/rev/e3a77f2630c3

Note You need to log in before you can comment on or make changes to this bug.