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: 18.104.22.16832 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
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?
My changes to IPDL/IPC cross thread shutdown doesn't match this range/timeframe/signature.
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.
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?
(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.
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.
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.
(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.
I'll wager a beer that this is the thumbnailer content process.
Which landed on m-c 2013-07-23 17:47:04 PDT. Let's blame that!
I can't find any recent crash reports with this signature.
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.