Cm 2.0.3 crashes [@ objc_msgSend | -[NSWindow makeKeyWindow] ] with full-screen Flash and Exposé or window cycling; Take 2: Flash 10.1!

RESOLVED FIXED

Status

--
critical
RESOLVED FIXED
9 years ago
8 years ago

People

(Reporter: alqahira, Assigned: stuart.morgan+bugzilla)

Tracking

({crash})

1.9.0 Branch
x86
Mac OS X
crash
Bug Flags:
camino2.0.4 +

Details

(Whiteboard: [camino-2.0.4], crash signature, URL)

Attachments

(1 attachment)

fix
1.37 KB, patch
mikepinkerton
: superreview+
alqahira
: feedback+
Details | Diff | Splinter Review
Starting mid-cycle for 2.0.3, we're seeing new [@ objc_msgSend | -[NSWindow makeKeyWindow] ] crashes.  They're currently the #2 2.0.3 crash.

The signatures are the same or very similar to what we saw in bug 465178, except all (but one) of these crashes are with 10.1.something.

0  	libobjc.A.dylib  	objc_msgSend  	
1 	AppKit 	-[NSWindow makeKeyWindow] 	
2 	AppKit 	-[NSWindow makeKeyAndOrderFront:] 	
3 	Camino 	-[BrowserWindow makeKeyAndOrderFront:] 	mozilla/camino/src/browser/BrowserWindow.mm:66
4 	AppKit 	_prepareToRestore 	
5 	AppKit 	_NSRestoreFromDock 	
6 	AppKit 	_NSCoreDockMessageReceive 	

0  	libobjc.A.dylib  	objc_msgSend  	
1 	AppKit 	-[NSWindow makeKeyWindow] 	
2 	AppKit 	-[NSWindow _makeKeyRegardlessOfVisibility] 	
3 	AppKit 	-[NSWindow makeKeyAndOrderFront:] 	
4 	Camino 	-[BrowserWindow makeKeyAndOrderFront:] 	mozilla/camino/src/browser/BrowserWindow.mm:66
5 	AppKit 	_prepareToRestore 	
6 	AppKit 	_NSRestoreFromDock 	
7 	AppKit 	_NSCoreDockMessageReceive 	

There's also a crash that looks like

0  	libobjc.A.dylib  	objc_msgSend  	
1 	AppKit 	-[NSWindow makeKeyWindow] 	
2 	AppKit 	-[NSWindow _makeKeyRegardlessOfVisibility] 	
3 	AppKit 	-[NSWindow makeKeyAndOrderFront:] 	
4 	Camino 	-[BrowserWindow makeKeyAndOrderFront:] 	mozilla/camino/src/browser/BrowserWindow.mm:66
5 	AppKit 	-[NSApplication _cycleWindowsReversed:] 	
6 	AppKit 	_NSKeyboardUIHandleSymbolicHotKey 	
7 	AppKit 	-[NSApplication _handleKeyEquivalent:] 	
8 	AppKit 	-[NSApplication sendEvent:] 	
9 	AppKit 	-[NSApplication run] 	
10 	AppKit 	NSApplicationMain 	

that's slightly different, but it's using Cmd-` to cycle windows rather than Exposé.

There are also some comments mentioning sleeping the Mac or sleeping the display.

The vast majority of the crashes are with 10.1 "final" (aka rc7) or 10.1rc2.  There are also a few with Gala Preview 2, and one each with Gala Preview 1, 10.1rc4, and some version that no-one has ever seen before (module id: A761C9FCC2551568696107F1811B8F010).  All are Intel, mostly 10.6 or 10.5, but 2 10.4, too.

I can easily repro either Exposé Show All Windows + click on origin window or Cmd-` with 2.0.3, but not at all with 2.1a1pre (I suspect Core focus changes changed something yet again?) using the URL in the location field.

STR:

