If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Assertion failure: compartment()->activeInference

RESOLVED WORKSFORME

Status

()

Core
JavaScript Engine
--
critical
RESOLVED WORKSFORME
6 years ago
3 years ago

People

(Reporter: bc, Unassigned)

Tracking

(Blocks: 1 bug, {assertion, crash})

Trunk
x86
Windows XP
assertion, crash
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [js:inv:p1], URL)

(Reporter)

Description

6 years ago
1. http://stickydiljoe.com/tag/big-mike/

   loads lots of SFW car images.

2.
ASSERTION: JS failed without setting an exception!: 'JS_IsExceptionPending(cx)'

3.
Assertion failure: compartment()->activeInference, at c:/work/mozilla/builds/nightly/mozilla/js/src/jsinfer.cpp:2125

All branches, Windows only. This can oom crash in a number of ways and you may need to repeat several times to get the assertion but it is pretty reproducible on a Windows XP box w/1G and Windows 7 w/2G. If you are running a 64bit build with lots of memory you probably won't see it.

If you need access to a test machine and have mpt access contact me for details.

This is essentially fall out from an image-suck crash
(Reporter)

Updated

6 years ago
Whiteboard: js-triage-needed
(We're using a new whiteboard tag.) Is this an OOM, or is something else going on?
Whiteboard: js-triage-needed → [js:investigate][js:p1]
(Reporter)

Comment 2

6 years ago
It can be OOM if it doesn't assert first. I see a number of different js assertions under high memory pressure especially with these kinds of image suck oom situations. This one appears to be fairly reproducible on my test machines. Instead of js-triage-needed, I should just use the [js:investigate] and leave the priority to you, right?
(In reply to Bob Clary [:bc:] from comment #2)
> It can be OOM if it doesn't assert first. I see a number of different js
> assertions under high memory pressure especially with these kinds of image
> suck oom situations. This one appears to be fairly reproducible on my test
> machines. Instead of js-triage-needed, I should just use the
> [js:investigate] and leave the priority to you, right?

Oops, I should have said something about how we're actually using the new tags. You can just leave it blank. As long as there isn't a js: in the whiteboard, Naveed or I will take a look at it and add something. We'll put js:investigate if we can't figure it out right away.
Whiteboard: [js:investigate][js:p1] → [js:inv:p1]
(Assignee)

Updated

3 years ago
Assignee: general → nobody
(Reporter)

Comment 4

3 years ago
Tested on Beta/39, Aurora/40, Nightly/41 OSX 10.{6,8,9}, RHEL6, Windows XP 32bit, Windows 7 32/64bit -> WFM
Status: NEW → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.