631105 - crash [@ js_DestroyScriptsToGC]

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[Daniel Veditz [:dveditz]]

This bug was filed from the Socorro interface and is 
report bp-03952eea-24b8-42ee-a210-3df772110130 .
============================================================= 

This is a new signature that has only been seen in Firefox 3.6.14 beta builds, and it's jumped to our #2 crash

https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox%3A3.6.14&query_search=signature&query_type=exact&query=js_DestroyScriptsToGC&date=now&range_value=2&range_unit=weeks&process_type=any&do_query=1&admin=&signature=js_DestroyScriptsToGC

Comment 1

[Daniel Veditz [:dveditz]]

Igor changed js_DestroyScriptsToGC in bug 599610 so let's start there.

Comment 2

[Igor Bukanov]

Most bug reports shows a read access violation at addresses around 0x93f0. The code in js_DestroyScriptToGC accesses a field which is at 0x10914 offset from the start of the JSThread structure. So it could be a null-pointer that is passed for JSThread. But then it is not clear why the address is 28K less than the field offset.

Comment 3

[Igor Bukanov]

(In reply to comment #2)
> So it could be a null-pointer that is passed for JSThread. 

It cannot be so - the stack traces shows that js_DestroyScriptsToGC is called from PurgeThreadData which reads/writes from JThread before calling js_DestroyScriptsToGC.

Comment 4

[Igor Bukanov]

I have not found so far what could have caused the bug.

Comment 6

[Daniel Veditz [:dveditz]]

This definitely spiked in 3.6.14, but I was incorrect to say it's a new signature (new on the top-300 list, I guess). We saw some of these in 3.6.13 as well, although with a hundred million more users than the 3.6.14 betas the absolute numbers of crashes was less. Oddly we're seeing some Mac crashes, but they're almost all using 3.6.3.  Perhaps the patch in bug 599610 isn't where the bug is, but it's greatly increased the odds of triggering a pre-existing condition that occasionally zapped users of earlier builds.

Hopefully more useful crash-stats link than the one in comment 0:
https://crash-stats.mozilla.com/report/list?product=Firefox&version=Firefox&query_search=signature&query_type=exact&query=js_DestroyScriptsToGC&date=02%2F07%2F2011%2010%3A10%3A15&range_value=2&range_unit=weeks&hang_type=any&process_type=any&plugin_field=&plugin_query_type=&plugin_query=&do_query=1&admin=&signature=js_DestroyScriptsToGC

Comment 7

[Daniel Veditz [:dveditz]]

This crash spike, like bug 633869, appears to be due to frankenbuilds. Bug 599610 was almost certainly not a cause, and backing it out merely moved the crash around.

We're not seeing this crash anymore in build2 so might as well close the bug "FIXED" and work on the frankenbuild issue in the other bug.

Comment 8

[Ludovic Hirlimann [:Usul]]

This looks like a to crasher for thunderbird updates. Shall I reopen this bug or create a new one ?

Comment 9

[Ludovic Hirlimann [:Usul]]

https://crash-stats.mozilla.com/report/list?range_value=2&range_unit=weeks&signature=js_DestroyScriptsToGC&version=Thunderbird%3A3.1.8

Comment 10

[Wayne Mery (:wsmwk)]

something very bad here, whether this reopens or a new bug is filed, it's certainly a runaway crash for Thunderbird 3.1.8 perhaps worthy of a respin.

#3 crash for FF 3.6.14. not even in the top 300 for 3.6.13
All are startup crashes for both FF and TB.

Comment 11

[Mark Banner (:standard8)]

This is a side effect of frankenbuilds, bug 634343 is watching this.

Comment 12

[Wayne Mery (:wsmwk)]

thunderbird 3.1.9 - banished to rank #238
Firefox 3.6.15 - not even in top 300