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

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

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;

Comment 1

[Christian Holler (:decoder)]

Attachment: [crash-signature] Machine-readable crash signature

Comment 2

[Christian Holler (:decoder)]

Marked s-s because this is a GC-related assert.

Comment 3

[Christian Holler (:decoder)]

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

Comment 4

[Christian Holler (:decoder)]

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.

Comment 5

[Brian Hackett [Laid off!]]

Attachment: 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.

Comment 6

[Brian Hackett [Laid off!]]

Attachment: patch

Oops, I inadvertently attached a patch with the fix deactivated.

Comment 7

[Brian Hackett [Laid off!]]

Attachment: patch for real this time

And I then proceeded to attach the exact same incorrect patch.

Comment 9

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

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.

Comment 10

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/ae6bd0223b53

Comment 11

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/ae6bd0223b53

Comment 12

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed.

Comment 13

[Christian Holler (:decoder)]

JSBugMon: This bug has been automatically verified fixed on Fx32