Closed
Bug 540243
Opened 15 years ago
Closed 15 years ago
Crash [@ js_GetUpvar]
Categories
(Core :: JavaScript Engine, defect)
Tracking
()
RESOLVED
FIXED
People
(Reporter: gkw, Assigned: dmandelin)
References
Details
(Keywords: crash, regression, testcase, Whiteboard: [ccbr]fixed-in-tracemonkey)
Crash Data
Attachments
(1 file)
2.93 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
for (a in (eval("\
function() {\
return function() {\
yield ((function() {\
return d\
})())\
} ();\
var d = []\
}\
"))());
crashes js opt and debug shell on TM tip at js_GetUpvar near null.
autoBisect shows this is probably related to bug 452498:
The first bad revision is:
changeset: 26784:2cf0bbe3772a
user: Brendan Eich
date: Sun Apr 05 21:17:22 2009 -0700
summary: upvar2, aka the big one take 2 (452498, r=mrbkap).
Exception Type: EXC_BAD_ACCESS (SIGBUS)
Exception Codes: KERN_PROTECTION_FAILURE at 0x000000000000001c
Crashed Thread: 0 Dispatch queue: com.apple.main-thread
Thread 0 Crashed: Dispatch queue: com.apple.main-thread
0 js-opt-32-tm-darwin 0x0005cb1d js_GetUpvar + 29
1 js-opt-32-tm-darwin 0x0004f46d js_Interpret + 2765
2 js-opt-32-tm-darwin 0x00060b3f SendToGenerator(JSContext*, JSGeneratorOp, JSObject*, JSGenerator*, long) + 159
3 js-opt-32-tm-darwin 0x00060d7a generator_op(JSContext*, JSGeneratorOp, long*, unsigned int) + 218
4 js-opt-32-tm-darwin 0x0005efa0 js_Invoke + 1584
5 js-opt-32-tm-darwin 0x0005f7ac js_InternalInvoke + 140
6 js-opt-32-tm-darwin 0x00060617 js_CallIteratorNext + 151
7 js-opt-32-tm-darwin 0x00050dd8 js_Interpret + 9272
8 js-opt-32-tm-darwin 0x0005e65c js_Execute + 444
9 js-opt-32-tm-darwin 0x0000d91c JS_ExecuteScript + 60
10 js-opt-32-tm-darwin 0x000047c5 Process(JSContext*, JSObject*, char*, int) + 1621
11 js-opt-32-tm-darwin 0x00008726 main + 1734
12 js-opt-32-tm-darwin 0x0000264d _start + 208
13 js-opt-32-tm-darwin 0x0000257c start + 40
Flags: blocking1.9.2?
Reporter | ||
Comment 1•15 years ago
|
||
This issue occurs without -j.
Summary: TM: Crash [@ js_GetUpvar] → Crash [@ js_GetUpvar]
Comment 2•15 years ago
|
||
I take it that you discovered this with a 1.9.2 RC2 build? Does it occur in RC1 and previous milestones?
Reporter | ||
Comment 3•15 years ago
|
||
(In reply to comment #2)
> I take it that you discovered this with a 1.9.2 RC2 build? Does it occur in RC1
> and previous milestones?
This occurs with 1.9.2 branch tip and 1.9.1 branch tip js shells. I'm not sure if the browser is as easily affected as well.
Comment 4•15 years ago
|
||
clearing nominations as it's unclear why we want to block on this - stability? security? do we know if it affects the browser?
Renominate when you've got some deets for us! :)
blocking1.9.1: ? → ---
Flags: blocking1.9.2?
Assignee | ||
Updated•15 years ago
|
Assignee: general → dmandelin
Assignee | ||
Comment 5•15 years ago
|
||
This is similar to bug 528644, but in this case we have an upvar defined "above" (i.e., in an enclosing lexical scope) a generator function and used "below" the generator function. The above function has returned by the time we access the upvar. In general, it is possible that a generator function has "returned" by the time expressions inside it have been evaluated. (When the generator is called, it immediately returns, and then runs code inside it as yield is called.) Because the generator has returned, it is also possible that functions that enclose the generator have returned. So it is not valid to use the display optimization if the def-use chain crosses a generator function lexical scope.
It seemed to me like it would be possible to trigger this kind of bug with MakeUpvarForEval as well, but I modified the test case so that the def-use chain also crosses the eval, and it didn't crash.
Attachment #422822 -
Flags: review?(mrbkap)
Updated•15 years ago
|
Attachment #422822 -
Flags: review?(mrbkap) → review+
Assignee | ||
Comment 6•15 years ago
|
||
This is the dog that didn't bark in comment 5 para 2:
function m() {
var d = 73;
for (a in (eval("\n\
function() {\n\
return function() {\n\
yield ((function() {\n\
print(d);\n\
return d\n\
})())\n\
} ();\n\
}\n\
"))());
}
m();
Assignee | ||
Comment 7•15 years ago
|
||
Whiteboard: [ccbr] → [ccbr]fixed-in-tracemonkey
Comment 8•15 years ago
|
||
function m() {
var d = 73;
return (eval("\n\
function() {\n\
return function() {\n\
yield ((function() {\n\
print(d);\n\
return d\n\
})())\n\
} ();\n\
}\n\
"))();
}
m().next();
Is the dog that barks:
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x00000018
0x00098b5e in js_GetUpvar (cx=0x309c00, level=1, cookie=262144) at jsinterp.cpp:2075
2075 JS_ASSERT(fp->script);
Dave, can you add this to trace-test too? Thanks,
/be
Comment 9•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•13 years ago
|
Crash Signature: [@ js_GetUpvar]
Comment 10•12 years ago
|
||
A testcase for this bug was automatically identified at js/src/jit-test/tests/closures/bug540243.js.
Flags: in-testsuite+
You need to log in
before you can comment on or make changes to this bug.
Description
•