builds from Feb. 23rd onwards occationally crash in nsPluginInstanceOwner::Destroy TB4316693K Looking at the checkins between 2005-02-22 04:00:00 and 2005-02-23 04:00:00, I'm guessing the checkin for bug 280217 could be involved. Added comment. Please take a look at the stack. 20 new crashes are till now reportged with that stack, seamonkey and ff both.

http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=all&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-02-22+04%3A00%3A00+&maxdate=2005-02-23+04%3A00%3A00&cvsroot=%2Fcvsroot I doubt that the checkin is responsible the code in question is only executed if a hidden input is the direct descendant of a table tag. A url/testcase would be cool.

i wonder if it happens when i mouse over plugin areas during load but i cant reproduce it at will. I use the "X-mouse" focus/raise feature from TweakUI, powertoys for XP. Have crashed at least twice with the stack past week. Got an alert about Media player plugin having terminated the last time i crashed now. The media in question was likely an add in an iframe. Comments in other talkbacks indicate java was involved.

bug 286004 seems pretty close?

perhaps, but the 20 other stacks are identical, the ones in the other bug are all different, and my about:plugins doesn't show java intalled.. I notice that after this crash, i can no longer save files. I wonder if registry.dat gets corrupted. And the registry.dat file for some reason seem to have a "media player" kind of icon. And again; the crash seems to involve media player.

This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/

Incident ID: 22538892 Stack Signature nsPluginInstanceOwner::Destroy f08bf354 Product ID MozillaTrunk Build ID 2006082509 Trigger Time 2006-08-26 11:01:57.0 Platform Win32 Operating System Windows NT 5.1 build 2600 Module gklayout.dll + (0005ab2e) URL visited User Comments Since Last Crash 32210 sec Total Uptime 32505 sec Trigger Reason Access violation Source File, Line No. c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp, line 3038 Stack Trace nsPluginInstanceOwner::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp, line 3038] nsObjectFrame::StopPlugin [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp, line 1404] nsObjectFrame::PrepareInstanceOwner [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp, line 1276] nsObjectLoadingContent::Instantiate [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsObjectLoadingContent.cpp, line 1360] nsObjectLoadingContent::EnsureInstantiation [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/base/src/nsObjectLoadingContent.cpp, line 565] nsHTMLExternalObjSH::GetPluginInstance [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 9102] nsHTMLExternalObjSH::PostCreate [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsDOMClassInfo.cpp, line 9143] XPCWrappedNative::GetNewOrUsed [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 463] XPCWrappedNative::GetNewOrUsed [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 332] XPCConvert::NativeInterface2JSObject [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 1176] XPCConvert::NativeData2JS [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcconvert.cpp, line 474] XPCWrappedNative::CallMethod [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp, line 2252] XPC_WN_GetterSetter [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/xpconnect/src/xpcwrappednativejsops.cpp, line 1481] js_Invoke [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 1350] js_InternalInvoke [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 1448] js_InternalGetOrSet [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 1508] js_GetProperty [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsobj.c, line 3439] js_Interpret [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 3785] js_Invoke [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 1369] js_InternalInvoke [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsinterp.c, line 1448] JS_CallFunctionValue [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/js/src/jsapi.c, line 4420] nsJSContext::CallEventHandler [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/base/nsJSEnvironment.cpp, line 1740] nsJSEventListener::HandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/dom/src/events/nsJSEventListener.cpp, line 213] nsEventListenerManager::HandleEventSubType [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp, line 1648] nsEventListenerManager::HandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventListenerManager.cpp, line 1752] nsEventTargetChainItem::HandleEvent [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventDispatcher.cpp, line 356] nsEventTargetChainItem::HandleEventTargetChain [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventDispatcher.cpp, line 433] nsEventDispatcher::Dispatch [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/content/events/src/nsEventDispatcher.cpp, line 643] PresShell::HandleDOMEventWithTarget [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresShell.cpp, line 6281] nsPopupSetFrame::OnCreate [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsPopupSetFrame.cpp, line 609] nsPopupSetFrame::ShowPopup [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsPopupSetFrame.cpp, line 326] nsPopupBoxObject::ShowPopup [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsPopupBoxObject.cpp, line 148] nsXULTooltipListener::LaunchTooltip [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsXULTooltipListener.cpp, line 518] nsXULTooltipListener::ShowTooltip [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/xul/base/src/nsXULTooltipListener.cpp, line 408] nsTimerImpl::Fire [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/threads/nsTimerImpl.cpp, line 383] NS_ProcessNextEvent_P [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpcom/build/nsThreadUtils.cpp, line 225] nsXULWindow::ShowModal [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsXULWindow.cpp, line 402] nsContentTreeOwner::ShowAsModal [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/xpfe/appshell/src/nsContentTreeOwner.cpp, line 503] nsWindowWatcher::OpenWindow [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/embedding/components/windowwatcher/src/nsWindowWatcher.cpp, line 415] nsPromptService::DoDialog [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 659] nsPromptService::ConfirmEx [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/embedding/components/windowwatcher/src/nsPromptService.cpp, line 346] nsPrompt::ConfirmEx [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/embedding/components/windowwatcher/src/nsPrompt.cpp, line 306] nsPluginHostImpl::HandleBadPlugin [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/plugin/base/src/nsPluginHostImpl.cpp, line 6312] ns4xPluginInstance::Stop [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp, line 923] nsObjectFrame::StopPlugin [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp, line 1381] nsObjectFrame::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsObjectFrame.cpp, line 493] nsLineBox::DeleteLineList [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsLineBox.cpp, line 368] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] nsLineBox::DeleteLineList [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsLineBox.cpp, line 368] nsLineBox::DeleteLineList [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsLineBox.cpp, line 368] nsLineBox::DeleteLineList [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsLineBox.cpp, line 368] nsLineBox::DeleteLineList [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsLineBox.cpp, line 368] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] CanvasFrame::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsHTMLFrame.cpp, line 211] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] nsFrameList::DestroyFrames [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/generic/nsFrameList.cpp, line 60] nsFrameManager::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsFrameManager.cpp, line 293] DocumentViewerImpl::Destroy [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsDocumentViewer.cpp, line 1612] DocumentViewerImpl::Show [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsDocumentViewer.cpp, line 1905] nsPresContext::EnsureVisible [c:/builds/tinderbox/MozillaTrunk/WINNT_5.0_Clobber/mozilla/layout/base/nsPresContext.cpp, line 1306]

