1228133 - Crash in mozilla::layers::CompositorParent::GetAPZCTreeManager(unsigned __int64)

Status: RESOLVED FIXED

(Core :: Panning and Zooming, defect)

Description

[Mark Straver]

Nightly 45.0a1 (2015-11-25)

Crash occurred when scrolling.

Hardware: ATI/AMD HD6870, Catalyst 15.7, APZ enabled.

Comment 1

[u279076]

Stack:
0 	xul.dll 	mozilla::layers::CompositorParent::GetAPZCTreeManager(unsigned __int64) 	gfx/layers/ipc/CompositorParent.cpp
1 	xul.dll 	mozilla::layout::RenderFrameParent::GetApzcTreeManager() 	layout/ipc/RenderFrameParent.cpp
2 	xul.dll 	mozilla::layout::RenderFrameParent::UpdateZoomConstraints(unsigned int, unsigned __int64, mozilla::Maybe<mozilla::layers::ZoomConstraints> const&) 	layout/ipc/RenderFrameParent.cpp
3 	xul.dll 	mozilla::dom::TabParent::RecvUpdateZoomConstraints(unsigned int const&, unsigned __int64 const&, mozilla::Maybe<mozilla::layers::ZoomConstraints> const&) 	dom/ipc/TabParent.cpp
4 	xul.dll 	mozilla::dom::PBrowserParent::OnMessageReceived(IPC::Message const&) 	obj-firefox/ipc/ipdl/PBrowserParent.cpp
5 	xul.dll 	mozilla::dom::PContentParent::OnMessageReceived(IPC::Message const&) 	obj-firefox/ipc/ipdl/PContentParent.cpp
6 	xul.dll 	mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) 	ipc/glue/MessageChannel.cpp
7 	xul.dll 	mozilla::ipc::MessageChannel::DispatchMessageW(IPC::Message const&) 	ipc/glue/MessageChannel.cpp
8 	xul.dll 	mozilla::ipc::MessageChannel::OnMaybeDequeueOne() 	ipc/glue/MessageChannel.cpp
9 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc
10 	xul.dll 	mozilla::ipc::DoWorkRunnable::Run() 	ipc/glue/MessagePump.cpp
11 	xul.dll 	nsThread::ProcessNextEvent(bool, bool*) 	xpcom/threads/nsThread.cpp
12 	xul.dll 	mozilla::net::nsHttpConnectionMgr::Shutdown() 	netwerk/protocol/http/nsHttpConnectionMgr.cpp
13 	xul.dll 	mozilla::net::nsHttpHandler::Observe(nsISupports*, char const*, wchar_t const*) 	netwerk/protocol/http/nsHttpHandler.cpp
14 	xul.dll 	nsObserverList::NotifyObservers(nsISupports*, char const*, wchar_t const*) 	xpcom/ds/nsObserverList.cpp
15 	xul.dll 	nsObserverService::NotifyObservers(nsISupports*, char const*, wchar_t const*) 	xpcom/ds/nsObserverService.cpp
16 	xul.dll 	nsXREDirProvider::DoShutdown() 	toolkit/xre/nsXREDirProvider.cpp
17 	xul.dll 	ScopedXPCOMStartup::~ScopedXPCOMStartup() 	toolkit/xre/nsAppRunner.cpp
18 	xul.dll 	mozilla::UniquePtr<ScopedXPCOMStartup, mozilla::DefaultDelete<ScopedXPCOMStartup> >::reset(ScopedXPCOMStartup*) 	mfbt/UniquePtr.h
19 	xul.dll 	XREMain::XRE_main(int, char** const, nsXREAppData const*) 	toolkit/xre/nsAppRunner.cpp
20 	xul.dll 	XRE_main 	toolkit/xre/nsAppRunner.cpp
21 	firefox.exe 	do_main 	browser/app/nsBrowserApp.cpp
22 	firefox.exe 	NS_internal_main(int, char**) 	browser/app/nsBrowserApp.cpp
23 	firefox.exe 	wmain 	toolkit/xre/nsWindowsWMain.cpp
24 	firefox.exe 	__tmainCRTStartup 	f:/dd/vctools/crt/crtw32/startup/crt0.c:255
25 	kernel32.dll 	BaseThreadInitThunk 	
26 	ntdll.dll 	__RtlUserThreadStart 	
27 	ntdll.dll 	_RtlUserThreadStart 	

There's only 2 reports so it doesn't appear to be highly reproducible. Mark, do you have steps to reproduce this crash?

Comment 2

[Kartikaya Gupta (email:[e-mail])]

Can you describe a bit more about what you were doing? Specifically:
- was the browser window open for a while already? According to the crash report the browser was up for 154 seconds, but not sure if you opened a new window just before the crash or not
- did you open/close/switch tabs just before it crashed? or were you just merrily scrolling down a page when it crashed?

Comment 3

[Mark Straver]

This was part of testing out a few different scenarios investigating bugs 1227799 and 1227971, hence the short uptime. At the time, there were 2 open windows (both restored from session), I switched tabs relatively short (<10 seconds) before the crash happened, and the second window was in the background where it was restored as part of the saved session. 
I was simply scrolling down a large page (all-text phpbb forum page, not media heavy) and it crashed without any clear indication or obvious reason.

Comment 4

[Mark Straver]

Anthony: I don't have any steps to reproduce, it seems to be relatively rare and only happened once so far for me.

Comment 5

[Kartikaya Gupta (email:[e-mail])]

Thanks for the additional info. I took another look at the relevant code and don't see why this could be happening. However we do have this crashes happening intermittently in our automation setup so I'll make a build with more logging and run it through there until it crashes. Hopefully that will shed more light on the problem.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

I did a try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=48366d3ad5f4&selectedJob=14164207 and the logging there seems to indicate a race between EraseLayerState and GetAPZCTreeManager. The EraseLayerState function gets called on the same id while we're in the middle of GetAPZCTreeManager, and so GetAPZCTreeManager ends up accessing a bad pointer. I'll do another try push with more locking to see if that fixes the problem.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

Try push at https://treeherder.mozilla.org/#/jobs?repo=try&revision=f0a9786f615a&group_state=expanded is looking promising...

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Attachment: Patch

https://treeherder.mozilla.org/#/jobs?repo=try&revision=3b53d453a052

Comment 9

[Pulsebot]

https://hg.mozilla.org/integration/mozilla-inbound/rev/d28a15be2c51

Comment 10

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/d28a15be2c51