Last Comment Bug 731181 - Assertion failure: cx->runtime->gcNumber == gcNumberBefore, at js/src/vm/RegExpObject.cpp:655
: Assertion failure: cx->runtime->gcNumber == gcNumberBefore, at js/src/vm/RegE...
Status: VERIFIED FIXED
[sg:critical] js-triage-done [advisor...
: assertion, regression, testcase
Product: Core
Classification: Components
Component: JavaScript Engine (show other bugs)
: Trunk
: x86_64 Linux
: -- critical (vote)
: mozilla13
Assigned To: Luke Wagner [:luke]
:
Mentors:
Depends on:
Blocks: langfuzz 724748
  Show dependency treegraph
 
Reported: 2012-02-28 06:16 PST by Christian Holler (:decoder)
Modified: 2013-01-14 07:49 PST (History)
7 users (show)
choller: in‑testsuite+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
unaffected
fixed
unaffected
unaffected


Attachments
Test case for shell (see README file inside). (2.07 KB, application/x-compressed-tar)
2012-02-28 06:16 PST, Christian Holler (:decoder)
no flags Details
patch (1.62 KB, patch)
2012-02-28 14:37 PST, Luke Wagner [:luke]
wmccloskey: review+
Details | Diff | Review

Description Christian Holler (:decoder) 2012-02-28 06:16:11 PST
Created attachment 601259 [details]
Test case for shell (see README file inside).

The attached test asserts on mozilla-central revision 2dc40eb83023 (see README for running instructions).

The test does not crash when stepping through the assert, but trips other dangerous assertions:

Program received signal SIGABRT, Aborted.
Assertion failure: mutationCount == p.mutationCount, at ./dist/include/js/HashTable.h:688

Program received signal SIGABRT, Aborted.
Assertion failure: !p.found(), at ./dist/include/js/HashTable.h:690

I assume it's some form of memory corruption (test is also fragile). S-s for that.
Comment 1 Luke Wagner [:luke] 2012-02-28 10:20:41 PST
Mmm fuzzing + strong assertions.  I thought I had verified that RegExpShared::compile didn't do any GC-thing allocation but I must have been looking at RegExpCode::compile b/c RegExpShare::compile clearly allocates an atom.
Comment 2 Luke Wagner [:luke] 2012-02-28 14:32:04 PST
There is a pretty simple reproducible test case:

  gczeal(2,1);
  /a/y.exec('a')

The '1' arg tells GC to start GC'ing on every allocation immediately (instead of waiting for a while).  Perhaps the fuzzers could be souped up to use this?
Comment 3 Luke Wagner [:luke] 2012-02-28 14:37:04 PST
Created attachment 601412 [details] [diff] [review]
patch

Remove those filthy lies.
Comment 4 Bill McCloskey (:billm) 2012-02-28 14:52:17 PST
Comment on attachment 601412 [details] [diff] [review]
patch

Yeah, this just looks better all around.
Comment 5 Jesse Ruderman 2012-02-28 15:09:07 PST
jsfunfuzz should generate gczeal(2, 1) fairly often. (How is that different from gczeal(2))?
Comment 7 Ed Morley [:emorley] 2012-02-29 11:20:08 PST
https://hg.mozilla.org/mozilla-central/rev/2742bfe821d2
Comment 8 Daniel Veditz [:dveditz] 2012-03-17 08:29:52 PDT
I assume GC things can be exploited (e.g. the Pwn2Own bug). Since this is a regression from bug 724748 we don't need it anywhere other than Fx13
Comment 9 Christian Holler (:decoder) 2013-01-14 07:49:34 PST
A testcase for this bug was automatically identified at js/src/jit-test/tests/basic/testBug731181.js.

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