683197 - segfault in onNewScript js/src/vm/Debugger.h

Status: RESOLVED WORKSFORME

(Core :: JavaScript Engine, defect)

Description

[clever]

Attachment: backtrace_1.txt

User Agent: Mozilla/5.0 (Windows NT 5.1; rv:6.0) Gecko/20100101 Firefox/6.0
Build ID: 20110811165603

Steps to reproduce:

simply starting firefox while under heavy cpu load with firebug installed can cause a segfault
i'm running nightly SourceStamp=e6591ea9b27b


Actual results:

segfaults on a few different paths, all ending in onNewScript
will attach a few backtraces

Comment 1

[clever]

Attachment: another backtrace

Comment 2

[clever]

Attachment: 3rd backtrace, from when it was idle

Comment 3

[Josh Matthews [:jdm]]

>571     if (!script->compartment->getDebuggees().empty())

Script isn't null here, and the conservative scanner should avoid any kind of GC hazard, so either compartment is null/corrupt or getDebuggees() is returning or doing something bad, I think.

Comment 4

[clever]

i was able to print script->compartment->debuggees in gdb and see it
but .empty() was inlined, and i couldnt figure out how to go any further

Comment 5

[clever]

Attachment: latest backtrace

this latest backtrace includes a few gdb print statements, showing that 0xdbdbdbdb is everywhere

Comment 6

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

The fact that the script contains 0xdb means that it has been destroyed and poisoned (sounds very Shakespearean!). Since the first word is 100, it was destroyed by DestroyScriptFromGC. mxr isn't working for me, but I think fun_finalize and script_finalize are the two callers.

I'm noticing that when !cg->inFunction(), NewScriptFromCG creates a script object but doesn't save it anywhere. Could we be invoking a GC after this (perhaps in js_CallNewScriptHook?), causing the now-dead script object to be finalized?

Comment 7

[clever]

is there any ENV variable i can set to increase the GC debuging output?

Comment 8

[clever]

looks like its not limited to my 600mhz netbook, the core2duo just had the same fault
https://crash-stats.mozilla.com/report/index/bp-2d9a74aa-6d3b-4123-9869-273952110901

oddly, the crash address is 0xdbdbe3bb, half poison and half normal looking

Comment 9

[Jason Orendorff [:jorendorff]]

Hmmm. dbdbe3bb sounds like a witch's spell. Also Shakespearean.

Comment 10

[Jason Orendorff [:jorendorff]]

Thanks for the bug report, clever. I think this will be fixed in tomorrow's Nightly.

Here's what I think is happening: In JSScript::NewScriptFromCG, we call js_NewScriptObject, then js_CallNewScriptHook, then Debugger::onNewScript. The first completes the script, which makes it subject to GC. But at this point, the script is not rooted anywhere. Conservative stack scanning doesn't follow pointers to JSScripts from local variables--yet. So then we call js_CallNewScriptHook, which can trigger GC if you have a debugger installed. The next thing that touches the JSScript (in this case Debugger::onNewScript, but it could be anything) crashes. I introduced this GC hazard recently.

Igor's patch in bug 674251 should fix this. It makes the conservative stack scanner find the JSScript pointer and mark it. The patch is already on its way in. I don't know if it made the most recent Nightly, but it'll be in for tomorrow's Nightly unless it has tragic side effects of epic proportions and we have to back it out.

Comment 11

[clever]

seems like it has stopped occuring, i'll close the bug

Comment 12

[clever]

this is why i hate race conditions
nightly is still segfaulting at random, same backtrace

it also refuses to fault when i compile firefox with a patch to aid in debuging this

Comment 13

[Wayne Mery (:wsmwk)]

clever, can you still reproduce?

Comment 14

[clever]

i haven't had firebug enabled in months, and with a race condition like this, it may take another month to trigger it
i'll just close the ticket