I'm able to intermittently reproduce a crash while in the browser on B2G master (I have some local patches applied locally from bug 898443 and bug 906427). Rough STR: 1. Load https://people.mozilla.com/~kgupta/tmp/iframe.html 2. Pinch zoom in 3. Scroll around The crash is in the root process, I have attached the backtrace.

See the same crash on a nexus4 when I open a smart collection: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 3024.3065] 0xb5bc2882 in mozalloc_abort (msg=<optimized out>) at ../../../memory/mozalloc/mozalloc_abort.cpp:30 30 MOZ_CRASH(); (gdb) bt #0 0xb5bc2882 in mozalloc_abort (msg=<optimized out>) at ../../../memory/mozalloc/mozalloc_abort.cpp:30 #1 0xb534454e in Abort (aMsg=0xb05ff804 "[Parent 3024] ###!!! ABORT: bad Shmem: file PLayerTransactionParent.cpp, line 740") at ../../../xpcom/base/nsDebugImpl.cpp:430 #2 NS_DebugBreak (aSeverity=<optimized out>, aStr=0xb5e5f334 "bad Shmem", aExpr=0x0, aFile=0xb5e7bf9b "PLayerTransactionParent.cpp", aLine=740) at ../../../xpcom/base/nsDebugImpl.cpp:417 #3 0xb50b30d2 in mozilla::layers::PLayerTransactionParent::DeallocShmem (this=<optimized out>, aMem=...) at PLayerTransactionParent.cpp:740 #4 0xb53d2516 in mozilla::layers::ShmemTextureHost::DeallocateSharedData (this=<optimized out>) at ../../../gfx/layers/composite/TextureHost.cpp:512 #5 0xb53a985c in mozilla::layers::CompositableHost::~CompositableHost (this=0xadb72080, __in_chrg=<optimized out>) at ../../../gfx/layers/composite/CompositableHost.cpp:43 #6 0xb53bdbf8 in mozilla::layers::ImageHost::~ImageHost (this=0xadb72080, __in_chrg=<optimized out>) at ../../../gfx/layers/composite/ImageHost.cpp:37 #7 0xb53bdc08 in mozilla::layers::ImageHost::~ImageHost (this=0xadb72080, __in_chrg=<optimized out>) at ../../../gfx/layers/composite/ImageHost.cpp:37 #8 0xb53a3fba in Release (this=<optimized out>) at ../../dist/include/mozilla/RefPtr.h:82 #9 mozilla::RefPtr<mozilla::layers::CompositableHost>::unref (t=<optimized out>) at ../../dist/include/mozilla/RefPtr.h:203 #10 0xb53a9db2 in ~RefPtr (this=0xadb6cadc, __in_chrg=<optimized out>) at ../../dist/include/mozilla/RefPtr.h:153 #11 mozilla::layers::CompositableParent::~CompositableParent (this=0xadb6cac0, __in_chrg=<optimized out>) at ../../../gfx/layers/composite/CompositableHost.cpp:260 #12 0xb53a9dcc in mozilla::layers::CompositableParent::~CompositableParent (this=0xadb6cac0, __in_chrg=<optimized out>) at ../../../gfx/layers/composite/CompositableHost.cpp:260 #13 0xb46f25c4 in mozilla::net::NeckoParent::DeallocPCookieServiceParent (this=<optimized out>, cs=<optimized out>) at ../../../netwerk/ipc/NeckoParent.cpp:507 #14 0xb50bca3a in mozilla::layers::PLayerTransactionParent::DeallocSubtree (this=0xaec58880) at PLayerTransactionParent.cpp:808 #15 0xb505db64 in mozilla::layers::PCompositorParent::DeallocSubtree (this=0xb03e9f30) at PCompositorParent.cpp:810 #16 0xb505dbfa in mozilla::layers::PCompositorParent::OnChannelError (this=0xb03e9f30) at PCompositorParent.cpp:685 #17 0xb503d0de in mozilla::ipc::MessageChannel::NotifyMaybeChannelError (this=0xb03e9f60) at ../../../ipc/glue/MessageChannel.cpp:1370 #18 0xb503d866 in mozilla::ipc::MessageChannel::OnNotifyMaybeChannelError (this=0xb03e9f60) at ../../../ipc/glue/MessageChannel.cpp:1399 #19 0xb4b1f54e in DispatchToMethod<WebCore::ReverbConvolver, void (WebCore::ReverbConvolver::*)()> (method= (void (WebCore::ReverbConvolver::*)(WebCore::ReverbConvolver * const)) 0xb503d7f1 <mozilla::ipc::MessageChannel::OnNotifyMaybeChannelError()>, obj=<optimized out>, arg=<optimized out>) at ../../../../../ipc/chromium/src/base/tuple.h:383 #20 RunnableMethod<WebCore::ReverbConvolver, void (WebCore::ReverbConvolver::*)(), Tuple0>::Run (this=<optimized out>) at ../../../../../ipc/chromium/src/base/task.h:307 #21 0xb535f228 in MessageLoop::RunTask (this=0xb05ffde8, task=0xadda8980) at ../../../ipc/chromium/src/base/message_loop.cc:338 #22 0xb535fac6 in MessageLoop::DeferOrRunPendingTask (this=<optimized out>, pending_task=<optimized out>) at ../../../ipc/chromium/src/base/message_loop.cc:346 #23 0xb5360bba in DoWork (this=<optimized out>) at ../../../ipc/chromium/src/base/message_loop.cc:446 #24 MessageLoop::DoWork (this=0xb05ffde8) at ../../../ipc/chromium/src/base/message_loop.cc:425 #25 0xb5360d80 in base::MessagePumpDefault::Run (this=0xb0d782e0, delegate=0xb05ffde8) at ../../../ipc/chromium/src/base/message_pump_default.cc:24 #26 0xb535f36e in MessageLoop::RunInternal (this=0xb05ffde8) at ../../../ipc/chromium/src/base/message_loop.cc:220 #27 0xb535f386 in RunHandler (this=0xb05ffde8) at ../../../ipc/chromium/src/base/message_loop.cc:213 #28 MessageLoop::Run (this=0xb05ffde8) at ../../../ipc/chromium/src/base/message_loop.cc:187 #29 0xb5362af0 in base::Thread::ThreadMain (this=0xb0d791f0) at ../../../ipc/chromium/src/base/thread.cc:160 #30 0xb536450c in ThreadFunc (closure=<optimized out>) at ../../../ipc/chromium/src/base/platform_thread_posix.cc:39 #31 0xb6f4aa5c in __thread_entry (func=0xb5364505 <ThreadFunc(void*)>, arg=0xb0d791f0, tls=0xb05fff00) at bionic/libc/bionic/pthread_create.cpp:92 #32 0xb6f4abd8 in pthread_create (thread_out=0xb0d791f8, attr=<optimized out>, start_routine=0x78, arg=0xb0d791f0) at bionic/libc/bionic/pthread_create.cpp:201 #33 0x00000000 in ?? ()

