Closed Bug 465454 Opened 16 years ago Closed 16 years ago

TM: Crash [@ JITted code] with this type-unstable loop

Categories

(Core :: JavaScript Engine, defect, P1)

Product:
Core
Component:
JavaScript Engine
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla1.9.1

People

(Reporter: jruderman, Assigned: brendan)

Details

(Keywords: crash, testcase, verified1.9.1, Whiteboard: [fixed by 465460])

Crash Data

for each (let b in [(-1/0), new String(''), new String(''), null, (-1/0), (-1/0), new String(''), new String(''), null]) '' + b;
This is due to classifying null as object when tracing and in typemaps. We need to null-guard, which is another branch test for a rare hard case. I think it is better to classify null as a distinct type.

undefined arguably should be its own trace typemap type too, but at least it's lumped into boolean. Imagine if it were included in object -- that's analogous to what we do with null.

/be
Assignee: general → brendan
Status: NEW → ASSIGNED
OS: Mac OS X → All
Priority: -- → P1
Hardware: PC → All
Target Milestone: --- → mozilla1.9.1
Would it make sense to group null and undefined together as one tracing type?
Summary: Crash [@ JITted code] with this type-unstable loop → TM: Crash [@ JITted code] with this type-unstable loop
Flags: blocking1.9.1+
No longer crashes.  Instead, incorrectly throws "TypeError: b is null" (only with JIT on).
WFM now that bug 465460 is fixed.

/be
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Adding fixed1.9.1 as bug 465460 is fixed1.9.1
Keywords: fixed1.9.1
Whiteboard: [fixed by 465460]
js1_8/regress/regress-465454.js
v 1.9.1, 1.9.2
Status: RESOLVED → VERIFIED
Keywords: fixed1.9.1 → verified1.9.1
Crash Signature: [@ JITted code]
You need to log in before you can comment on or make changes to this bug.