634629 - Crash [@ js::Value::setInt32(int)]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Bob Clary [:bc] (inactive)]

1. http://baixarodownload.com/category/acaoaventura/page/7
2. Crash Windows

ss since I don't like the write crash.

Operating system: Windows NT
                  5.1.2600 Service Pack 3
CPU: x86
     GenuineIntel family 6 model 44 stepping 2
     1 CPU

Crash reason:  EXCEPTION_ACCESS_VIOLATION_WRITE
Crash address: 0x2870000

Thread 0 (crashed)
 0  mozjs.dll!js::Value::setInt32(int) [jsvalue.h : 353 + 0x18]
    eip = 0x006a5f61   esp = 0x0012b71c   ebp = 0x0012b728   ebx = 0x00000001
    esi = 0x00000069   edi = 0x00000000   eax = 0x00000031   ecx = 0x02870000
    edx = 0x00000031   efl = 0x00010202
    Found by: given as instruction pointer in context
 1  mozjs.dll!js::Interpret(JSContext *,JSStackFrame *,unsigned int,JSInterpMode) [jsinterp.cpp : 4909 + 0x24]
    eip = 0x00772e48   esp = 0x0012b730   ebp = 0x0012c9dc
    Found by: call frame info
 2  mozjs.dll!js::RunScript(JSContext *,JSScript *,JSStackFrame *) [jsinterp.cpp : 650 + 0x10]
    eip = 0x0075d13e   esp = 0x0012c9e4   ebp = 0x0012ca10
    Found by: call frame info
 3  mozjs.dll!js::Execute(JSContext *,JSObject *,JSScript *,JSStackFrame *,unsigned int,js::Value *) [jsinterp.cpp : 1011 + 0x15]
    eip = 0x0075edd0   esp = 0x0012ca18   ebp = 0x0012ca90
    Found by: call frame info
 4  mozjs.dll!EvaluateUCScriptForPrincipalsCommon(JSContext *,JSObject *,JSPrincipals *,unsigned short const *,unsigned int,char const *,unsigned int,jsval_layout *,JSVersion) [jsapi.cpp : 5055 + 0x21]
    eip = 0x006b3945   esp = 0x0012ca98   ebp = 0x0012cac0
    Found by: call frame info
 5  mozjs.dll!JS_EvaluateUCScriptForPrincipalsVersion [jsapi.cpp : 5071 + 0x2d]
    eip = 0x006b3a34   esp = 0x0012cac8   ebp = 0x0012cb08
    Found by: call frame info

Comment 1

[Bob Clary [:bc] (inactive)]

bp-1cc062fe-7f78-4456-be37-8ecfa2110216

Comment 2

[Andreas Gal :gal]

We have a test case. Lets jump on this quickly before the page changes.

Comment 3

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Bob: can you get a minidump, since it's on Windows?

https://developer.mozilla.org/Capturing_a_minidump

Comment 4

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

restoring gal's blocking-?, even though no rationale was given!

Comment 5

[Bob Clary [:bc] (inactive)]

(In reply to comment #3)
> Bob: can you get a minidump, since it's on Windows?
> 
> https://developer.mozilla.org/Capturing_a_minidump

yeah, but its a 130M.

Comment 6

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

zip and put it on dropbox?

Comment 7

[Bob Clary [:bc] (inactive)]

Ok. I have a locally saved version that crashes at the same place. I'll start reducing it. Do we still need the dump?

Comment 8

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

Up to Andreas.

Comment 9

[Bob Clary [:bc] (inactive)]

Note also bug 606960

Comment 10

[Bob Clary [:bc] (inactive)]

Attachment: testcase

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Exploitable?

Comment 12

[Andreas Gal :gal]

The ? is for investigation. Looking now.

Comment 13

[Andreas Gal :gal]

I am not crashing with TM tip, 64-bit linux.

Comment 14

[Andreas Gal :gal]

As far as I can tell this is an invalid pc, reading past the script code, so probably exploitable. I still can't reproduce. I vote blocking and put a JS guy on it to figure out whats up.

Comment 15

[David Anderson [:dvander] - inactive, e-mail if emergency]

STR don't work for me on Linux x64, or Windows 7, both using m-c on the cset in the given crash link. Also doesn't crash on the latest tm nightly. I'll look into this ASAP if I can get a crash dump.

I'm unblocking this because:
 (1) I can't reproduce it.
 (2) comment #14 isn't the cause. It's an invalid read at a page boundary.
     This is almost definitely a case of not committing enough of the
     thread-local contiguous stack. We have lots of random JIT crashes on this
     already, we have no test cases for those, and we're not blocking on them.
 (3) Writes/reads beyond the committed pages, but within the reserved stack,
     will safely segfault. It's not clear whether the commit bounds check is
     wrong, or the actual stack limit bounds check is wrong. The latter would
     be sg:something, but getting this sort of thing to crash reliably is 
     difficult.

Comment 16

[Bob Clary [:bc] (inactive)]

http://dl.dropbox.com/u/21344102/firefoxcrash.dmp

I can also get it in the debugger and answer any questions you may have.

Comment 17

[Andreas Gal :gal]

There are no softblockers any more. If you are sure this is not a problem, lets unblock, otherwise its a hardblocker.

Comment 18

[Andreas Gal :gal]

bc, can we meet you on irc and buddy debugging this?

Comment 19

[David Anderson [:dvander] - inactive, e-mail if emergency]

(Why do we have "hardblocker" then?)

Thanks for the dump, bc, I'll take a look at this now.

Comment 20

[David Anderson [:dvander] - inactive, e-mail if emergency]

Attachment: fix

Wow - awesome bug. I ended up being able to reproduce this in the shell thanks to bc's test case - it's indeed a safe crash, writing beyond the commit depth.

What makes this awesome is that it's a trivial typo to fix and will probably reduce our EnterMethodJIT crashes by 5-10%, since a large portion of those are crashes writing beyond the commit end.

Comment 21

[David Anderson [:dvander] - inactive, e-mail if emergency]

We don't really have to block on this, but the risk is so low and the benefit so high, we should just get it in.

Comment 22

[David Anderson [:dvander] - inactive, e-mail if emergency]

http://hg.mozilla.org/tracemonkey/rev/d0c8f25fe4f5

Comment 23

[Chris Leary [:cdleary] (not checking bugmail)]

cdleary-bot mozilla-central merge info:
http://hg.mozilla.org/mozilla-central/rev/d0c8f25fe4f5