434593 - Crash [@ UserCallWinProcCheckWow] with Adobe PDF plugin, document.write and going back

Status: VERIFIED FIXED

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

Description

[Martijn Wargers (dead)]

Attachment: testcase

See testcase, which crashes current trunk build after 200ms, when you have the Adobe PDF Reader (version 8.1.2) installed.

This seems to have regressed between 2007-08-12 and 2007-08-13:
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=2007-08-12+03&maxdate=2007-08-13+21&cvsroot=%2Fcvsroot
I think a regression from bug 347743 somehow.

http://crash-stats.mozilla.com/report/index/3414d40a-25d9-11dd-a7b1-0013211cbf8a?p=1
0  	 	@0x40c0001c  	
1 	user32.dll 	UserCallWinProcCheckWow 	
2 	user32.dll 	CallWindowProcAorW 	
3 	user32.dll 	CallWindowProcA 	
4 	nppdf32.dll 	nppdf32.dll@0x68ee 	
5 	user32.dll 	InternalCallWinProc 	
6 	user32.dll 	UserCallWinProcCheckWow 	
7 	user32.dll 	DispatchClientMessage 	
8 	user32.dll 	__fnDWORD 	
9 	ntdll.dll 	KiUserCallbackDispatcher 	
10 	nppdf32.dll 	nppdf32.dll@0x67e4 	
11 	user32.dll 	SendMessageW 	
12 	xul.dll 	nsWindow::Destroy 	mozilla/widget/src/windows/nsWindow.cpp:1481
13 	xul.dll 	nsView::~nsView 	mozilla/view/src/nsView.cpp:272
14 	xul.dll 	nsScrollPortView::~nsScrollPortView 	mozilla/view/src/nsScrollPortView.cpp:107
15 	xul.dll 	nsScrollPortView::`scalar deleting destructor' 	
16 	xul.dll 	nsIView::Destroy 	mozilla/view/src/nsView.cpp:314
17 	xul.dll 	nsView::~nsView 	mozilla/view/src/nsView.cpp:224
18 	xul.dll 	nsView::`vector deleting destructor' 	
19 	xul.dll 	nsFrame::Destroy 	mozilla/layout/generic/nsFrame.cpp:505
20 	xul.dll 	nsFrameList::DestroyFrames 	mozilla/layout/generic/nsFrameList.cpp:67
21 	xul.dll 	nsContainerFrame::Destroy 	mozilla/layout/generic/nsContainerFrame.cpp:257
22 	xul.dll 	nsFrameManager::Destroy 	mozilla/layout/base/nsFrameManager.cpp:283
23 	xul.dll 	PresShell::Destroy 	mozilla/layout/base/nsPresShell.cpp:1706
24 	xul.dll 	DocumentViewerImpl::Destroy 	mozilla/layout/base/nsDocumentViewer.cpp:1525
25 	xul.dll 	DocumentViewerImpl::Show 	mozilla/layout/base/nsDocumentViewer.cpp:1845
26 	xul.dll 	nsPresContext::EnsureVisible 	mozilla/layout/base/nsPresContext.cpp:1460
27 	xul.dll 	nsPluginInstanceOwner::Init 	mozilla/layout/generic/nsObjectFrame.cpp:4241
28 	xul.dll 	nsObjectFrame::PrepareInstanceOwner 	mozilla/layout/generic/nsObjectFrame.cpp:1635
29 	xul.dll 	nsObjectFrame::Instantiate 	mozilla/layout/generic/nsObjectFrame.cpp:1683
30 	xul.dll 	nsPluginStreamListener::OnStartRequest 	mozilla/content/html/document/src/nsPluginDocument.cpp:127
31 	xul.dll 	nsDocumentOpenInfo::OnStartRequest 	mozilla/uriloader/base/nsURILoader.cpp:290
32 	xul.dll 	nsBaseChannel::OnStartRequest 	mozilla/netwerk/base/src/nsBaseChannel.cpp:607
33 	xul.dll 	nsInputStreamPump::OnStateStart 	mozilla/netwerk/base/src/nsInputStreamPump.cpp:439
34 	xul.dll 	nsInputStreamPump::OnInputStreamReady 	mozilla/netwerk/base/src/nsInputStreamPump.cpp:395
35 	xul.dll 	nsInputStreamReadyEvent::Run 	mozilla/xpcom/io/nsStreamUtils.cpp:111
36 	xul.dll 	nsThread::ProcessNextEvent 	mozilla/xpcom/threads/nsThread.cpp:510
37 	xul.dll 	nsBaseAppShell::Run 	mozilla/widget/src/xpwidgets/nsBaseAppShell.cpp:170
38 	nspr4.dll 	PR_GetEnv 	
39 	firefox.exe 	wmain 	mozilla/toolkit/xre/nsWindowsWMain.cpp:87
40 	firefox.exe 	firefox.exe@0x217f 	
41 	kernel32.dll 	BaseProcessStart

