Closed Bug 631105 Opened 11 years ago Closed 11 years ago

crash [@ js_DestroyScriptsToGC]


(Core :: JavaScript Engine, defect)

1.9.2 Branch
Windows NT
Not set



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


(Reporter: dveditz, Assigned: igor)



(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
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:
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.
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
Crash Signature: [@ js_DestroyScriptsToGC]
You need to log in before you can comment on or make changes to this bug.