1165188 - Assertion failure: js::CurrentThreadCanAccessRuntime(runtime_), at ../../../dist/include/js/HeapAPI.h:132

Status: VERIFIED DUPLICATE of bug 1159321

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

Attachment: Crash report OSX nightly

1. https://tangrams.github.io/tangram-sandbox/tangram.html?styles/matrix.yaml#15.785/51.5091/-0.1150

2. reload until assertion appears

3. Assertion failure: js::CurrentThreadCanAccessRuntime(runtime_), at ../../../dist/include/js/HeapAPI.h:132

Aurora/40, Nightly/41 on OSX, Linux, Windows

I used Developer tools/Web Console to open a new tab via w = window.open('about:blank'). I actually had to allow popups then execute that again to get the right window.

In the new tab/window I opened Developer tools/Web Console then executed setInterval('window.opener.document.location.reload()', 120000) and waited.

s-s since similar bugs were.

Comment 1

[Bob Clary [:bc] (inactive)]

Attachment: Crash report OSX Beta/39

Beta/39 as well with a related assertion:

Assertion failure: CurrentThreadCanAccessRuntime(rt), at /mozilla/builds/beta/mozilla/js/src/gc/Heap.h:1258

Comment 2

[Jan de Mooij [:jandem]]

We're firing a pre-barrier under SetAliasedVarOperation and we should be on the main thread there..

Comment 3

[Jan de Mooij [:jandem]]

[Tracking Requested - why for this release]:

Comment 4

[Jan de Mooij [:jandem]]

NI terrence to make sure this doesn't slip through the cracks.

Comment 5

[Terrence Cole [:terrence]]

I think this is almost certainly a dup of bug 1159321, but let me see if I can reproduce it first.

Comment 6

[Terrence Cole [:terrence]]

Great STR Bob! Verified on Aurora (the only unpatched branch still) that this is the same as bug 1159321. This should be fixed as soon as I get aurora approval in bug 1159321.

Comment 7

[Bob Clary [:bc] (inactive)]

:terrence: I can still reproduce this with today's nightly on Windows 7 64bit using the manual steps in comment 0. I can also reproduce this in automation (using Spider) on OSX, Linux, Windows on Nightly. I don't think this is a dupe or if it is, then bug 1159321 isn't fixed.

Comment 8

[Terrence Cole [:terrence]]

Sorry, Bob, I should have mentioned that the fixing changeset on nightly is bfcba00a76c0. It landed under cover in bug 1159428. It only got uplifted to m-c at 10 PDT last night to I don't expect it's on nightly yet! Can you check if that changeset is in the tree you tested?

Comment 9

[Bob Clary [:bc] (inactive)]

The Windows 7 64bit build was built just after midnight PDT this morning from http://hg.mozilla.org/mozilla-central/rev/ac277e615f8f

The other platforms are all built every morning just after midnight and may have slightly different revisions.

https://hg.mozilla.org/mozilla-central/rev/bfcba00a76c0 was merged into mozilla-central on 2015-05-02 10:05:09 which is included.

Comment 10

[Terrence Cole [:terrence]]

You are correct! I looked at the wrong bug. That was the first cover bug that landed in what is now Aurora. The new, second, cover bug with the rest of the fix landed just yesterday in:

changeset:   244585:f09a26b8374c
user:        Terrence Cole <[e-mail]>
date:        Wed May 13 19:13:49 2015 -0700
summary:     Bug 1163810 - Use type-based dispatch for IncrementalReferenceBarrier; r=jonco

Comment 11

[Bob Clary [:bc] (inactive)]

Ok, I rebuilt everything and retested the url in this bug and could only reproduce on Aurora.

Comment 12

[Ritu Kothari (:ritu) (Inactive, please n-i to RyanVM, jcristau, or pascal)]

Since the duplicate bug has been resolved fixed, I don't think there is a need to track this bug. Re-setting the tracking FF40 and FF41 flag to empty.

Liz, can you please make a call on whether to track this for 39 or not?

Comment 13

[Liz Henry (:lizzard) (privacy/fingerprinting team)]

bc, can you still reproduce this on aurora? Just checking.

Comment 14

[Bob Clary [:bc] (inactive)]

looks good. nothing anywhere.