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.

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); 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?

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.

Biesi, any comments on this?

Biesi - ping ...

Comment on attachment 240143 [details] [diff] [review] a guess fix Clearing the r-request, the code has changed now quite a bit.

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 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

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.

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>

shows up as crash #87 on breakpad for RC1. http://crash-stats.mozilla.com/topcrasher/byversion/Firefox/3.0

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: https://build.mozilla.org/tryserver-builds/2008-05-23_12:16-jst@mozilla.com-objframe-init-crash/ 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.

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

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

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

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.

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.

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.