Closed Bug 354102 Opened 18 years ago Closed 16 years ago

Crash [@ nsObjectFrame::Instantiate]


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



(Not tracked)



(Reporter: smaug, Assigned: jst)



(Keywords: crash)

Crash Data


(2 files, 1 obsolete file)

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:

This is related to Bug 312062, Bug 346688, Bug 330832 and Bug 136927. Or perhaps even a dup of one of those.
Should nsObjectFrame::nsObjectFrame() set mInstanceOwner to nsnull.
There are also crashes @ nsPluginInstanceOwner::Destroy.

> Should nsObjectFrame::nsObjectFrame() set mInstanceOwner to nsnull.
 nm that, I think
So.. the code in question basically looks like:

1328   mInstanceOwner->SetPluginHost(pluginHost);
1330   rv = InstantiatePlugin(pluginHost, aMimeType, aURI);
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?

Blocks: 1156
Flags: blocking1.9?
Attached patch a guess fix (obsolete) — Splinter Review
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.
Attachment #240143 - Flags: review?(cbiesinger)
Biesi, any comments on this?
Assignee: nobody → jst
Depends on: 347743
Flags: blocking1.9? → blocking1.9+
Biesi - ping ...
Comment on attachment 240143 [details] [diff] [review]
a guess fix

Clearing the r-request, the code has changed now quite a bit.
Attachment #240143 - Flags: review?(cbiesinger)
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 :/
Depends on: 393845
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
Attachment #240143 - Attachment is obsolete: true
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.
Keywords: topcrash
Priority: -- → P5
Flags: wanted-next+
Flags: tracking1.9+
Flags: blocking1.9-
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
<> Firefox sometimes
Here's the crash report:
shows up as crash #87 on breakpad for RC1.
Keywords: crash
Make sure we don't crash if the frame dies while we're initializing the plugin.
Test builds with the above patch applied available here:

Please test if you're able to reproduce this crash!
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.
Attached file testcase
The tryserver build seems to fix the crash with this testcase, though.

With a normal trunk build, I get this breakpad stacktrace:
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
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
wanted1.9.1+ w/ P3.
Flags: wanted1.9.1?
Flags: wanted1.9.1+
Flags: wanted1.9.0.x?
Flags: wanted1.9.0.x+
Flags: blocking1.9.1?
Flags: blocking1.9.1-
Flags: blocking1.9.0.1?
Flags: blocking1.9.0.1-
Priority: P5 → P3
Also crashing with the stacktrace from comment 16 on when trying to view a video.
The testcase, that I attached, , 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.
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
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.
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.
Martijn, can you still reproduce this with a nightly from today or later?
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
Awesome. I'm betting this was fixed by the patch that went in for bug 421833.
Closed: 16 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsObjectFrame::Instantiate]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.