1) Load http://www.fastcashphoto.com/2010/06/final-cut-pro-7-unscripted-using-alpha-transitions/

2) Make the video full-screen

3a) Exposé "Show All Windows" and click on the original window, OR
3b) Cmd-` to cycle windows.

4) BOOM!
Flags: camino2.0.4?
To summarize from irc:  

With Flash 10.1, it's now a FP_FPWindow that's being deallocated too early, per zombies (-[FP_FPWindow _setFrameNeedsDisplay:]: message sent to deallocated instance 0x12a7ff10), and also checking for that window class in the work-around for bug 465178 seems to stop the crashing.  Stuart says the real fix would be a bit more complex, though.
(Assignee)

Comment 2

9 years ago
The "slightly more complex" part is that I don't think we want to pass nil into isMemberOfClass, so we need to do the string-to-class lookup and check the return before using it.
(Assignee)

Updated

9 years ago
Flags: camino2.0.4? → camino2.0.4+
(Assignee)

Comment 3

9 years ago
Created attachment 456524 [details] [diff] [review]
fix

I don't have a 2.0 tree post-hard-drive-death; can you take this for a spin to make sure I didn't botch it?
Assignee: nobody → stuart.morgan+bugzilla
Status: NEW → ASSIGNED
Attachment #456524 - Flags: feedback?(alqahira)
Comment on attachment 456524 [details] [diff] [review]
fix

f+; I can Exposé and cycle windows with impunity.  Sometime please explain to me why we don't need the more complex method for NSCarbonWindow, too, though.
Attachment #456524 - Flags: feedback?(alqahira) → feedback+
(Assignee)

Comment 5

9 years ago
NSCarbonWindow is a core system class, so it'll always be there. (I guess for future-proofing we could do the same check in case it changes in 10.x, since it's not public, but we'd have plenty of time to find that out). This string is only going to resolve to a class if a version of Flash with that class in it has been loaded, which is a whole lot less dependable.
(Assignee)

Updated

9 years ago
Attachment #456524 - Flags: superreview?(mikepinkerton)
Comment on attachment 456524 [details] [diff] [review]
fix

suck. sr=pink.
Attachment #456524 - Flags: superreview?(mikepinkerton) → superreview+
Stuart, I assume we want this on 1.9.2 even though the crash appears not to happen there, just in case the focus code changes under us?  It won't hurt any more than the code to stop the 10.0 crashes does, which appears to be "not at all", right?

Landed on CAMINO_2_0_BRANCH for Stuart in advance of 2.0.4; leaving open pending an answer to the previous question, though.
Whiteboard: [camino-2.0.4]
(Assignee)

Comment 8

8 years ago
It won't hurt, but since it's an ugly hack I'd rather we not carry it forward until/unless we have evidence that it's actually necessary.
OK, then FIXED it is!

I guess that also means we should test Flash 10.0 and see if we can remove that part of the hack from 2.1?
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

8 years ago
Couldn't hurt (although I'd be happy just pulling the code regardless; nobody running 2.1 should still be running 10.0)
(In reply to comment #10)
> Couldn't hurt (although I'd be happy just pulling the code regardless; nobody
> running 2.1 should still be running 10.0)

Since we left this thread hanging, the removal happened in bug 583187.

-------------------------

There are also two reports of this crash with 2.0.5 and Flash 10.2:
bp-dc24eb30-f0b6-4709-8b4c-594a32101113 (Preview 1 and 10.5.8)
bp-76cac4c3-9a4c-4503-8185-2343b2101109 (Preview 2 and 10.6.4)

I can't reproduce the crash with 10.2 using the normal steps, so either there's a new STR or a new edge case, or some new condition to trigger that I don't meet.  We should keep an eye on it, but hopefully we can get 2.1 out before 10.2 ;)
Crash Signature: [@ objc_msgSend | -[NSWindow makeKeyWindow] ]
You need to log in before you can comment on or make changes to this bug.