Closed Bug 942819 Opened 7 years ago Closed 7 years ago

crash in mozilla::layers::DeviceManagerD3D9::Init()

Categories

(Core :: Graphics: Layers, defect)

28 Branch
x86
All
defect
Not set
critical

Tracking

()

VERIFIED FIXED
mozilla28
Tracking Status
firefox28 + verified

People

(Reporter: tracy, Assigned: nrc)

References

Details

(Keywords: crash, topcrash-win)

Crash Data

Attachments

(1 file)

This bug was filed from the Socorro interface and is 
report bp-424b3d3c-7a32-4d20-a092-ccbb22131124.
=============================================================

This is a very explosive top crasher that spiked to #1 on Nightly builds beginning 2013112303.  

Crash Reason 	EXCEPTION_ACCESS_VIOLATION_WRITE

Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::layers::DeviceManagerD3D9::Init() 	gfx/layers/d3d9/DeviceManagerD3D9.cpp
1 	xul.dll 	mozilla::layers::LayerManagerD3D9::Initialize(bool) 	gfx/layers/d3d9/LayerManagerD3D9.cpp
2 	xul.dll 	nsWindow::GetLayerManager(mozilla::layers::PLayerTransactionChild *,mozilla::layers::LayersBackend,nsIWidget::LayerManagerPersistence,bool *) 	widget/windows/nsWindow.cpp
3 	xul.dll 	nsWindow::AllowD3D9WithReinitializeCallback(nsWindow *) 	widget/windows/nsWindow.cpp
4 	xul.dll 	nsWindow::EnumAllThreadWindowProc(HWND__ *,long) 	widget/windows/nsWindow.cpp
5 	user32.dll 	InternalEnumWindows 	
6 	user32.dll 	EnumThreadWindows 	
7 	xul.dll 	nsWindow::EnumAllWindows(void (*)(nsWindow *)) 	widget/windows/nsWindow.cpp
8 	xul.dll 	nsWindow::StartAllowingD3D9(bool) 	widget/windows/nsWindow.cpp
9 	xul.dll 	StartAllowingD3D9 	widget/windows/nsToolkit.cpp
10 	xul.dll 	nsTimerImpl::Fire() 	xpcom/threads/nsTimerImpl.cpp
11 	xul.dll 	nsThread::ProcessNextEvent(bool,bool *) 	xpcom/threads/nsThread.cpp
12 	xul.dll 	NS_ProcessNextEvent(nsIThread *,bool) 	xpcom/glue/nsThreadUtils.cpp
13 	xul.dll 	mozilla::ipc::MessagePump::Run(base::MessagePump::Delegate *) 	ipc/glue/MessagePump.cpp
14 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
15 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
16 	xul.dll 	nsBaseAppShell::Run() 	widget/xpwidgets/nsBaseAppShell.cpp
17 	xul.dll 	nsAppShell::Run() 	widget/windows/nsAppShell.cpp
18 	xul.dll 	nsAppStartup::Run() 	toolkit/components/startup/nsAppStartup.cpp
19 	xul.dll 	XREMain::XRE_mainRun() 	toolkit/xre/nsAppRunner.cpp
20 	xul.dll 	XREMain::XRE_main(int,char * * const,nsXREAppData const *) 	toolkit/xre/nsAppRunner.cpp
21 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp
22 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp
23 	firefox.exe 	NS_internal_main(int,char * *) 	browser/app/nsBrowserApp.cpp
24 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp
25 	firefox.exe 	__tmainCRTStartup 	f:/dd/vctools/crt_bld/self_x86/crt/src/crtexe.c
26 	kernel32.dll 	BaseThreadInitThunk 	
27 	ntdll.dll 	__RtlUserThreadStart 	
28 	ntdll.dll 	_RtlUserThreadStart
Bug 900248 landed on the 22nd and changed the assignment of the variable that frame #1 is accessing a code line later. CCing nrc and Bas because of that.
I'm not setting this blocking the other one as I'm not sure that it was the cause but it looks very likely.
Also, this is by far the topcrasher on 28 right now, requesting tracking for that.
Component: Graphics → Graphics: Layers
(In reply to Robert Kaiser (:kairo@mozilla.com) from comment #1)
> Bug 900248 landed on the 22nd and changed the assignment of the variable
> that frame #1 is accessing a code line later. CCing nrc and Bas because of
> that.
> I'm not setting this blocking the other one as I'm not sure that it was the
> cause but it looks very likely.

I'm not sure if I'm doing it right, but from following the link to the crash report and then to hg, I get code from before bug 900248 landed. Does that imply 900248 is not to blame? Or are there many other crash reports after it landed?
Ah, I see what is wrong. Patch coming up...
Assignee: nobody → ncameron
The error happens because in frame 0 |this| is null, thus we get a write error when storing into mFocusWnd. That happens because GetD3D9DeviceManager can return null. In fact the initialisation is done in GetD3D9DeviceManager, so we don't need to do it in the LayerManager too.

(In reply to Nick Cameron [:nrc] from comment #3)
> I'm not sure if I'm doing it right, but from following the link to the crash

And, no, I was not doing it right at all :-|
Blocks: 900248
Attachment #8337937 - Flags: review?(matt.woodrow)
Attachment #8337937 - Flags: review?(matt.woodrow) → review+
https://hg.mozilla.org/mozilla-central/rev/4fa706cb38bb
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
no longer crashing on builds beyond 20131126
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.