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?
Thus is only a problem if incremental GC is enabled, and it's currently off by default.
JSBugMon: This bug has been automatically confirmed to be still valid (reproduced on revision da0d07b5ca1e).
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.
Also, this is not sensitive since it only affects the verifier.
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.
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.