Crash [@ nsObjectFrame::Instantiate]

RESOLVED FIXED

Status

()

P3
major
RESOLVED FIXED
12 years ago
8 years ago

People

(Reporter: smaug, Assigned: jst)

Tracking

({crash})

Trunk
x86
All
crash
Points:
---
Dependency tree / graph
Bug Flags:
wanted-next +
blocking1.9.1 -
wanted1.9.1 +
blocking1.9 -
blocking1.9.0.1 -
wanted1.9.0.x +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments, 1 obsolete attachment)

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?

Blocks: 1156
Flags: blocking1.9?
Created attachment 240143 [details] [diff] [review]
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.
Attachment #240143 - Flags: review?(cbiesinger)
Biesi, any comments on this?
Assignee: nobody → jst
Depends on: 347743
Flags: blocking1.9? → blocking1.9+

Comment 6

12 years ago
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

Updated

11 years ago
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
<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
Keywords: crash
(Assignee)

Comment 13

11 years ago
Created attachment 322287 [details] [diff] [review]
Another guess fix.

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

Comment 14

11 years ago
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.
Created attachment 322946 [details]
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
Flags: wanted1.9.1?
Flags: wanted1.9.0.x?
Flags: blocking1.9.1?
Flags: blocking1.9.0.1?
wanted1.9.0.1+
blocking1.9.0.1-
blocking1.9.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 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.
(Assignee)

Comment 23

11 years ago
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
(Assignee)

Comment 25

11 years ago
Awesome. I'm betting this was fixed by the patch that went in for bug 421833.
Status: NEW → RESOLVED
Last Resolved: 11 years ago
Resolution: --- → FIXED
Crash Signature: [@ nsObjectFrame::Instantiate]
You need to log in before you can comment on or make changes to this bug.