354102 - Crash [@ nsObjectFrame::Instantiate]

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Olli Pettay [:smaug][[e-mail]]]

Currently #13 crash in trunk builds and 
some of the nsQueryInterface::operator() crashes seems to be caused by this too.

One form of the stack traces look like this:
nsObjectFrame::Instantiate()
nsObjectLoadingContent::Instantiate()
nsAsyncInstantiateEvent::Run()
nsThread::ProcessNextEvent()
NS_ProcessNextEvent_P()
nsBaseAppShell::Run()
nsAppStartup::Run()
XRE_main()
main()

This is related to Bug 312062, Bug 346688, Bug 330832 and Bug 136927. Or perhaps even a dup of one of those.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Should nsObjectFrame::nsObjectFrame() set mInstanceOwner to nsnull.

Comment 2

[Olli Pettay [:smaug][[e-mail]]]

There are also crashes @ nsPluginInstanceOwner::Destroy.


> Should nsObjectFrame::nsObjectFrame() set mInstanceOwner to nsnull.
> 
 nm that, I think

Comment 3

[Boris Zbarsky [:bzbarsky]]

So.. the code in question basically looks like:

1328   mInstanceOwner->SetPluginHost(pluginHost);
1329 
1330   rv = InstantiatePlugin(pluginHost, aMimeType, aURI);
1331 
1332   // finish up
1333   if (NS_SUCCEEDED(rv)) {
1334     nsCOMPtr<nsIPluginInstance> inst;
1335     mInstanceOwner->GetInstance(*getter_AddRefs(inst));

With us crashing on line 1335(!) on Windows.  But the Windows stacks look pretty bogus.

The stack in comment 0 looks like one of the Linux stacks, but doesn't have any line numbers....

It _could_ be that instantiating the plugin kills the frame or something, I suppose.  Could always try handling that with an nsWeakFrame and see if it helps?

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Attachment: a guess fix

Perhaps we could try something like this.
Trying to prevent crashes if frame somehow gets deleted when instantiating or stopping a plugin.
But this is just a guess fix.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Biesi, any comments on this?

Comment 6

[Mike Schroepfer]

Biesi - ping ...

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 240143 [details] [diff] [review]
a guess fix

Clearing the r-request, the code has changed now quite a bit.

Comment 8

[Christian :Biesinger (don't email me, ping me on IRC)]

bug 393845 fixes at least parts of this, and in fact parts of that patch look very much like parts of this one... sorry for never getting to this review :/

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Comment on attachment 240143 [details] [diff] [review]
a guess fix

jst says this is not the right fix, and the problem it covers has been fixed elsewhere

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is this still showing up in breakbad a lot? Please add back the topcrash keyword if so. We would probably want to up the priority too then.

Comment 11

[Michael Köhler [:Coce]]

Im running Windows XP Service Pack 3,
Firefox 3 RC1 (Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.9)
Gecko/2008051206 Firefox/3.0)
and Java SE 6 Update 6.

When I do the Java test here
<http://www.java.com/en/download/help/testvm.xml?ff3> Firefox sometimes
crashes.
Here's the crash report:
<http://crash-stats.mozilla.com/report/index/8e72e005-28f4-11dd-ba47-001321b13766?p=1>

Comment 12

[Tony Chung [:tchung]]

shows up as crash #87 on breakpad for RC1.   

http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0

Comment 13

[Johnny Stenback (:jst)]

Attachment: Another guess fix.

Make sure we don't crash if the frame dies while we're initializing the plugin.

Comment 14

[Johnny Stenback (:jst)]

Test builds with the above patch applied available here:

https://build.mozilla.org/tryserver-builds/2008-05-23_12:[e-mail]-objframe-init-crash/

Please test if you're able to reproduce this crash!

Comment 15

[Martijn Wargers (dead)]

I was hoping this patch would fix the crash with the testcase from bug 421833, but it doesn't. The stacktrace in that bug looks almost the same as this one, that's why.

Comment 16

[Martijn Wargers (dead)]

Attachment: testcase

The tryserver build seems to fix the crash with this testcase, though.

With a normal trunk build, I get this breakpad stacktrace:
http://crash-stats.mozilla.com/report/index/66db8773-2d85-11dd-a85e-001cc45a2ce4?p=1
0  	 	@0x0  	
1 	xul.dll 	Create4xPlugin 	nsPluginHostImpl.cpp:4710
2 	xul.dll 	nsPluginHostImpl::GetPluginFactory 	nsPluginHostImpl.cpp:4827
3 	xul.dll 	nsPluginHostImpl::TrySetUpPluginInstance 	nsPluginHostImpl.cpp:4043
4 	xul.dll 	nsPluginHostImpl::SetUpPluginInstance 	nsPluginHostImpl.cpp:3911

Comment 17

[Damon Sicore (:damons)]

wanted1.9.0.1+
blocking1.9.0.1-
blocking1.9.1-
wanted1.9.1+ w/ P3.

Comment 18

[Martijn Wargers (dead)]

Also crashing with the stacktrace from comment 16 on http://www.artoischampionships.com/1/news/video_2008.asp when trying to view a video.

Comment 19

[Martijn Wargers (dead)]

The testcase, that I attached, https://bugzilla.mozilla.org/attachment.cgi?id=322946 , regressed between 2008-05-18 (not crashing) and 2008-05-28 (crashing).
Ria, do you have builds inbetween to find a more narrow regression range? Thanks.

Comment 20

[Martijn Wargers (dead)]

Never mind, that regression range is probably incorrect. The crash seems to only happen on hg builds, not on branch.
So a regression range for hg builds might be useful, although I have no idea how to get a nice list of check-ins of a regression window on hg.mozilla.org.

Comment 21

[Ria Klaassen (not reading all bugmail)]

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008061609 Minefield/3.1a1pre

I get no crash but only a sound fragment. Also with branch builds.

Comment 22

[Ria Klaassen (not reading all bugmail)]

OK, I see, it is XP-only. Not on Vista. Vista has a plugin in its own Plugins folder and no problem (at least here). On XP the problem was there on a 1 April build, so probably from the beginning; when it should have started to work it didn't work.

Comment 23

[Johnny Stenback (:jst)]

Martijn, can you still reproduce this with a nightly from today or later?

Comment 24

[Martijn Wargers (dead)]

Yeah, seems to be worksforme, now, using:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008063003 Minefield/3.1a1pre

Comment 25

[Johnny Stenback (:jst)]

Awesome. I'm betting this was fixed by the patch that went in for bug 421833.