Closed Bug 631105 Opened 11 years ago Closed 11 years ago

crash [@ js_DestroyScriptsToGC]

Categories

(Core :: JavaScript Engine, defect)

1.9.2 Branch
x86
Windows NT
defect
Not set
critical

Tracking

()

VERIFIED FIXED
Tracking Status
blocking1.9.2 --- .14+
status1.9.2 --- wanted

People

(Reporter: dveditz, Assigned: igor)

References

Details

(Keywords: crash, regression)

Crash Data

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
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general
Version: 3.6 Branch → 1.9.2 Branch
Igor changed js_DestroyScriptsToGC in bug 599610 so let's start there.
Assignee: general → igor
Blocks: 599610
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.
(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.
blocking1.9.2: ? → .14+
I have not found so far what could have caused the bug.
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
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
This looks like a to crasher for thunderbird updates. Shall I reopen this bug or create a new one ?
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.
This is a side effect of frankenbuilds, bug 634343 is watching this.
thunderbird 3.1.9 - banished to rank #238
Firefox 3.6.15 - not even in top 300
Status: RESOLVED → VERIFIED
Crash Signature: [@ js_DestroyScriptsToGC]
You need to log in before you can comment on or make changes to this bug.