989567 - [e10s] Assertion in CrossProcessCompositorParent::DeferredDestroy

Status: RESOLVED WORKSFORME

(Core :: Graphics: Layers, defect)

Description

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Between March 19 and March 27, we began to get this failure while running mochitests in e10s mode.

https://tbpl.mozilla.org/php/getParsedLog.php?id=36906265&tree=Holly&full=1#error0

The top stack frames look like this:

Assertion failure: (((bool)(__builtin_expect(!!(!NS_FAILED_impl(NS_DispatchToMainThread(runnable))), 1)))), at /builds/slave/h-lx-d-00000000000000000000000/build/gfx/layers/ipc/CompositorParent.cpp:1283
TEST-INFO | Main app process: killed by SIGSEGV
TEST-UNEXPECTED-FAIL | Shutdown | application terminated with exit code 11
INFO | runtests.py | Application ran for: 0:12:57.920086
INFO | zombiecheck | Reading PID log: /tmp/tmpaSkJBepidlog
==> process 2444 launched child process 2483
INFO | zombiecheck | Checking for orphan process with PID: 2483
PROCESS-CRASH | Shutdown | application crashed [@ mozilla::layers::CrossProcessCompositorParent::DeferredDestroy()]
Crash dump filename: /tmp/tmpz2AIAG/minidumps/7fcd8608-529d-970f-49b42ac1-7edfeb45.dmp
Operating system: Linux
                  0.0.0 Linux 3.2.0-23-generic-pae #36-Ubuntu SMP Tue Apr 10 22:19:09 UTC 2012 i686
CPU: x86
     GenuineIntel family 6 model 44 stepping 2
     1 CPU
Crash reason:  SIGSEGV
Crash address: 0x0
Thread 9 (crashed)
 0  libxul.so!mozilla::layers::CrossProcessCompositorParent::DeferredDestroy() [CompositorParent.cpp:b525fd1e4fbf : 1283 + 0x2c]
    eip = 0xb30f3394   esp = 0x9cdfdff0   ebp = 0x9cdfe028   ebx = 0xb6b5e7b4
    esi = 0x9cdfe00c   edi = 0x0ac06d38   eax = 0x00000000   ecx = 0xb758b8ac
    edx = 0x00000000   efl = 0x00210282
    Found by: given as instruction pointer in context
 1  libxul.so!RunnableMethod<mozilla::layers::CrossProcessCompositorParent, void (mozilla::layers::CrossProcessCompositorParent::*)(), Tuple0>::Run() [tuple.h:b525fd1e4fbf : 383 + 0x12]
    eip = 0xb30f0ae6   esp = 0x9cdfe030   ebp = 0x9cdfe048   ebx = 0xb6b5e7b4
    esi = 0x094ed018   edi = 0x9cdfe210
    Found by: call frame info
 2  libxul.so!MessageLoop::RunTask(Task*) [message_loop.cc:b525fd1e4fbf : 344 + 0x8]
    eip = 0xb2ca4256   esp = 0x9cdfe050   ebp = 0x9cdfe088   ebx = 0xb6b5e7b4
    esi = 0x094ed018   edi = 0x9cdfe210
    Found by: call frame info

It looks like this code was added in bug 976479. That bug mentions that we might have problems at shutdown if we're not allowed to dispatch to the main thread anymore. I suspect that's what's going on here. There's a pointer to bug 924622, but I'm not sure what the proposal is there.

Blake, Ben, what are our options here? This is happening maybe half the time on Holly.

Comment 1

[Ben Turner (not reading bugmail, use the needinfo flag!)]

I think our only option is to replace the MOZ_ALWAYS_TRUE(...) with a NS_WARN_IF(!...) for now. That would leak the CompositorParent though.

Bug 924622 proposes to have a defined shutdown sequence for the compositor stuff (I think). That would presumably fix this bug by making us always able to close down when inter-thread dispatch is still allowed.

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Unfortunately, leaking is no better than asserting from the "is it orange" perspective. I'll try to see about bug 924622.

Comment 3

[Benoit Girard (:BenWa)]

Then we should have the main thread sync wait for the CompositorParent to shutdown.

Comment 4

[Mason Chang [Inactive] [:mchang]]

Hi Bill, do you know if this is still an issue? Thanks!

Comment 5

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

No, this is fixed now.