Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090407 Shiretoko/3.5b4pre ID:20090407031108 I noticed this crash while I wanted to verify bug 481382 on trunk. Changing the system appearance to graphite or back to blue always crashes Shiretoko. This crash doesn't happen with Minefield so far. It was working before, so it has to be regressed in the last month or so. Right now, I haven't found another bug which handles the same stacks. I say stacks because they differ a bit. Switching to graphite gives another signature as when switching to blue. To graphite: bp-cc3e0dd6-9fa3-419a-9252-cbadb2090408 0 @0x80000020 1 Foundation Foundation@0x9f1b 2 CoreFoundation CoreFoundation@0x548d9 3 CoreFoundation CoreFoundation@0x54bb2 4 Foundation Foundation@0x707f 5 Foundation Foundation@0x108c7 6 AppKit AppKit@0x424e34 7 AppKit AppKit@0x3a4dee 8 Foundation Foundation@0x9f1b 9 CoreFoundation CoreFoundation@0x548d9 10 CoreFoundation CoreFoundation@0x54bb2 11 CoreFoundation CoreFoundation@0x54ea7 12 CoreFoundation CoreFoundation@0x5461a 13 CoreFoundation CoreFoundation@0x5470d 14 CoreFoundation CoreFoundation@0x4f454 15 CoreFoundation CoreFoundation@0x738e7 16 CoreFoundation CoreFoundation@0x73cd7 17 HIToolbox HIToolbox@0x302bf 18 HIToolbox HIToolbox@0x300d8 19 HIToolbox HIToolbox@0x2ff4c 20 AppKit AppKit@0x40d7c 21 AppKit AppKit@0x4062f 22 AppKit AppKit@0x3966a 23 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:716 24 XUL nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:192 25 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3279 26 firefox-bin main browser/app/nsBrowserApp.cpp:156 27 firefox-bin firefox-bin@0x1541 28 firefox-bin firefox-bin@0x1468 29 @0x2 To blue: bp-6d7c9ca7-f080-4e60-9fbc-d29352090408 0 XUL -[ChildView systemMetricsChanged] nsCOMPtr.h:554 1 Foundation Foundation@0x9f1b 2 CoreFoundation CoreFoundation@0x548d9 3 CoreFoundation CoreFoundation@0x54bb2 4 Foundation Foundation@0x707f 5 Foundation Foundation@0x108c7 6 AppKit AppKit@0x424e34 7 AppKit AppKit@0x3a4dee 8 Foundation Foundation@0x9f1b 9 CoreFoundation CoreFoundation@0x548d9 10 CoreFoundation CoreFoundation@0x54bb2 11 CoreFoundation CoreFoundation@0x54ea7 12 CoreFoundation CoreFoundation@0x5461a 13 CoreFoundation CoreFoundation@0x5470d 14 CoreFoundation CoreFoundation@0x4f454 15 CoreFoundation CoreFoundation@0x738e7 16 CoreFoundation CoreFoundation@0x73cd7 17 HIToolbox HIToolbox@0x302bf 18 HIToolbox HIToolbox@0x300d8 19 HIToolbox HIToolbox@0x2ff4c 20 AppKit AppKit@0x40d7c 21 AppKit AppKit@0x4062f 22 AppKit AppKit@0x3966a 23 XUL nsAppShell::Run widget/src/cocoa/nsAppShell.mm:716 24 XUL nsAppStartup::Run toolkit/components/startup/src/nsAppStartup.cpp:192 25 XUL XRE_main toolkit/xre/nsAppRunner.cpp:3279 26 firefox-bin main browser/app/nsBrowserApp.cpp:156 27 firefox-bin firefox-bin@0x1541 28 firefox-bin firefox-bin@0x1468 29 @0x1

changing the system appearance is uncommon enough that I don't think this needs to block.

I can't reproduce the crash with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b4pre) Gecko/20090413 Shiretoko/3.5b4pre. I haven't tried other versions.

Yes, somehow this was getting fixed by an unknown checkin. You should use the above mentioned build to see Firefox crashing. Unless we do not know which bug fixed this one too, I'll resolve it as WFM.

It's back with the latest nightly on 1.9.1: bp-2f0d3aae-bb75-4e29-b6e9-05dd52090417

I've identified this crash. The cause was the last release of Firebug. Upgrading to 1.4X.0a19 fixes the crash.

