Closed Bug 663691 Opened 15 years ago Closed 8 years ago

dead script in list of scripts per compartment (hit during Compartment::purge)

Categories

(Core :: XPConnect, defect)

Product:
Core
Component:
XPConnect
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

()

Status:
RESOLVED INACTIVE
Tracking Flags:
Tracking Status
firefox5 - ---
firefox6 - ---

People

(Reporter: scoobidiver, Unassigned)

References

Details

(Keywords: crash)

Crash Data

It is #48 top browser crasher in 4.0.1, #12 in 5.0b3, #15 in 6.0a2 on Mac OS X. Some comments say: "Reducing screen size to make a small window " "I quit firefox with command-q and it said that it had crashed." "Keeps crashing on the CNET site" Signature JSCompartment::purge UUID 11e165b7-fc55-41d4-8be0-91d8c2110611 Date Processed 2011-06-11 05:56:00.702344 Uptime 1419 Last Crash 11565023 seconds (more than 3 months) before submission Install Age 51651 seconds (14.3 hours) since version was first installed. Install Time 2011-06-10 22:34:45 Product Firefox Version 5.0 Build ID 20110608151458 Release Channel beta Branch 2.2 OS Mac OS X OS Version 10.7.0 11A480b CPU amd64 CPU Info family 6 model 23 stepping 10 Crash Reason EXC_BAD_ACCESS / KERN_INVALID_ADDRESS Crash Address 0x7865550d App Notes Renderers: 0x22600,0x20400GL Context? GL Context+ GL Layers? GL Layers+ Frame Module Signature [Expand] Source 0 XUL JSCompartment::purge js/src/jsscript.h:515 1 XUL js_GC js/src/jsgc.cpp:2156 2 XUL nsXPConnect::Collect js/src/xpconnect/src/nsXPConnect.cpp:405 3 XUL nsXPConnect::GarbageCollect js/src/xpconnect/src/nsXPConnect.cpp:413 4 XUL nsTimerImpl::Fire xpcom/threads/nsTimerImpl.cpp:424 5 XUL nsTimerEvent::Run xpcom/threads/nsTimerImpl.cpp:520 6 XUL nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:618 7 XUL NS_ProcessPendingEvents_P nsThreadUtils.cpp:200 8 XUL nsBaseAppShell::NativeEventCallback widget/src/xpwidgets/nsBaseAppShell.cpp:130 9 XUL nsAppShell::ProcessGeckoEvents widget/src/cocoa/nsAppShell.mm:399 10 CoreFoundation CoreFoundation@0x12590 11 CoreFoundation CoreFoundation@0x11dfc 12 CoreFoundation CoreFoundation@0x38aa8 13 libsystem_c.dylib libsystem_c.dylib@0xa03c7 14 libsystem_c.dylib libsystem_c.dylib@0x4d15f More reports at: https://crash-stats.mozilla.com/report/list?signature=JSCompartment%3A%3Apurge
These crashes are mostly 10.7, but there are a few 10.6.7 crashes sprinkled in as well.
Lion specific crash in GC/compartments? Andreas/Dave, how do we feel about this?
Based on Comment 3, adding that signature to crash signature field. Extension correlations for the Windows crash signature don't have anything higher than 29%, which in this case is the Java console.
Crash Signature: [@ JSCompartment::purge ] → [@ JSCompartment::purge ] [@ JSCompartment::purge(JSContext*) ]
We aren't going to specifically track this for 5 or 6 but the crash-stats team will be watching it closely
tracking-firefox5: ? → -
tracking-firefox6: ? → -
JSCompartment::purge(JSContext*) has 758 crashes in the last week across all versions. JSCompartment::purge has 170 mac and 3 Linux crashes last week across all versions.
It is not specific to Mac OS X, so I renamed the bug summary, changed the platform. But 98% of crashes on Mac happen on Mac OS X 10.7 Lion and it is #12 top browser crasher on Mac OS X while the Windows crash is only #140 top browser crasher.
OS: Mac OS X → All
Hardware: x86_64 → All
Summary: Crash [@ JSCompartment::purge ] on Mac OS X 10.7 Lion → Crash in JSCompartment::purge almost only on Mac OS X 10.7 "Lion" for Mac
Windows version has 844 crashes in the last week. The Mac specific crash has 183 crashes which are almost all 10.7 users. Would be interesting to probe why it is happening more often on 10.7 then 10.6.
Adding Steven for the 10.7 part, but I'd really like to see someone on the JS team take a look.
The ability to link from the stack directly to the source line seems to have been lost.
Digging up the source by hand: (someone please double check that I found the right revision). 2152 if (rt->gcCurrentCompartment) { 2153 rt->gcCurrentCompartment->purge(cx); 2154 } else { 2155 for (JSCompartment **c = rt->compartments.begin(); c != rt->compartments.end(); ++c) >>2156 (*c)->purge(cx); 2157 }
The crash is reported here: 514 bool hasJITCode() { >> 515 return jitNormal || jitCtor; 516 } This code is inlined and doesn't appear in the stack: #ifdef JS_METHODJIT for (JSScript *script = (JSScript *)scripts.next; &script->links != &scripts; script = (JSScript *)script->links.next) { >>> if (script->hasJITCode()) { # if defined JS_POLYIC mjit::ic::PurgePICs(cx, script); # endif # if defined JS_MONOIC if (cx->runtime->gcRegenShapes) mjit::ic::PurgeMICs(cx, script); # endif } } #endif
Looks like we have a script on that list that has been already GCed. Scripts are these weird things we allocate from the heap using malloc, but we use a JSObject to keep them alive. If we stash a script pointer in the heap without also keeping the JSObject rooted, we die. As for why 10.7 is crashing more frequently, 10.7 might have a new and better malloc implementation that is more aggressive about unmapping memory if a bunch of nearby frees happen, which is more likely to reveal this bug via a segfault.
Summary: Crash in JSCompartment::purge almost only on Mac OS X 10.7 "Lion" for Mac → dead script in list of scripts per compartment (hit during Compartment::purge)
The reason for the disproportionate number of these crashes on OS X 10.7 may be bug 663688, which (apparently) causes heap corruption and triggers many different kinds of seemingly unrelated crashes. For what it's worth, crash-stats doesn't have any record of this bug's crashes happening on builds that contain one of the workarounds for bug 663688.
Besides what Andreas found, I've noticed that a lot of GC marking crashes seem to happen with js_TraceScript near the top of the stack. This also suggests that scripts are getting GCed before their time. If it's a rooting bug, I think bug 662646 has a shot at discovering it. I'm planning to land that on trunk tomorrow. Looking at crash-stats, we seem to get about one Windows crash a day on nightlies, so we'll be able to get some data soon.
The instrumentation in bug 662646 has landed, and there has been one Windows crash of this kind so far. Strangely, we crash during the browser's first GC. I'm pretty sure this is correct; the uptime was only 12 seconds, so it makes sense. This seems to disprove the hypothesis that we accidentally GCed a reachable script, since we crash during compartment purging, which happens at the beginning of the GC. Somehow, we must be ending up with a bad script by some other means. The crash addresses are also strange. They're often either -1 or 0. So the problem is not that we're dereferencing freed memory. Perhaps we somehow hit a freed script, and its next pointer is -1 or 0, and we crash when we get to that one?
Depends on: 670702
removing blocking dependency on bug 636455 since there are no reports in the last 4 weeks with a Firefox version greater the 14.0.1
No longer blocks: lion-compatibility
Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.