The default bug view has changed. See this FAQ.

Crash [@ JSScript::isEmpty] // GC related corruption

RESOLVED FIXED

Status

()

Core
JavaScript Engine
--
critical
RESOLVED FIXED
6 years ago
2 years ago

People

(Reporter: decoder, Unassigned)

Tracking

(Blocks: 2 bugs, {crash, regression, testcase})

Trunk
x86_64
Linux
crash, regression, testcase
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox7 unaffected, firefox8+ fixed)

Details

(Whiteboard: js-triage-needed [qa-], crash signature)

(Reporter)

Description

6 years ago
The following test crashes, tested on TI revision 8e7da0684155 (options -j -m -n -a -Z 2):

var TIME_0000  = (function () {  })();
function getTimeZoneDiff() {}


Seems to be a GC related problem that causes a waste amount of different crashes. Must be recently introduced during merge with m-c.
This is a GC hazard, but it looks like it came in on the merge from jsdbg2 and not as a result of a merge botch.  When defining the globals in a top level script, we would root the script's binding info (primarily its empty shape), but nothing else.  This used to be OK as the script has not had its u.object created yet and is invulnerable to GCs, but now the u.object is created earlier (for the debugger newScript hook) so the script itself can be collected while defining globals.

jorendorff, is there something that should be keeping the script rooted here that I missed?  If not, this should go on m-c now I think.

http://hg.mozilla.org/projects/jaegermonkey/rev/74bfd74ca289
Group: core-security
(Reporter)

Comment 2

6 years ago
Ccing clegnitto and chofmann on this, as I can confirm this affects mozilla-central (confirmed with testcase from comment 0 on revision f597467fac5e (debug build) with options "-j -m -Z 2").
(Reporter)

Updated

6 years ago
Summary: TI: Crash [@ JSScript::isEmpty] // GC related corruption → Crash [@ JSScript::isEmpty] // GC related corruption

Comment 3

6 years ago
yeah, we should get this fixed on mozilla-central and aurora if the change ends up there after the war room work tomorrow.
tracking-firefox8: --- → ?
(In reply to Christian Holler (:decoder) from comment #0)
> Seems to be a GC related problem that causes a waste amount of different
> crashes. Must be recently introduced during merge with m-c.

fwiw, I see this too, autoBisect pointing to the m-c merge as well.
I was never able to reproduce this, but I pushed bhackett's fix, which seems obviously correct per comment 1.

http://hg.mozilla.org/mozilla-central/rev/7027d3788076
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → FIXED
This landed before the merge on 8-16 and is in the Firefox 8 beta repo already.
status-firefox7: --- → unaffected
status-firefox8: --- → fixed
tracking-firefox8: ? → +
Keywords: regression, regressionwindow-wanted
Group: core-security
qa- as nothing to do for QA fix verification -- please set to qa+ if this is not the case.
Whiteboard: js-triage-needed → js-triage-needed [qa-]
Keywords: regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.