Crash from a scratchpad's sandbox: "Assertion Failure: rt->heapState == JSRuntime::Idle"

RESOLVED FIXED in mozilla17

Status

()

Core
XPConnect
--
critical
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: espadrine, Unassigned)

Tracking

({assertion, crash})

Trunk
mozilla17
x86_64
Linux
assertion, crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

5 years ago
Backtrace: http://pastebin.mozilla.org/1747828

Situation: writing in the scratchpad that may have evaluated
something in the background.

I got the following message, too:
Assertion failure: rt->heapState == JSRuntime::Idle, at /home/tyl/files/cloud/fx-team/js/src/jsapi.cpp:241
(Reporter)

Comment 1

5 years ago
Created attachment 650766 [details]
Backtrace

Updated

5 years ago
Severity: normal → critical
Crash Signature: [@ JS_GetGlobalForScopeChain]
Keywords: assertion, crash
Bill, Nick, looks like we're running into an AssertHeapIsIdle assertion while collecting compartment stats. Can you have a look at the stack and say where we're going wrong?
Created attachment 651240 [details] [diff] [review]
Loosen over-tight assertion in JS_GetGlobalForScopeChain.

I assume it's reasonable for JS_GetGlobalForScopeChain() to be called within
a call to nsXPConnect::GetNativeOfWrapper()?  If so, the assertion is too
strong, and should be changed to AssertHeapIsIdleOrIterating().

It's possible that we'll see this same overtight assertion in other
jsapi.cpp functions that can be called within GetNativeOfWrapper().
Attachment #651240 - Flags: review?(wmccloskey)
Attachment #651240 - Flags: review?(wmccloskey) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/6615f5ae4ffd

Comment 5

5 years ago
https://hg.mozilla.org/mozilla-central/rev/6615f5ae4ffd
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
You need to log in before you can comment on or make changes to this bug.