344325 - meez.com is crashing SeaMonkey/OSX [@ nsObjectFrame::Instantiate]

Status: RESOLVED WORKSFORME

(Core Graveyard :: Plug-ins, defect)

Description

[David Barr]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060627 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060627 SeaMonkey/1.5a

This is one of the current memes on LiveJournal. Just going to the main site will crash SeaMonkey.

Reproducible: Always

Steps to Reproduce:
1. Open the browser.
2. Type "http://www.meez.com"
3. Hit "Enter."

Actual Results:  
Blooie!

Expected Results:  
Open the page. If unable, announce an error and close the tab.

Yet another case where having Talkback for OSX would have helped.

Also, this made me think of a general question. What is the difficulty level of incorporating error handling code that kills an individual tab on receiving bad code, as opposed to killing the application entirely?

Comment 1

[David Barr]

Okay, so I forgot to make sure I was at the latest nightly build before writing the bug. However, the behavior is the same with 

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060711 SeaMonkey/1.5a

save for a delay in the point where the browser crashes.

Comment 2

[Adam Guthrie]

If you wanted to try crashing with a Firefox build that would be great. http://kb.mozillazine.org/Talkback

Comment 3

[David Barr]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8.0.4) Gecko/20060508 Firefox/1.5.0.4

gets the "Browser unsupported" page without crashing. The 20060711 nightly build of Firefox/Minefield did crash, but did not launch Talkback. I didn't get the full build string for Minefield, but I can go after that if you need it.

Comment 4

[Stefan [:stefanh]]

Hmm... (10.3.9 ppc seamonkey debug build with quite recent source) this looks like it's caused by bug 136927:

###!!! ASSERTION: about to crash due to bug 136927: '!mInstantiating', file /Users/Stefan/mozilla-debug/mozilla/layout/generic/nsObjectFrame.cpp, line 488

I've got two crash logs from the crash, the first lines are:
---------------------------------------
Thread 0 Crashed:
0   libgklayout.dylib        	0x1c445a70 nsObjectFrame::Instantiate(char const*, nsIURI*) + 0x1ac (nsObjectFrame.cpp:1340)
1   libgklayout.dylib        	0x1c660d48 nsObjectLoadingContent::Instantiate(nsACString_internal const&, nsIURI*) + 0x460 (nsObjectLoadingContent.cpp:1349)
2   libgklayout.dylib        	0x1c65c0bc nsAsyncInstantiateEvent::Run() + 0x1e0 (nsObjectLoadingContent.cpp:140)
3   libxpcom_core.dylib      	0x01e6ec5c nsThread::ProcessNextEvent(int, int*) + 0x2a8 (nsThread.cpp:483)
4   libxpcom_core.dylib      	0x01df5c6c NS_ProcessNextEvent_P(nsIThread*, int) + 0xa8 (nsThreadUtils.cpp:225)
5   libwidget_mac.dylib      	0x0aa0ce2c nsBaseAppShell::Run() + 0xa8 (nsBaseAppShell.cpp:153)
6   libappcomps.dylib        	0x08830a84 nsAppStartup::Run() + 0x48 (nsAppStartup.cpp:218)
7   org.mozilla.seamonkey    	0x00006320 main1(int, char**, nsISupports*) + 0xe50 (nsAppRunner.cpp:1238)
8   org.mozilla.seamonkey    	0x00006b3c main + 0x260 (nsAppRunner.cpp:1740)
9   org.mozilla.seamonkey    	0x0000201c _start + 0x17c (crt.c:267)
10  org.mozilla.seamonkey    	0x00001e9c start + 0x30

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

and

Thread 0 Crashed:
0   libgklayout.dylib        	0x1caf6ffc 0x1c336000 + 0x7c0ffc
1   libgklayout.dylib        	0x1cb0ba8c 0x1c336000 + 0x7d5a8c
2   libgklayout.dylib        	0x1c444350 nsObjectFrame::InstantiatePlugin(nsIPluginHost*, char const*, nsIURI*) + 0x1d8 (nsObjectFrame.cpp:736)
3   libgklayout.dylib        	0x1c445a48 nsObjectFrame::Instantiate(char const*, nsIURI*) + 0x184 (nsObjectFrame.cpp:1335)
4   libgklayout.dylib        	0x1c660d48 nsObjectLoadingContent::Instantiate(nsACString_internal const&, nsIURI*) + 0x460 (nsObjectLoadingContent.cpp:1349)
5   libgklayout.dylib        	0x1c65c0bc nsAsyncInstantiateEvent::Run() + 0x1e0 (nsObjectLoadingContent.cpp:140)
6   libxpcom_core.dylib      	0x01e6ec5c nsThread::ProcessNextEvent(int, int*) + 0x2a8 (nsThread.cpp:483)
7   libxpcom_core.dylib      	0x01df5c6c NS_ProcessNextEvent_P(nsIThread*, int) + 0xa8 (nsThreadUtils.cpp:225)
8   libwidget_mac.dylib      	0x0aa0ce2c nsBaseAppShell::Run() + 0xa8 (nsBaseAppShell.cpp:153)
9   libappcomps.dylib        	0x08830a84 nsAppStartup::Run() + 0x48 (nsAppStartup.cpp:218)
10  org.mozilla.seamonkey    	0x00006320 main1(int, char**, nsISupports*) + 0xe50 (nsAppRunner.cpp:1238)
11  org.mozilla.seamonkey    	0x00006b3c main + 0x260 (nsAppRunner.cpp:1740)
12  org.mozilla.seamonkey    	0x0000201c _start + 0x17c (crt.c:267)
13  org.mozilla.seamonkey    	0x00001e9c start + 0x30

Looking at talkback reports - there are 167 reports with the stack signature 'nsObjectFrame::Instantiate' or "nsObjectFrame::InstantiatePlugin"

My console output shows some more stuff - I'll attach the output as a separate file (it doesn't says me anything, but might for someone else)

Comment 5

[Stefan [:stefanh]]

Attachment: Console output

Here's my Console output from just before crashing.

Comment 6

[Adam Guthrie]

Stefan or David, can you get this crash with another browser? Say Safari?

Comment 7

[David Barr]

Safari 2.0.4 appears to be fine. The "Your browser is not supported" page that I get in stable Firefox does list several browsers that work.

Comment 8

[Stefan [:stefanh]]

Looking at the assertion, this is caused by bug 136927. Stacks looks different, though.

Comment 9

[timeless]

oh man. could you please get stack traces for
###!!! ASSERTION: nsPluginHostImpl not thread-safe: '_mOwningThread.GetThread() == PR_GetCurrentThread()', file /Users/Stefan/mozilla-debug/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp, line 2546

that's very bad.

reporter: the problem is that if a "page" "crashes" it probably corrupted internal shared global gecko state. there's no useful way to recover from this.

the only solution is to switch to a model where each page uses its own independent process/instance. I'd love to see that happen, but it won't happen before gecko 1.10 (or whatever gecko 1.9+1 is) and if it does happen, we could call the new gecko version major+1 (if the current at the time before that feature is gecko 2.1, then it might as well be gecko 3.0 with that feature since it's a huge thing).

Comment 10

[David Barr]

If you really need the stack trace, I'm tempted to suggest this bug is dependent on 341560. But, that's just me being a snot... 

I'll play with Minefield some more in the next few days, especially to verify that Talkback is included as a component in the nightly build.

Comment 11

[David Barr]

Works now.