Also seen in debug emulator tests. https://tbpl.mozilla.org/php/getParsedLog.php?id=29957373&tree=Pine&full=1#error6

Nical, what could be causing this assert?

The shmem is deallocated twice which is obvisously bad. Shmem is a bit special because IPDL is trying to be smart about it and deallocates it internally when IPC is disconnected. When that happens we don't really get notified so it's our responsibility to carefully listen to IPC disconnections with ActorDestroy and forget our references to (now dangling) shmems. * So, it could be that the shmem is being automatically deallocated because something IPC related happened, but we did not see it coming and we try to deallocate it ourselves using the normal shutdown path. * Or, it could just be that something is messed up in the deallocation sequence and that we run into a case where both the client side and the host side try to deallocate the shmem.

If there is any justice in the world, then this should be fixed by the third patch in bug 907463. No promises though. I reckon it should be worth trying. Of course landing those patches is another story, but hopefully I'll manage soon...

(In reply to Nick Cameron [:nrc] from comment #5) > If there is any justice in the world, then this should be fixed by the third > patch in bug 907463. No promises though. I reckon it should be worth trying. > Of course landing those patches is another story, but hopefully I'll manage > soon... Feel free to test your patch on 'pine' where we run those debug tests.

Is this still reproducing? I suspect it has been fixed along with bug 907463.

I was only seeing it intermittently anyway so I won't be able to confirm. Do the debug tests on pine provide confirmation one way or another?

I think it has been fixed, please reopen if this i am wrong.