Assertion failure: thing->zone()->isCollecting() || rt->isAtomsZone(thing->zone()), at gc/Marking.cpp:204

VERIFIED FIXED in Firefox 32

Status

()

Core
JavaScript Engine
--
critical
VERIFIED FIXED
3 years ago
3 years ago

People

(Reporter: decoder, Assigned: bhackett)

Tracking

(Blocks: 1 bug, 4 keywords)

Trunk
mozilla32
x86_64
Linux
assertion, regression, sec-high, testcase
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(firefox31 unaffected, firefox32 verified, firefox-esr24 unaffected)

Details

(Whiteboard: [jsbugmon:update])

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

3 years ago
The following testcase asserts on mozilla-central revision 323156681cef (run with --fuzzing-safe --ion-eager):


String.prototype.search = evalcx('').String.prototype.search;
''.search(/()/);
var iter = Iterator({});
for ( var i = 0; i < 10000000 ; ++i )
  iter[i] = i;
(Reporter)

Comment 1

3 years ago
Created attachment 8432134 [details]
[crash-signature] Machine-readable crash signature
(Reporter)

Comment 2

3 years ago
Marked s-s because this is a GC-related assert.
status-firefox32: --- → affected
Whiteboard: [jsbugmon:update,bisect]
(Reporter)

Updated

3 years ago
Whiteboard: [jsbugmon:update,bisect] → [jsbugmon:update]
(Reporter)

Comment 3

3 years ago
JSBugMon: Bisection requested, result:
=== Tinderbox Build Bisection Results by autoBisect ===

The "good" changeset has the timestamp "20140521111121" and the hash "d1c0446db4d3".
The "bad" changeset has the timestamp "20140521113118" and the hash "32a1e7461250".

Likely regression window: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d1c0446db4d3&tochange=32a1e7461250
(Reporter)

Comment 4

3 years ago
Likely regressed by:

author: Brian Hackett (at Wed May 21 11:31:02 2014 -0700)
changeset: 32a1e7461250
Bug 1010441 - Keep RegExpShared and RegExp jitcode around when preserving jitcode in a compartment, r=billm. 


Needinfo from Brian based on that.
Flags: needinfo?(bhackett1024)
(Assignee)

Comment 5

3 years ago
Created attachment 8432496 [details] [diff] [review]
patch

Thanks!  This actually goes back to the irregexp landing, though it is a latent issue that predated that but which wasn't able to cause problems.  If we execute a proxy for a regexp from another compartment then we'd fetch its RegExpShared directly and use that without entering the compartment for the RegExpShared.  If we compile the regexp then with irregexp the compiled code is created in the wrong compartment (with yarr the compiled code is only associated with the RegExpShared).  The attached patch fixes this by getting a RegExpShared for the current compartment when querying a RegExp proxy.
Assignee: nobody → bhackett1024
Attachment #8432496 - Flags: review?(wmccloskey)
Flags: needinfo?(bhackett1024)
(Assignee)

Updated

3 years ago
Blocks: 1013586
(Assignee)

Updated

3 years ago
Blocks: 1013589
(Assignee)

Comment 6

3 years ago
Created attachment 8432590 [details] [diff] [review]
patch

Oops, I inadvertently attached a patch with the fix deactivated.
Attachment #8432496 - Attachment is obsolete: true
Attachment #8432496 - Flags: review?(wmccloskey)
Attachment #8432590 - Flags: review?(wmccloskey)
(Assignee)

Comment 7

3 years ago
Created attachment 8432593 [details] [diff] [review]
patch for real this time

And I then proceeded to attach the exact same incorrect patch.
Attachment #8432590 - Attachment is obsolete: true
Attachment #8432590 - Flags: review?(wmccloskey)
Attachment #8432593 - Flags: review?(wmccloskey)
(Assignee)

Updated

3 years ago
Duplicate of this bug: 1019034
Blocks: 976446
status-firefox31: --- → unaffected
status-firefox-esr24: --- → unaffected
Keywords: regression, sec-high
Comment on attachment 8432593 [details] [diff] [review]
patch for real this time

Review of attachment 8432593 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/jsproxy.cpp
@@ +2760,5 @@
> +    // compartment the RegExpShared we just got is from, but if it happens to
> +    // be from the correct one then the lookup below will just refetch it from
> +    // the RegExpCompartment without needing to create a new RegExpShared.
> +    RegExpShared *re = proxyGuard.re();
> +    return cx->compartment()->regExps.get(cx, re->getSource(), re->getFlags(), g);

Please put all this in CrossCompartmentWrapper::regexp_toShared.
Attachment #8432593 - Flags: review?(wmccloskey) → review+
(Assignee)

Comment 10

3 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/ae6bd0223b53
https://hg.mozilla.org/mozilla-central/rev/ae6bd0223b53
Status: NEW → RESOLVED
Last Resolved: 3 years ago
status-firefox32: affected → fixed
Flags: in-testsuite?
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
(Reporter)

Updated

3 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 12

3 years ago
JSBugMon: This bug has been automatically verified fixed.
(Reporter)

Updated

3 years ago
status-firefox32: fixed → verified
(Reporter)

Comment 13

3 years ago
JSBugMon: This bug has been automatically verified fixed on Fx32
Group: core-security
You need to log in before you can comment on or make changes to this bug.