Comment 1

[Martijn Wargers (dead)]

Still crashes in current trunk build.

Comment 2

[Johnny Stenback (:jst)]

Not blocking on this after all. Does anyone have statistics for this crash? Do lots of people see it?

Comment 3

[Martijn Wargers (dead)]

Maybe this is an Adobe pdf plugin bug?

Comment 4

[Rudi Sherry]

Yes, I believe this is the Adobe PDF plugin (nppdf32.dll).  I happen to be looking at this bug (reported internally here) this morning, although I don't have any information about when the fix might be available.

Comment 9

[Rudi Sherry]

This should be fixed with the new release of Reader/Acrobat 9.1.  If you do apply that patch, please verify that the nppdf32.dll in the plugins folder is patched; it should be, but we have some reports that sometimes it is not.

Comment 10

[Martijn Wargers (dead)]

Indeed, thanks, verified fixed with the latest 9.1 Adobe Reader.

Comment 11

[Ralph P. Schorn]

If nppdf32.dll is not patched - which happened to me on two machines with Adobe Acrobat (not the reader) - then simply copy this file from

C:\Program Files\Adobe\Acrobat 9.0\Acrobat\Browser

to

C:\Program Files\Mozilla Firefox\plugins

The new file has the date Feb 27th 2009.

Comment 12

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Enough users still have old versions of Acrobat that this is still an active top crash on Firefox 3.6 betas (though not on Firefox 3.5.5!).  It seems like it's responsible for slightly over 1% of the crashes in those betas (through being responsible for a little more than half of the UserCallWinProcCheckWow crashes).

(8.1 is about 60% of it, 9.0 about 20%, and the rest older versions.)

Comment 13

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Is there something that could have made this hapeen more reliably in Firefox 3.6 betas than in Firefox 3.5.5?

Comment 14

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

I decided to track the 3.6beta topcrash as bug 531551.

Comment 15

[Rudi Sherry]

The plug-in bug causing the crash triggers when the the parent HWND of the window containing the PDF changes (that is, the HWND containing the PDF content gets a new parent HWND).  This is pretty low-level so the specific reason for increase in 3.6 wouldn't be obvious from the feature-changes (which I just perused).

Perhaps something having to do with themes?

Regardless, updating the user to the latest 8.x or 9.x Reader is the solution, which unfortunately we don't have control over; 7.x Reader is almost end-of-life and we don't expect to make an update for that.

I am still pushing to have a detectable Reader version for our upcoming 8.x and 9.x release which should happen in the next few months (not allowed to say date yet) so the "out-of-date" plug-in notification can happen... note that once that happens, we'll have to change the plug-in detection javsacript so it recognizes that any Reader plug-in without a detectable date is, by definition, out-of-date.

Comment 16

[Ralph P. Schorn]

This bug is still present with me at all my pcs - but only in case Thunderbird 2.0.0.23 has also been started before. I however do not use Adobe Reader but the full product Acrobat 9.2 Pro Extended. An update to the latest Acrobat version (9.2) does not do the job here. The Firefox plugin nppdf32.dll delivered here is still dated Feb 27 2009 and has not been updated by Acrobat 9.11, 9.12, 9.2 etc.