898825 - crash in mozilla::layers::CrossProcessCompositorParent::AllocPLayerTransactionParent

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Scoobidiver (away)]

It started spiking in 25.0a1/20130724. The regression range for the spike is:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=5ceea82a79c7&tochange=2983ca6d4d1a
It might be a regression from bug 884061.

Signature 	mozilla::layers::CrossProcessCompositorParent::AllocPLayerTransactionParent(mozilla::layers::LayersBackend const&, unsigned __int64 const&, mozilla::layers::TextureFactoryIdentifier*) More Reports Search
UUID 	f21affd0-bc99-49af-963d-736532130727
Date Processed	2013-07-27 19:18:04.037001
Uptime	6
Last Crash	15 seconds before submission
Install Age 	13828 since version was first installed.
Install Time 	2013-07-27 15:27:33
Product 	Firefox
Version 	25.0a1
Build ID 	20130727030206
Release Channel 	nightly
OS 	Windows NT
OS Version 	6.3.9431
Build Architecture 	x86
Build Architecture Info 	GenuineIntel family 6 model 42 stepping 7 | 4
Crash Reason 	EXCEPTION_ACCESS_VIOLATION_READ
Crash Address 	0x0
App Notes 	
AdapterVendorID: 0x8086, AdapterDeviceID: 0x0116, AdapterSubsysID: 04931028, AdapterDriverVersion: 9.17.10.2932
D2D? D2D+ DWrite? DWrite+ D3D10 Layers? D3D10 Layers+ 

Frame 	Module 	Signature 	Source
0 	xul.dll 	mozilla::layers::CrossProcessCompositorParent::AllocPLayerTransactionParent(mozilla::layers::LayersBackend const &,unsigned __int64 const &,mozilla::layers::TextureFactoryIdentifier *) 	gfx/layers/ipc/CompositorParent.cpp
1 	xul.dll 	mozilla::layers::PCompositorParent::OnMessageReceived(IPC::Message const &,IPC::Message * &) 	obj-firefox/ipc/ipdl/PCompositorParent.cpp
2 	xul.dll 	mozilla::ipc::SyncChannel::OnDispatchMessage(IPC::Message const &) 	ipc/glue/SyncChannel.cpp
3 	xul.dll 	mozilla::ipc::RPCChannel::OnMaybeDequeueOne() 	ipc/glue/RPCChannel.cpp
4 	xul.dll 	MessageLoop::RunTask(Task *) 	ipc/chromium/src/base/message_loop.cc
5 	xul.dll 	MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const &) 	ipc/chromium/src/base/message_loop.cc
6 	xul.dll 	MessageLoop::DoWork() 	ipc/chromium/src/base/message_loop.cc
7 	xul.dll 	base::MessagePumpDefault::Run(base::MessagePump::Delegate *) 	ipc/chromium/src/base/message_pump_default.cc
8 	xul.dll 	MessageLoop::RunHandler() 	ipc/chromium/src/base/message_loop.cc
9 	xul.dll 	MessageLoop::Run() 	ipc/chromium/src/base/message_loop.cc
10 	xul.dll 	base::Thread::ThreadMain() 	ipc/chromium/src/base/thread.cc
11 	xul.dll 	`anonymous namespace'::ThreadFunc(void *) 	tools/profiler/platform-win32.cc
12 	kernel32.dll 	kernel32.dll@0x1a55e 	
13 	ntdll.dll 	ntdll.dll@0x48f03 	
14 	ntdll.dll 	ntdll.dll@0x48ed9

More reports at:
https://crash-stats.mozilla.com/report/list?product=Firefox&signature=mozilla%3A%3Alayers%3A%3ACrossProcessCompositorParent%3A%3AAllocPLayerTransactionParent%28mozilla%3A%3Alayers%3A%3ALayersBackend+const%26%2C+unsigned+__int64+const%26%2C+mozilla%3A%3Alayers%3A%3ATextureFactoryIdentifier*%29

Comment 1

[Benjamin Smedberg]

I don't see other obvious candidates in the regression range. jcranmer can you check the Atomic patches to see if any changes in IPDL/IPC might affect this?

Comment 2

[Benoit Girard (:BenWa)]

My changes to IPDL/IPC cross thread shutdown doesn't match this range/timeframe/signature.

Comment 3

[Joshua Cranmer [:jcranmer]]

The only changes to IPC code itself are in this changeset: <https://hg.mozilla.org/mozilla-central/rev/ed39337cc38f>. RPCChannel::RefCountedTask itself changes from manual thread-safe refcounts to NS_INLINE_DECL_THREADSAFE_REFCOUNTING. As the inline threadsafe refcounting also doesn't do refcount stabilization, I don't see any of those changes directly causing the issue.

Comment 4

[Benjamin Smedberg]

jcranmer/benwa: where does that leave us with actually fixing the crash here, or at least finding an owner for it? We could just back out bug 884061. Benwa, did you look through the regression range for anything related to OMTC that I might have missed, or is there somebody else who can help from the graphics team?

Comment 5

[Joshua Cranmer [:jcranmer]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> jcranmer/benwa: where does that leave us with actually fixing the crash
> here, or at least finding an owner for it? We could just back out bug
> 884061. Benwa, did you look through the regression range for anything
> related to OMTC that I might have missed, or is there somebody else who can
> help from the graphics team?

It would be helpful if the regression range could be targetted to a specific revision (all intermediate revisions of bug 884061 should be able to produce a viable build--I'm a stickler for making that work in my patch queues). It's possible that a change in another patch ended up causing the regression, which is part of the reason why I kept the semi-automatic change as 26 patches and not one giant patch.

Comment 6

[Joshua Cranmer [:jcranmer]]

Another possibility, which I'm really not looking forward to trying to debug, is the possibility that mozilla/Atomics.h is actually incorrectly written, particularly on our Windows builds.

Comment 7

[Benjamin Smedberg]

I'm not sure what you're asking for. This bug was filed based on crash report volumes. We don't have specific steps to reproduce, so even with the intermediate builds I'm not sure what we'd do next.

Comment 8

[Benoit Girard (:BenWa)]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #4)
> jcranmer/benwa: where does that leave us with actually fixing the crash
> here, or at least finding an owner for it? We could just back out bug
> 884061. Benwa, did you look through the regression range for anything
> related to OMTC that I might have missed, or is there somebody else who can
> help from the graphics team?

The configuration isn't something I'm familiar with. We're receiving a sync PLayerTransaction but no other thread in the main process is awaiting the response and we're allocating a CrossProcessCompositorParent on a crash like 'e56c99ab-52d8-41fb-b2bb-b54bd2130725' on windows 7 (this excludes metro AFAIK). So I don't know what piece of coding is even running. It's some form of e10s that's running.

Comment 9

[Benjamin Smedberg]

I'll wager a beer that this is the thumbnailer content process.

Comment 10

[Benjamin Smedberg]

Which landed on m-c 2013-07-23 17:47:04 PDT. Let's blame that!

Comment 11

[:Gavin Sharp [email: [e-mail]]]

I can't find any recent crash reports with this signature.