(In reply to comment #5) > I've identified this crash. The cause was the last release of Firebug. Sorry, this is incorrect. Lucky us, we cannot crash Firefox. Firebug can take code paths or set state that Firefox is not expecting, that Firefox test suite does not cover etc. But as pure JS code Firebug cannot, as a matter of design, cause Firefox to crash. > Upgrading to 1.4X.0a19 fixes the crash. This would be more like "does not (yet) trip the bug that crashes Firefox".

Henrik: Tell me which version(s) of Firebug trigger this crash, and I'll look into it further. John, can I download old versions of Firebug? If so, where do I find them?

(In reply to comment #7) > John, can I download old versions of Firebug? If so, where do I find > them? http://getfirebug.com/releases/firebug

(In reply to comment #7) > Henrik: Tell me which version(s) of Firebug trigger this crash, and > I'll look into it further. I had installed http://getfirebug.com/releases/firebug/1.4X/firebug-1.4X.0a18.xpi. But even with a backup of my daily profile it doesn't crash right now. When I've reopened this bug today it crashes each time I have switched the system settings. Even after a restart the same crash happened. But after upgrading to a19 the crash was gone. So I thought it could be initiated by Firebug. But I was wrong. Thanks John. I don't have steps so far. > > John, can I download old versions of Firebug? If so, where do I find > them?

Ok, now I have downgraded from a19 to a18 and the crash happens again. Seems like Firebug is somehow involved but the reason is another extension? I'll try to find out the combination. Lets reopen for now.

With 1.4X you can try to set pref extensions.firebug-tracing-service.toOSConsole then run from the OS Console. In Firebug open the Firebug Icon Menu "Tracing". In the Options tab set ERRORS and FBS_ERRORS. If you see output in the os console at the crash you may get some hints if any JS is involved. (Of course this may cause the crash to not happen). You can also set all the options ON once to see if anything can be learned.

Ok, I was able to trim it down. Here is a minimized profile. Do the following steps to reproduce: 1. Create a fresh profile 2. Immediately exit Firefox and replace the files in the new profile with the ones from the attached archive 3. Start Firefox with the new profile 4. Open appearance settings 5. Switch to Blue/Graphite a couple of times At least after 5-10 times to crash should happen.

Somehow this only happens when Firebug 1.4X.0a18 and Update Notifier 0.1.5.4 is installed. The latter one is not compatible with Firefox 3.1. The given profile contains both add-ons and the Nightly tester tools installed.

Thanks, Henrik. I can now reproduce your crash. Here are two crashlogs made in gdb using an opt build of Shiretoko with debug symbols (code pulled today). I suspect this crash also happens on the trunk and the 1.9.0 branch. All I needed to do is change the Appearance (in the system Appearance panel) from blue to graphite (or from graphite to blue) and focus a browser window (either by clicking on it or by dismissing the Appearance panel). Like you, I only need to have Firebug and Update Notifier installed to see the crash. I think it's probably triggered by the little button Update Notifier adds to the upper left part of the browser window (near the Close, Minimize and Zoom buttons). The crashes don't happen if you disable Update Notifier (which makes the button disappear), or if no updates are available (which makes the button the same color as the titlebar on which it sits).

So its a crash which is caused by an add-on but we fail on the back-end part? Means we should/can fix it? I think yes when having a look at the assignee now.

I wonder if there's some new theming code related to graphite desktop appearance. If the button creates a halo when it's focused, it might be getting confused about which color to use. Might be some something related to: https://bugzilla.mozilla.org/show_bug.cgi?id=448767 and/or https://bugzilla.mozilla.org/show_bug.cgi?id=481382

I suspect this is a straight Cocoa widgets bug -- the crashes happen on access to a deleted nsChildView object (stored in a ChildView object's mGeckoChild variable). But I'm still trying to figure out how on earth this could be happening :-)

Steven: When you get a chance (no hurry, really), do let us know if this crash happens on 1.9.0 as well.

This bug's particular crash only happens on the 1.9.1 branch -- not on the trunk and not on the 1.9.0 branch. But that's an accident: The underlying cause exists on the trunk and both branches. Yes, I've figured this bug out. It's exceedingly twisted and arcane. But it'd take me another couple of hours to dot the 'i's and cross the 't's. And it's late, and I want to go to bed :-) So the patch (and my explanation) will have to wait til Monday. I'm pretty sure, though, that this *isn't* a common crash.

Ok, I got the regression range now. This crash has been regressed between the builds 08091702 and 08091802. There is only one checkin in this timeframe which could have been caused this bug. It's the "Make -moz-system-metric(mac-graphite-theme) live" in bug 448767. The patch on this bug went in for FF3.1b1 so there have been a further patch on trunk which prevents this crash there.

(In reply to comment #19) > This bug's particular crash only happens on the 1.9.1 branch -- not on > the trunk and not on the 1.9.0 branch. That's not true as what I can see now. It still crashes on trunk but you missed probably the same thing as I did until some minutes ago. Both add-ons gets deactivated when running my attached profile with a recent nightly build. Override the compatibility and restart Firefox. Afterward it still crashes. So given by bug 448767 it was checked into 1.9.1 but will never go into 1.9.0. So the crash will not happen on 1.9.0 at any time.

Here's a 1.9.1-branch patch (and tryserver build) that fixes the underlying cause of this bug. A mozilla-central patch will follow shortly. https://build.mozilla.org/tryserver-builds/2009-04-20_10:25-smichaud@pobox.com-bugzilla487393-191branch/smichaud@pobox.com-bugzilla487393-191branch-firefox-try-mac.dmg As you can see from the patch, this should probably also be landed on the 1.9.0 branch at some point, after baking on the trunk and 1.9.1 branches. I'm not sure if it will actually fix any crashes on the 1.9.0 branch, but the problem is deep-seated (and scary) enough to merit fixing on general principles. Short description of problem: Code in the nsCocoaWindow destructor assumes that all its children will be nsCocoaWindow objects, static_casts each child to an nsCocoaWindow object and sets nsCocoaWindow->mParent to nsnull. But this isn't true -- for example a tooltip window (a kind of popup window) has at least one child that's an nsChildView object. It's easy to see how this can cause serious trouble. In fact I wonder why we haven't tripped over it before now :-) Chain of events that leads to this bug's crash: 1) As the browser starts up, the Update Notifier tries to display a tooltip (which never actually gets displayed). This triggers the creation of a popup window (an nsCocoaWindow object whose corresponding native window is a PopupWindow object) and its child (an nsChildView object whose corresponding native view is a ChildView object). As the ChildView object is created (in [ChildView initWithFrame:...]), it gets registered to receive AppleAquaScrollBarVariantChanged messages (at its systemMetricsChanged method). 2) 5-10 seconds after its creation, the nsCocoaWindow object from step 1 is destroyed without ever having been displayed. The nsCocoaWindow destructor misinterprets the pointer to its child (which is an nsChildView object) as another nsCocoaWindow object, and tries to null out the child's mParent variable. What actually happens is that the child's mView variable gets nulled out. 3) The tooltip's nsChildView object object (child of its nsCocoaWindow object) is destroyed and nsChildView::TearDownView() gets called on it. But because mView is already null, the ChildView object corresponding to this nsChildView object doesn't get destroyed, and stays registered to receive AppleAquaScrollBarVariantChanged messages. And the ChildView object's widgetDestroyed method never gets called (which prevents its mGeckoChild variable from getting nulled, even though it's now invalid). 4) The user changes the system appearance from blue to graphite (or vice versa). This causes an AppleAquaScrollBarVariantChanged message to be sent to all registered objects -- including our ChildView object whose corresponding nsChildView object has been destroyed, and whose mGeckoChild variable is an invalid pointer. 5) The invalid mGeckoChild variable gets accessed in [ChildView systemMetricsChanged] -- which causes this bug's crash.

A tryserver build for this patch will follow eventually.

Here's a tryserver build for my trunk patch: https://build.mozilla.org/tryserver-builds/2009-04-20_12:39-smichaud@pobox.com-bugzilla487393/smichaud@pobox.com-bugzilla487393-firefox-try-mac.dmg

Steven, I tried to check your tryserver builds but with todays builds I'm even not able to reproduce the crash. We would need a more reliable testcase. :/

Henrik, I can easily reproduce the crash with today's Shiretoko nightly, using your STR from comment #12.

Landed on trunk: http://hg.mozilla.org/mozilla-central/rev/92941f213546 I'll let this bake a while (a week?) before trying to get it landed on the 1.9.1 branch.

i think we can close it now as fixed.

Right (sorry, I just forgot to mark it FIXED).

This is ready to land on 1.9.1 right? It needs to land ASAP if it's going to make it.

Sorry, forgot about this. Yes, it was ready to go. I just landed it: http://hg.mozilla.org/releases/mozilla-1.9.1/rev/ac87562f14b5

From comment #22: > As you can see from the patch, this should probably also be landed > on the 1.9.0 branch at some point, after baking on the trunk and > 1.9.1 branches. I'm not sure if it will actually fix any crashes on > the 1.9.0 branch, but the problem is deep-seated (and scary) enough > to merit fixing on general principles. So I'm asking if this is wanted on the 1.9.0 branch.

I'm not able to crash the following builds anymore when switching the system appearance. Looks great. Thanks Steven! Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2a1pre) Gecko/20090517 Minefield/3.6a1pre ID:20090517031025 Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b5pre) Gecko/20090517 Shiretoko/3.5b5pre ID:20090517031745

Even though this bug's STR doesn't work on the 1.9.0 branch, the underlying cause of this bug does exist there. And how we may have additional reason to land a version of this patch on the 1.9.0 branch (as revised by my patch for bug 503196). See bug 457337 comment #9. I'll post a 1.9.0-branch patch early next week.