511671 - QuakeLive plugin crashes browser when opening a game window [@ nsPurpleBuffer::Put]

Status: RESOLVED INVALID

(Core :: Widget: Cocoa, defect)

Description

[Timothee Besset]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.0.13) Gecko/2009082005 Iceweasel/3.0.12 (Debian-3.0.12-1)
Build Identifier: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1.2) Gecko/20090729 Firefox/3.5.2

The QuakeLive plugin opens a render window when a player wants to connect to a server. This is done from a thread that is specific to the plugin, but runs in the same process as the browser overall. While this works fine on Safari we are seeing this crash on FireFox.

We think this is because FireFox tries to do things with that Window when it really shouldn't, as that Window really is unrelated to the browser.

We have created a specific account that can be used to logon to the site and bypass the user agent check, as we currently refuse FF 3.5.x on Mac since we know it will be crashing. We can provide that account information outside of the ticket tracking.


Reproducible: Always

Steps to Reproduce:
1. Logon to http://www.quakelive.com/ with FireFox 3.5.x on a Mac (Intel OSX 10.5 used here), using the moztest account

2. Install plugin if needed / wait through the content download until you can get to the server list.

3. Connect to an online server, or start a practice game.

Actual Results:  
Crash. I've seen it not crash sometimes, in which case you can just exit out of the game and try again, then it will crash. Not 100% but very, very close.


Expected Results:  
Game window opens, plugin connects to the game successfully.


Going to upload backtrace, and code sample of the window creation.

Comment 1

[Timothee Besset]

Attachment: backtrace

Comment 2

[Timothee Besset]

Attachment: window init code sample

This code runs in the plugin's thread, in the browser process. We use the same basic architecture on all operating systems, OSX FireFox is the only one on which we have the crash.

Comment 3

[Steven Michaud [:smichaud] (Retired)]

I suspect most of the symbols in this stack trace are spurious.

To get a good stack trace (that's not a Breakpad stack trace), you
need to generate it using a copy of FF that you've built yourself --
either a debug build (which is easiest) or an optimized build with
debug symbols.

Comment 4

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Steven, I will take care of it and check it in the next hours. I will report back.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

Thanks, Henrik!

Comment 6

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Confirmed for now with a debug build. Because we are accessing an invalid address lets close this bug.

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x414b07f3
0x1cc74703 in ?? ()

I'll attach a complete gdb stack in a moment.

Comment 7

[Henrik Skupin [:whimboo][⌚️UTC+1]]

This bug is closed for the public so I will put the login credentials in so devs will have a chance to get it in their debugger and to fix this crash:

email = [e-mail]
password = m0zt3st

Comment 8

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Attachment: gdb stack

Just a note beside. I was not able to crash Firefox 3.5.2 on OS X 10.5.8 but my Shiretoko debug build crashed.

Comment 9

[Henrik Skupin [:whimboo][⌚️UTC+1]]

I missed the first lines in the stack. Given by the output below the crashing thread is not the main thread?

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_PROTECTION_FAILURE at address: 0x12e2f318
[Switching to process 90019 thread 0xa22b]
0x00592ee6 in nsPurpleBuffer::Put (this=0x100e660, p=0x1cc2b918) at /data/build/shiretoko/xpcom/base/nsCycleCollector.cpp:767
767	        e->mObject = p;

Comment 10

[Timothee Besset]

Correct, the plugin starts it's own thread and creates a render window out of that thread (comment #2). Notifications for Windows that don't actually belong to the browser should be ignored?

Comment 11

[Benjamin Smedberg]

Creating a toplevel window from a plugin is already dangerous enough... doing it from another thread is thoroughly unsupported.

Comment 12

[Steven Michaud [:smichaud] (Retired)]

I was also going to complain about calling Cocoa display methods on a secondary thread ... but you guys beat me to it.

Timothee, it's now clear that the QuakeLive plugin is at fault here.  It shouldn't call Cocoa display methods on anything but the main thread, or cause them to be called on anything but the main thread.

Comment 13

[Timothee Besset]

We can try creating the Window from the main thread and passing it over to the plugin thread.

FWIW this current approach of creating the window in a seperate thread works fine on Windows (FF and IE), Linux (FF) and Mac (Safari). It seems to me the browser catching that Window through a Cocoa notification mechanism and not realizing it should ignore it is a bit of the issue there.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

So the "window init sample code" runs on a secondary thread (one created by the plugin)?

I don't know how you're able to get away with this in Safari.  But I do know (from personal experience) that Safari does a lot of things on secondary threads (like loading Java applets) that other browsers do on the main thread.  And Safari developers (of course) know a lot more about undocumented OS X internals than outsiders do.

Comment 15

[Henrik Skupin [:whimboo][⌚️UTC+1]]

(In reply to comment #13)
> FWIW this current approach of creating the window in a seperate thread works
> fine on Windows (FF and IE), Linux (FF) and Mac (Safari). It seems to me the

For me the final game window doesn't open in it's own window on Windows. I believe the same applies to Linux (where I haven't tested it)?

Comment 16

[Timothee Besset]

Yes, we have seamless window mode integration working on Windows and Linux, but not on Mac.

At this point on Mac we are not able to reliably open a render Window embedded in the browser (including following the browser when it's moving, supporting resizing and having a correct drawing order). We also need full keyboard and mouse grab since we're heavily interactive.

We have some pieces of the embedding working, but not reliably enough to enable it in a public release. We have started discussions with Apple on this, and we'd be happy to investigate this with you as well. We know Java applets are getting the embedding and interaction right so there should be a way to get this working for us as well.

Comment 17

[Rob Campbell [:rc] (:robcee)]

fwiw, this plugin doesn't play too well with Safari either.

Process:         Safari [6424]
Path:            /Applications/Safari.app/Contents/MacOS/Safari
Identifier:      com.apple.Safari
Version:         4.0.2 (5530.19)
Build Info:      WebBrowser-55301900~2
Code Type:       X86 (Native)
Parent Process:  launchd [161]

Interval Since Last Report:          631966 sec
Crashes Since Last Report:           1
Per-App Interval Since Last Report:  850 sec
Per-App Crashes Since Last Report:   1

Date/Time:       2009-08-21 15:44:48.274 -0300
OS Version:      Mac OS X 10.5.7 (9J61)
Report Version:  6
Anonymous UUID:  ABB9D74F-36BE-4AC8-ADA3-13E6BACBDF0F

Exception Type:  EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0000000000000002, 0x0000000000000000
Crashed Thread:  18

Application Specific Information:
*** Terminating app due to uncaught exception 'WebKitThreadingException', reason: 'DOMNode* kit(WebCore::Node*) was called from a secondary thread'

Comment 18

[Benjamin Smedberg]

Definitely a plugin programming error, INVALID.