nsPluginInstanceOwner::Destroy appears in these sigs for 1.9.1, 1.9.2, 1.9.3, the first being the most common ... nsPluginInstanceOwner::Destroy() nsCOMPtr<nsIPluginWidget>::nsCOMPtr<nsIPluginWidget>(nsQueryInterface) | nsPluginInstanceOwner::Destroy() nsRefPtr<nsPrivateTextRangeList>::assign_assuming_AddRef(nsPrivateTextRangeList*) | nsRefPtr<PluginWindowEvent>::assign_with_AddRef(PluginWindowEvent*) | nsPluginInstanceOwner::Destroy() bp-0d56d1c3-0811-4b1c-accb-72c452091216 Mac FF 3.5.6 0 XUL nsPluginInstanceOwner::Destroy layout/generic/nsObjectFrame.cpp:4055 1 XUL DoStopPlugin layout/generic/nsObjectFrame.cpp:1983 2 XUL nsObjectFrame::StopPluginInternal layout/generic/nsObjectFrame.cpp:2086 3 XUL FreezeElement layout/base/nsPresShell.cpp:6464 4 XUL EnumerateFreezables content/base/src/nsDocument.cpp:7633 5 XUL PL_DHashTableEnumerate pldhash.c:735 6 XUL nsIDocument::EnumerateFreezableElements nsTHashtable.h:241 7 XUL PresShell::Freeze layout/base/nsPresShell.cpp:6480 8 XUL DocumentViewerImpl::Destroy layout/base/nsDocumentViewer.cpp:1424 9 XUL DocumentViewerImpl::Show layout/base/nsDocumentViewer.cpp:1840 10 XUL nsPresContext::EnsureVisible layout/base/nsPresContext.cpp:1550 bp-6b33393f-4edc-4da4-95d2-59a0a2091230 FF 3.5.6 windows 0 xul.dll nsPluginInstanceOwner::Destroy layout/generic/nsObjectFrame.cpp:4051 1 xul.dll DoStopPlugin layout/generic/nsObjectFrame.cpp:1983 2 xul.dll nsStopPluginRunnable::Run layout/generic/nsObjectFrame.cpp:2020 3 xul.dll nsThread::ProcessNextEvent xpcom/threads/nsThread.cpp:521

