Closed Bug 783924 Opened 12 years ago Closed 12 years ago

Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0," or "Assertion failure: !unknownProperties(),"

Categories

(Core :: JavaScript Engine, defect)

x86_64
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla17
Tracking Status
firefox14 --- unaffected
firefox15 --- unaffected
firefox16 --- unaffected
firefox17 --- verified
firefox-esr10 --- unaffected

People

(Reporter: gkw, Assigned: shu)

References

Details

(4 keywords, Whiteboard: [fuzzblocker][adv-track-main17-])

Crash Data

Attachments

(5 files)

Attached file stack
ParallelArray(/x/, /x/);

asserts js debug shell on m-c changeset 35b8d6ef5d46 without any CLI arguments at Assertion failure: dimensions.length() > 0,

Another [fuzzblocker] similar to bug 783923.

autoBisect shows this is probably related to the following changeset:

The first bad revision is:
changeset:   102665:ea2ad8970f3e
user:        Shu-yu Guo
date:        Fri Aug 17 10:38:59 2012 -0700
summary:     Bug 778559 - Implement ParallelArray API with sequential execution (r=dmandelin)
Group: core-security
Attached file stack from opt crash
I just rechecked, this is very bad, 0xffffffff is being accessed.
Crash Signature: [@ js::ParallelArrayObject::IndexInfo::initialize]
Summary: "Assertion failure: dimensions.length() > 0," → Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0,"
Attached file stack
One more testcase:

Function("ParallelArray([])")()

Assertion failure: !unknownProperties(),
Note that the fix for !unknownProperties() patch requires patch in bug 783923 to be already applied.
Attachment #653234 - Flags: review?
Attachment #653235 - Flags: review?
Attachment #653234 - Flags: review? → review?(dmandelin)
Attachment #653235 - Flags: review? → review?(dmandelin)
Comment on attachment 653235 [details] [diff] [review]
fix for !unknownProperties() assert

Actually, this makes more sense to be reviewed by bhackett.
Attachment #653235 - Flags: review?(dmandelin) → review?(bhackett1024)
Summary: Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0," → Crash [@ js::ParallelArrayObject::IndexInfo::initialize] or "Assertion failure: dimensions.length() > 0," or "Assertion failure: !unknownProperties(),"
Attachment #653234 - Flags: review?(dmandelin) → review+
Attachment #653235 - Flags: review?(bhackett1024) → review+
https://hg.mozilla.org/mozilla-central/rev/6087ddaf9911
https://hg.mozilla.org/mozilla-central/rev/f6ff05c68a61
Assignee: general → shu
Status: NEW → RESOLVED
Closed: 12 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla17
Status: RESOLVED → VERIFIED
JSBugMon: This bug has been automatically verified fixed.
(In reply to Gary Kwong [:gkw, :nth10sd] from comment #1)
> I just rechecked, this is very bad, 0xffffffff is being accessed.

If %rax is always null then it doesn't really matter where the other address is, it's still going to crash before it does anything nasty. Is it always null? That seems to be the case the patch is protecting against.
Depends on: 783923
The instruction at %pc register is: movl   $0x1,(%rax,%rcx,4)

Does this mean storing 0x1 at %rax and %rcx, not accessing %rax and %rcx themselves?
Whiteboard: [fuzzblocker] → [fuzzblocker][adv-track-main17-]
Group: core-security
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: