Closed Bug 719674 Opened 8 years ago Closed 8 years ago
JS Crash on heap with invalid memory being executed
3.06 KB, application/x-compressed-tar
2.34 KB, application/x-compressed-tar
13.85 KB, patch
|Details | Diff | Splinter Review|
The attached test crashes on mozilla-central revision e5e66f40c35b (32 bit opt build, options -m -n -a). The test is one of a few that recently popped up that seem highly fragile while reducing. GDB Backtrace: Program received signal SIGSEGV, Segmentation fault. 0xf73cd15a in ?? () (gdb) bt #0 0xf73cd15a in ?? () #1 0x08328380 in ?? () #2 0x082fbff4 in ?? () Backtrace stopped: previous frame inner to this frame (corrupt stack?) (gdb) x /4i $pc => 0xf73cd15a: Cannot access memory at address 0xf73cd15a This does not crash in valgrind. S-s and sg:critical due to attempted execution of invalid memory.
Here's another, shorter test that works with the debug shell for better debugging.
Regression from bug 706914, when stubbing a LookupSwitch or TableSwitch, if the native code for the target was not found then the compartment's entire stack was switched over to the interpreter and execution continued. This is not valid to do --- ClearAllFrames must be followed by wiping out all JIT code in the compartment, and clearStackReferences must be followed by wiping out all of the script's code. Updated comments, and went through all uses of these functions to fix any other problems, which turned up issues in recompileForStepMode, and TI-triggered recompilation.
Assignee: general → bhackett1024
Attachment #590742 - Flags: review?(dvander)
Attachment #590742 - Flags: review?(dvander) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.