bp-0d56d1c3-0811-4b1c-accb-72c452091216 is the only one in last 4 months with comments

There's a spike in crashes from 13.0a1/20120201 and it's now #16 top crasher in this build. The regression window for the spike is: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3f26b7bee352&tochange=e18c7bc2c28e It's likely caused by bug 90268. The first frames of the stack look like: Frame Module Signature [Expand] Source 0 xul.dll nsPluginInstanceOwner::Destroy dom/plugins/base/nsPluginInstanceOwner.cpp:2723 1 xul.dll nsPluginHost::StopPluginInstance dom/plugins/base/nsPluginHost.cpp:3283 2 xul.dll nsRefPtr<nsPresContext>::~nsRefPtr<nsPresContext> obj-firefox/dist/include/nsAutoPtr.h:907 3 xul.dll nsObjectLoadingContent::DoStopPlugin content/base/src/nsObjectLoadingContent.cpp:2036 4 xul.dll nsObjectLoadingContent::StopPluginInstance content/base/src/nsObjectLoadingContent.cpp:2063 5 xul.dll InDocCheckEvent::Run content/base/src/nsObjectLoadingContent.cpp:171 6 xul.dll nsThread::ProcessNextEvent 7 xul.dll CallCreateInstance obj-firefox/xpcom/build/nsComponentManagerUtils.cpp:170 8 xul.dll MessageLoop::DoWork ipc/chromium/src/base/message_loop.cc:412 More reports at: https://crash-stats.mozilla.com/report/list?signature=nsPluginInstanceOwner%3A%3ADestroy%28%29

This looks like a case where mContent is set to null. We could check for that before calling the remove listener calls, but I wonder if this would constitute a leak in that we should have unhooked these earlier. Josh, thoughts?

(In reply to Jim Mathies [:jimm] from comment #10) > This looks like a case where mContent is set to null. We could check for > that before calling the remove listener calls It's not NULL, it's a bad pointer. Some addresses are NULL, some look valid but deleted, some look like garbage.

One comment says: "Java servlet for the danish NemID login timed out cause I put the PC in standby, before logging in. Reloaded the homepage, then I retried, and then it crashed" Almost all crash reports have jvm.dll, mainly 20.5.0.3 (Java(TM) Platform SE 6u30) and also 22.0.0.10 (Java(TM) Platform SE 7u2).

jvm.dll is "Java HotSpot(TM) Client VM".

One comment says: "Java servlet for the danish NemID login timed out cause I put the PC in standby, before logging in. Reloaded the homepage, then I retried, and then it crashed"

This is probably not the same bug it started out as: when we fix whatever caused the spike we'll probably still have other crashes at this signature. As far as security severity rating EXCEPTION_ACCESS_VIOLATION_EXEC isn't good (but I only see one in the past week) bp-ed58b82b-0f5d-4ea4-b233-7a5f12120220 Neither is EXCEPTION_PRIV_INSTRUCTION (that's in Fx4, though) bp-1d75926f-f6ec-485c-bbb6-de32d2120220 I'm not sure how it crashes at the invalid read in bp-12eb8cc0-af8d-4db3-9147-424562120222 -- if the crash location is right it had to execute a dozen nearly identical calls before crashing on one mContent->RemoveEventListener(NS_LITERAL_STRING(<various>), this, true); http://hg.mozilla.org/releases/mozilla-release/annotate/c581b36e7a12/dom/plugins/base/nsPluginInstanceOwner.cpp#l2674

see Bug 724781

Josh, can you take this one? If not, please reassign. I don't know that we'll do anything about the original problem that this bug was filed about, but the recent changes look like to be fallout from your recent plugin work, and we should sort that out before we ship this IMO.

I think the fix for bug 723523 probably fixed this. I don't see it in crash-stats any more, correct me if I'm wrong.

https://crash-stats.mozilla.com/report/list?signature=nsPluginInstanceOwner::Destroy%28%29 shows a few crashes in the first signature, but not many. The second signature is still around and seems to be covered by Bug 724248.

The latest crash happened in 13.0a1/20120301.

We've never been able to induce the crash for this or bug 723523 on demand, right? There probably isn't much to be verified for this fix other than seeing if the overall number of crashes goes down.

Checking over crash-stats I see no instances of the signature over the last week for any Firefox version. Marking verified based on this data since this does not have a reproducible testcase.