Crash [@ npdsplay.dll][@ UserCallWinProcCheckWow][@ @0x300bf8c3] with plugins on reload or back and forward

VERIFIED FIXED in mozilla1.9beta5

Status

()

Core
Plug-ins
P1
critical
VERIFIED FIXED
10 years ago
7 years ago

People

(Reporter: Martijn Wargers (zombie), Assigned: jst)

Tracking

(4 keywords)

Trunk
mozilla1.9beta5
x86
Windows XP
crash, regression, testcase, topcrash
Points:
---
Bug Flags:
blocking1.9 +

Firefox Tracking Flags

(Not tracked)

Details

(crash signature)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
Created attachment 309973 [details]
testcase

See testcase, which crashes Firefox on reload. This is with the Windows Media Player 10 installed.
The binding attached to the embed, is just an empty binding.

This regressed between 2008-03-13 and 2008-03-14, so I think a regression from bug 416953.
(Reporter)

Comment 1

10 years ago
http://crash-stats.mozilla.com/report/index/526c858c-f42f-11dc-9237-001a4bd46e84
0  	npdsplay.dll@0x29519  	
1 	npdsplay.dll@0x2972e 	
2 	InternalCallWinProc 	
3 	UserCallWinProcCheckWow 	
4 	DispatchClientMessage 	
5 	__fnDWORD 	
6 	KiUserCallbackDispatcher 	
7 	npdsplay.dll@0x29703 	
8 	wmp.dll@0xf3744 	
9 	wmp.dll@0x155e0e 	
10 	npdsplay.dll@0x17b03 	
11 	npdsplay.dll@0xcea7 	
12 	npdsplay.dll@0x1090c 	
13 	ns4xPluginInstance::Stop() 	mozilla/modules/plugin/base/src/ns4xPluginInstance.cpp:955
14 	DoStopPlugin 	mozilla/layout/generic/nsObjectFrame.cpp:1730
15 	nsStopPluginRunnable::Run() 	mozilla/layout/generic/nsObjectFrame.cpp:1766
16 	nsThread::ProcessNextEvent(int, int*) 	mozilla/xpcom/threads/nsThread.cpp:510
17 	PR_GetEnv 	
(Reporter)

Comment 2

10 years ago
Created attachment 309975 [details]
testcase2

This is with Flash version 9,0,115,0 installed.
To reproduce the crash, load testcase2, go back and then forward.

http://crash-stats.mozilla.com/report/index/bf37f685-f431-11dc-b4b0-001a4bd43e5c
0  	@0x300bf8c3  	
1 	UserCallWinProcCheckWow 	
2 	DispatchClientMessage 	
3 	__fnDWORD 	
4 	KiUserCallbackDispatcher 	
5 	TestWindowProcess 	
6 	nsPresContext::EnsureVisible(int) 	mozilla/layout/base/nsPresContext.cpp:1460
7 	PresShell::UnsuppressAndInvalidate() 	mozilla/layout/base/nsPresShell.cpp:4326
8 	PresShell::UnsuppressPainting() 	mozilla/layout/base/nsPresShell.cpp:4386
9 	DocumentViewerImpl::LoadComplete(unsigned int) 	mozilla/layout/base/nsDocumentViewer.cpp:1013
10 	nsDocShell::EndPageLoad(nsIWebProgress*, nsIChannel*, unsigned int) 	mozilla/docshell/base/nsDocShell.cpp:5025
11 	nsWebShell::EndPageLoad(nsIWebProgress*, nsIChannel*, unsigned int) 	mozilla/docshell/base/nsWebShell.cpp:1013
12 	nsCOMPtr_base::assign_from_qi(nsQueryInterface, nsID const&) 	nsCOMPtr.cpp:96
13 	nsDocShell::OnStateChange(nsIWebProgress*, nsIRequest*, unsigned int, unsigned int) 	mozilla/docshell/base/nsDocShell.cpp:4930
This bug has accounted for about 20% of our crashes in the past few days of Windows nightlies, starting in 20080314.
Flags: blocking1.9?
Keywords: topcrash
Summary: Crash [@ npdsplay.dll][@ UserCallWinProcCheckWow] with plugins on reload or back and forward → Crash [@ npdsplay.dll][@ UserCallWinProcCheckWow][@ @0x300bf8c3] with plugins on reload or back and forward
Duplicate of this bug: 423494

Comment 5

