Closed Bug 515440 Opened 15 years ago Closed 15 years ago

TM: "Assertion failure: tm->reservedDoublePoolPtr > tm->reservedDoublePool, at ../jstracer.cpp"

Categories

(Core :: JavaScript Engine, defect, P1)

x86
macOS
defect

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- alpha1+
status1.9.2 --- beta3-fixed
status1.9.1 --- ?

People

(Reporter: gkw, Assigned: gal)

References

Details

(Keywords: assertion, regression, testcase, Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file, 1 obsolete file)

for each(let c in [1.3]) { for (var x = 0; x < 4; ++x) { gczeal(2); } } asserts js debug shell on TM tip with -j at Assertion failure: tm->reservedDoublePoolPtr > tm->reservedDoublePool, at ../jstracer.cpp:2050 Setting security-sensitive because it involves gczeal. autoBisect shows it is probably related to bug 463238: The first bad revision is: changeset: 26344:1c6be1c210b9 user: Andreas Gal date: Fri Mar 20 18:52:11 2009 -0700 summary: Support calling arbitrary JSFastNatives from trace (463238, r=brendan).
Flags: blocking1.9.2?
blocking2.0: --- → ?
status1.9.1: --- → ?
Assignee: general → gal
Blocking 1.9.2+, P1, per Gal.
Assignee: gal → general
Flags: blocking1.9.2? → blocking1.9.2+
Priority: -- → P1
Assignee: general → gal
Attached patch patch (obsolete) — Splinter Review
gal - set-a-reviewer-ping?
Attachment #401560 - Flags: review?(jorendorff)
jorendorff, this needs a review
Comment on attachment 401560 [details] [diff] [review] patch OK, so -- I can see why this causes the test not to crash. But fundamentally all gcZeal does is cause GC to happen for sure *at times when it could happen anyway*. It's like the bug is, buying milk always gets us arrested if there's a cop in the minimart. And this patch says, "ok, so if there's a cop, we'll walk away." We no longer have any deep aborts in jsgc.cpp. This indicates to me that we don't think there's anything wrong with buying milk. So I want to know why we're getting arrested.
Attachment #401560 - Flags: review?(jorendorff) → review-
I didn't set a review flag because I am not confident the patch does the right thing. I will confer with jorendorff. Update in a bit.
Attached patch patchSplinter Review
Attachment #401560 - Attachment is obsolete: true
Attachment #404932 - Flags: review?(jorendorff)
gcthingss -> gcthings, fixed
Comment on attachment 404932 [details] [diff] [review] patch >+ } >+ /* Keep reserved objects. */ Blank line between these two. Otherwise it looks good. r=me.
Attachment #404932 - Flags: review?(jorendorff) → review+
This is probably very hard to exploit. http://hg.mozilla.org/tracemonkey/rev/112a84b7e687
Whiteboard: fixed-in-tracemonkey
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
There was a followup on tracemonkey apparently.. http://hg.mozilla.org/tracemonkey/rev/39c7a00d0989
Depends on: 521218
Marking the 14 bugs that are both: * nominated for blocking1.9.3:? * fixed on the 1.9.2 branch (according to status1.9.2) as blocking1.9.3:alpha1, so that we don't have to go through the nominations individually. They're all fixed already (so there's no work to do), and being fixed on 1.9.2 means they probably do block 1.9.3.
blocking2.0: ? → alpha1
Group: core-security
Automatically extracted testcase for this bug was committed: https://hg.mozilla.org/mozilla-central/rev/efaf8960a929
Flags: in-testsuite+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: