719674 - JS Crash on heap with invalid memory being executed

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Christian Holler (:decoder)]

Attachment: shell testcase, unpack, chdir and run main.js with options "-n -m -a"

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.

Comment 1

[Christian Holler (:decoder)]

Attachment: shell testcase (dbg), unpack, chdir and run main.js with options "-n -m -a"

Here's another, shorter test that works with the debug shell for better debugging.

Comment 2

[Brian Hackett [Laid off!]]

Attachment: patch (47584f117727)

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.

Comment 3

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/6c5229914ef9

Comment 4

[Brian Hackett [Laid off!]]

https://hg.mozilla.org/mozilla-central/rev/6c5229914ef9