583680 - JM: Crash [@ 0xf7685768]

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

function f(foo) {
    foo.replace(/s/, "")
    Function(foo)()
}
for (a = 0; a < 1000; a++) {
    f("\
      for (var b = 0; b < 7; b++) {\
        gczeal(2)\
      }\
    ")
}

asserts js debug shell on JM changeset 2ee92d697741 with -m at a weird memory address.


Program received signal SIGSEGV, Segmentation fault.
0xf7685768 in ?? ()
(gdb) bt
#0  0xf7685768 in ?? ()
#1  0xf76a815d in ?? ()
#2  0x08212004 in js::mjit::JaegerShot (cx=0x833ecf0) at ../methodjit/MethodJIT.cpp:696
#3  0x080d803c in js::RunScript (cx=0x833ecf0, script=0x8345a78, fun=0x0, scopeChain=0xf7502000) at ../jsinterp.cpp:461
#4  0x080d8e35 in js::Execute (cx=0x833ecf0, chain=0xf7502000, script=0x8345a78, down=0x0, flags=0, result=0x0) at ../jsinterp.cpp:949
#5  0x0806f778 in JS_ExecuteScript (cx=0x833ecf0, obj=0xf7502000, script=0x8345a78, rval=0x0) at ../jsapi.cpp:4736
#6  0x0804be15 in Process (cx=0x833ecf0, obj=0xf7502000, filename=0xffffd5d5 "ic.js", forceTTY=0) at ../../shell/js.cpp:440
#7  0x0804ccf9 in ProcessArgs (cx=0x833ecf0, obj=0xf7502000, argv=0xffffd408, argc=2) at ../../shell/js.cpp:860
#8  0x08055314 in shell (cx=0x833ecf0, argc=2, argv=0xffffd408, envp=0xffffd414) at ../../shell/js.cpp:4981
#9  0x08055430 in main (argc=2, argv=0xffffd408, envp=0xffffd414) at ../../shell/js.cpp:5077
(gdb) x/i $eip
=> 0xf7685768:	Cannot access memory at address 0xf7685768

Comment 1

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

fwiw, this was a royal PITA to reduce. :-/

Comment 2

[Gary Kwong [:gkw] [:nth10sd] (NOT official MoCo now)]

Try passing in as a CLI argument if unable to reproduce..

Comment 3

[Andrew Drake [:adrake]]

Only crashes on 32-bit with ICs enabled.

Comment 4

[Andrew Drake [:adrake]]

Bisection results:

Changeset 49107:c2e4e788c37c: good
The first bad revision is:                                                                                                                                                                                                                    
changeset:   49108:c0bea72054fc
user:        David Mandelin <[e-mail]>
date:        Fri Jul 30 15:01:08 2010 -0700
summary:     Bug 583382: reset pics to correct stub, r=dvander

Comment 5

[Andrew Drake [:adrake]]

With a /lot/ of coercion (I feel your pain Gary), and with JMFLAGS=jsops (?!), this produces the same assertion as bug 583675 . It even crashes in the same place, upon attempting to call a function property of a string. I'm tempted to mark this as a duplicate since the other test case is more direct and seems to do the same thing. Self-assigning both since I might as well.

Comment 6

[Andrew Drake [:adrake]]

Sadly, fixing bug 583675 didn't fix this one, so not a duplicate. Debugging this one now.

Comment 7

[Andrew Drake [:adrake]]

So, I have at least a preliminary cause. The PreGCCleanup runs a purge on the current thread data. This causes us to blow away all the PICs -- even of currently running scripts -- leading to the above and many more crashes. When do we actually want to do this -- since clearly GC time isn't ideal? Or do we want to check if the script is alive first, clearing out its native code too?

Comment 8

[Andrew Drake [:adrake]]

Attachment: Patch v0

Passes all trace-tests, and fixes this test case.

Comment 9

[Brendan Eich [:brendan]]

Why were PICs being purged with other thread-data-homed weak refs?

Shapes are going away, but shape regeneration is rare (2^24 shapes).

/be

Comment 10

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

(In reply to comment #9)

Brendan, I was looking for a quick place to throw it, the only thing that popped out was purge when shape regen flag is set. Is there a better place?

Comment 11

[Brendan Eich [:brendan]]

Is that what is actually happening (shape regen)? Probably due to the XBL shape generation at high rate bug.

Shapes as generated uints will go away but one could imagine purging caches of all kinds due to some rare event, so it's good to defend if cheap (or ward off if you can do that instead).

/be

Comment 12

[Andrew Drake [:adrake]]

http://hg.mozilla.org/users/danderson_mozilla.com/moo/rev/ed5cfed88ffb

Comment 13

[Christian Holler (:decoder)]

Automatically extracted testcase for this bug was committed:

https://hg.mozilla.org/mozilla-central/rev/efaf8960a929