Closed
Bug 528048
Opened 15 years ago
Closed 15 years ago
TM: Crash on trace with recursion, explicit GC
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
VERIFIED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | beta5-fixed |
status1.9.1 | --- | unaffected |
People
(Reporter: gkw, Assigned: dvander)
References
Details
(Keywords: crash, regression, testcase, Whiteboard: [sg:critical?][ccbr] fixed-in-tracemonkey)
Attachments
(1 file, 3 obsolete files)
(deleted),
patch
|
gal
:
review+
|
Details | Diff | Splinter Review |
for (j = 0; j < 3; j++) {}
m = [];
m.concat();
n = [];
n.concat([]);
Function("\
for (i = 0; i < 8; i++)\
((function f1(b, c) {\
if (c) {\
return (gc)()\
}\
f1(b, 1);\
((function f2(d, e) {\
return d.length == e ? 0 : d[e] + f2(d, e + 1)\
})([{}, /x/, /x/], 0))\
})())\
")()
Spun off from bug 523793 comment 3. dvander suggests security-sensitive till more is known.
Reporter | ||
Comment 1•15 years ago
|
||
autoBisect shows this is probably due to bug 459301:
http://hg.mozilla.org/tracemonkey/pushloghtml?fromchange=89e665eb9944&tochange=d04601f54db5
Blocks: tracerecursion
Reporter | ||
Comment 2•15 years ago
|
||
Opt shell with -j stack:
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000001c
Crashed Thread: 0
Thread 0 Crashed:
0 ??? 0x001e3c4c 0 + 1981516
1 js-opt-tm-darwin 0x000fd8d6 __ZL11ExecuteTreeP9JSContextP12TreeFragmentRjPP10VMSideExit + 806
2 js-opt-tm-darwin 0x0011c21a js_MonitorLoopEdge(JSContext*, unsigned int&, RecordReason) + 1322
3 js-opt-tm-darwin 0x0005a0b3 js_Interpret + 48371
4 js-opt-tm-darwin 0x0005e22c js_Execute + 444
5 js-opt-tm-darwin 0x0000d1cc JS_ExecuteScript + 60
6 js-opt-tm-darwin 0x00003cb8 __ZL7ProcessP9JSContextP8JSObjectPci + 1336
7 js-opt-tm-darwin 0x00007db4 main + 2212
8 js-opt-tm-darwin 0x00001c3b _start + 209
9 js-opt-tm-darwin 0x00001b69 start + 41
Whiteboard: [ccbr]
Assignee | ||
Comment 3•15 years ago
|
||
At first I thought there might be a GC hazard but I don't think I'll be so lucky.
From initial debugging it seems like we build a trace which gets obj.proto.proto.valueOf, and |obj| is a RegexObj. Later |obj| is a normal scripted object, and going two links up to the prototype chain is invalid (NULL).
Why this is happening, I'm not yet sure.
Assignee | ||
Comment 4•15 years ago
|
||
I got real lucky here, it is a rooting bug. A property cache guard burns an object address into trace but doesn't root it. It gets freed and reallocated, and later the guard succeeds but on a different object, with a different shape and prototype chain.
Assignee | ||
Comment 5•15 years ago
|
||
This affects 1.9.2, though the test case does not trigger there since we don't trace recursion.
Flags: blocking1.9.2?
Assignee | ||
Updated•15 years ago
|
No longer blocks: tracerecursion
Updated•15 years ago
|
Flags: blocking1.9.2? → blocking1.9.2+
Assignee | ||
Comment 6•15 years ago
|
||
There are a few more possible misuses of INS_CONSTWORD.
Attachment #412109 -
Attachment is obsolete: true
Attachment #412115 -
Flags: review?(gal)
Attachment #412109 -
Flags: review?(brendan)
Comment 7•15 years ago
|
||
Comment on attachment 412115 [details] [diff] [review]
more fixes
With some beautifications as discussed.
Attachment #412115 -
Flags: review?(gal) → review+
Assignee | ||
Comment 8•15 years ago
|
||
Attachment #412115 -
Attachment is obsolete: true
Attachment #412117 -
Flags: review?(gal)
Comment 9•15 years ago
|
||
Comment on attachment 412117 [details] [diff] [review]
prettier patch
>+TraceRecorder::insImmVal(jsval val)
>+{
>+ if (!JSVAL_IS_INT(val) && !JSVAL_IS_SPECIAL(val) && val != JSVAL_NULL)
This should be just JSVAL_IS_GCTHING(val) of course.
>+ treeInfo->gcthings.addUnique(val);
>+ return lir->insImmWord(val);
>+}
/be
Assignee | ||
Comment 10•15 years ago
|
||
Whoops, thanks, didn't realize that existed.
Assignee | ||
Comment 11•15 years ago
|
||
use JSVAL_IS_TRACEABLE
Attachment #412117 -
Attachment is obsolete: true
Attachment #412255 -
Flags: review?(gal)
Attachment #412117 -
Flags: review?(gal)
Updated•15 years ago
|
Whiteboard: [ccbr] → [sg:critical?][ccbr]
Comment 12•15 years ago
|
||
Comment on attachment 412255 [details] [diff] [review]
prettier patch v2
Very nice.
Attachment #412255 -
Flags: review?(gal) → review+
Assignee | ||
Comment 13•15 years ago
|
||
Whiteboard: [sg:critical?][ccbr] → [sg:critical?][ccbr] fixed-in-tracemonkey
Comment 14•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 15•15 years ago
|
||
status1.9.2:
--- → final-fixed
Comment 16•15 years ago
|
||
It was hoped that this patch would fix Bug 530955 and we would verify it in 3.6b5.
doesn't seem like that is the case.
Comment 17•15 years ago
|
||
(In reply to comment #15)
> 2009-12-04 08:01:34 PST
> http://hg.mozilla.org/releases/mozilla-1.9.2/rev/f2cad56bfdcb
maybe the patch landing just missed the cut off? b5 builds were also made right around then.
Comment 18•15 years ago
|
||
From pushlog, it looks like that patch (f2cad56bfdcb) did make it in time for b5:
http://hg.mozilla.org/releases/mozilla-1.9.2/pushloghtml?startdate=12%2F2%2F2009&enddate=12%2F6%2F2009
Updated•14 years ago
|
Group: core-security
status1.9.1:
--- → unaffected
Comment 19•13 years ago
|
||
Tracer has been long gone on trunk, marking verified.
Status: RESOLVED → VERIFIED
Comment 20•12 years ago
|
||
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.
Description
•