10 years ago
(In reply to comment #4)
> *** Bug 423494 has been marked as a duplicate of this bug. ***
> 

I recognize the similarities between the two bugs (same signature, etc.), but the frame stack from comments 1 and 2 doesn't match very well with the report that I posted in bug 423494.  Moreover, I wasn't doing anything with a plugin when the crash happened.  See below:

0  	@0x300a3de3  	
1 	UserCallWinProcCheckWow 	
2 	DispatchClientMessage 	
3 	__fnDWORD 	
4 	ntdll.dll@0x60e6d 	
5 	nsView::~nsView() 	mozilla/view/src/nsView.cpp:272
6 	nsView::`scalar deleting destructor'(unsigned int) 	
7 	nsIView::Destroy() 	mozilla/view/src/nsView.cpp:314
8 	nsView::~nsView() 	mozilla/view/src/nsView.cpp:224
9 	nsView::`scalar deleting destructor'(unsigned int) 	
10 	nsFrame::Destroy() 	mozilla/layout/generic/nsFrame.cpp:505
11 	nsSubDocumentFrame::Destroy() 	mozilla/layout/generic/nsFrameFrame.cpp:784
12 	nsFrameList::DestroyFrames() 	mozilla/layout/generic/nsFrameList.cpp:67
13 	nsContainerFrame::Destroy() 	mozilla/layout/generic/nsContainerFrame.cpp:257
14 	nsFrameList::DestroyFrames() 	mozilla/layout/generic/nsFrameList.cpp:67
15 	nsContainerFrame::Destroy() 	mozilla/layout/generic/nsContainerFrame.cpp:257
16 	nsBoxFrame::RemoveFrame(nsIAtom*, nsIFrame*) 	mozilla/layout/xul/base/src/nsBoxFrame.cpp:1024
17 	nsCSSFrameConstructor::ContentRemoved(nsIContent*, nsIContent*, int, int*) 	mozilla/layout/base/nsCSSFrameConstructor.cpp:9648
18 	PresShell::ContentRemoved(nsIDocument*, nsIContent*, nsIContent*, int) 	mozilla/layout/base/nsPresShell.cpp:4787
19 	nsNodeUtils::ContentRemoved(nsINode*, nsIContent*, int) 	mozilla/content/base/src/nsNodeUtils.cpp:167
20 	nsGenericElement::doRemoveChildAt(unsigned int, int, nsIContent*, nsIContent*, nsIDocument*, nsAttrAndChildArray&) 	mozilla/content/base/src/nsGenericElement.cpp:2850
21 	nsXULElement::RemoveChildAt(unsigned int, int) 	mozilla/content/xul/content/src/nsXULElement.cpp:980
22 	nsXULElement::IndexOf(nsINode*) 	mozilla/content/xul/content/src/nsXULElement.cpp:906
23 	nsXULElement::RemoveChild(nsIDOMNode*, nsIDOMNode**) 	mozilla/content/xul/content/src/nsXULElement.h:610
24 	NS_InvokeByIndex_P 	mozilla/xpcom/reflect/xptcall/src/md/win32/xptcinvoke.cpp:101
25 	xptiInterfaceEntry::GetMethodInfo(unsigned short, nsXPTMethodInfo const**) 	mozilla/xpcom/reflect/xptinfo/src/xptiInterfaceInfo.cpp:317
(Assignee)

Updated

10 years ago
Assignee: nobody → jst
Flags: blocking1.9? → blocking1.9+
Priority: -- → P1

Comment 6

10 years ago
Not to confuse or derail things in this bug, but a random sampling of crashes from here:

http://crash-stats.mozilla.com/report/list?range_unit=weeks&version=Firefox%3A3.0b5pre&range_value=2&signature=%400x300bf8c3

reveals that a large proportion of the crashes with signature 0x300bf8c3 have a frame stack similar to that of comment 5 and not to comment 1 or comment 2.  I'd posit that the large proportion of 0x300bf8c3 crashes are related to bug 423494.

Comment 7

10 years ago
we should try and get this fixed for before releasing beta 5.  looks like it will likely be the top crash by wide margin (4x?) over the number #2 crasher if we don't....
Target Milestone: --- → mozilla1.9beta5
(Assignee)

Comment 8

10 years ago
Fixed by the fix for bug 422926.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → FIXED
verified fixed using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9pre) Gecko/2008041217 Minefield/3.0pre ID:2008041217 and the testcases from this bug. No crash on testcases --> Verified fixed
Status: RESOLVED → VERIFIED
Crash Signature: [@ npdsplay.dll] [@ UserCallWinProcCheckWow] [@ @0x300bf8c3]
You need to log in before you can comment on or make changes to this bug.