Closed Bug 487393 Opened 11 years ago Closed 11 years ago

Changing system appearance to blue/graphite crashes browser [@ systemMetricsChanged][@ Foundation@0x9f1b]

Categories

(Core :: Widget: Cocoa, defect, critical)

All
macOS
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: whimboo, Assigned: smichaud)

References

Details

(Keywords: crash, regression, verified1.9.1, Whiteboard: [needs baking on 1.9.1-branch])

Crash Data

Attachments

(4 files)

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
Flags: blocking1.9.1?
changing the system appearance is uncommon enough that I don't think this needs to block.
Flags: wanted1.9.1+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
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.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
It's back with the latest nightly on 1.9.1: bp-2f0d3aae-bb75-4e29-b6e9-05dd52090417
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Status: REOPENED → NEW
I've identified this crash. The cause was the last release of Firebug. Upgrading to 1.4X.0a19 fixes the crash.
Status: NEW → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → INVALID
(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.
Status: RESOLVED → REOPENED
Resolution: INVALID → ---
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.
Attached file Profile
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).
Assignee: nobody → smichaud
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.
Status: REOPENED → ASSIGNED
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.
Flags: wanted1.9.0.x?
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.
Blocks: 448767
(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.
Flags: wanted1.9.0.x?
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.
Attachment #373724 - Flags: review?(joshmoz)
Attached patch Trunk patchSplinter Review
A tryserver build for this patch will follow eventually.
Attachment #373725 - Flags: review?(joshmoz)
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.
Attachment #373725 - Flags: review?(joshmoz) → review+
Attachment #373724 - Flags: review?(joshmoz) → review+
Attachment #373724 - Flags: superreview?(roc)
Attachment #373725 - Flags: superreview?(roc)
Attachment #373725 - Flags: superreview?(roc) → superreview+
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.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Whiteboard: [needs baking on trunk]
Target Milestone: --- → mozilla1.9.2a1
Right (sorry, I just forgot to mark it FIXED).
Attachment #373724 - Flags: superreview?(roc) → superreview+
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
Keywords: fixed1.9.1
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.
Flags: wanted1.9.0.x?
Whiteboard: [needs baking on trunk] → [needs baking on 1.9.1-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
Status: RESOLVED → VERIFIED
Hardware: x86 → All
Version: 1.9.1 Branch → Trunk
Depends on: 503196
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.
Crash Signature: [@ systemMetricsChanged] [@ Foundation@0x9f1b]
You need to log in before you can comment on or make changes to this bug.