Closed Bug 983489 Opened 10 years ago Closed 10 years ago

Crash on nsIAppStartup.quit() - application crashed [@ mozilla::gl::GLContext::MakeCurrent(bool)]

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla32
tracking-b2g backlog
Tracking Status
e10s - ---

People

(Reporter: vichen, Assigned: vichen)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 7 obsolete files)

https://tbpl.mozilla.org/?tree=Try&rev=bfe897476327

Summary

PROCESS-CRASH | Shutdown | application crashed [@ mozilla::gl::GLContext::MakeCurrent(bool)]
Return code: 1
AttributeError: GzipFile instance has no attribute '__exit__'
Return code: 1
Blocks: B2GRT
Full stack:

06:18:50     INFO -  Operating system: Android
06:18:50     INFO -                    0.0.0 Linux 2.6.29-00302-g586075d #31 Mon Feb 24 10:28:23 PST 2014 armv7l Android/full/generic:4.0.4.0.4.0.4/OPENMASTER/eng.cltbld.20140313.071241:eng/test-keys
06:18:50     INFO -  CPU: arm
06:18:50     INFO -       0 CPUs
06:18:50     INFO -  Crash reason:  SIGSEGV
06:18:50     INFO -  Crash address: 0x218
06:18:50     INFO -  Thread 20 (crashed)
06:18:50     INFO -   0  libxul.so!mozilla::gl::GLContext::MakeCurrent(bool) [GLContext.h:bfe897476327 : 2514 + 0x0]
06:18:50     INFO -       r4 = 0x44df4eb0    r5 = 0x44df4e74    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffba0    lr = 0x40fa4a5b    pc = 0x40f3680e
06:18:50     INFO -      Found by: given as instruction pointer in context
06:18:50     INFO -   1  libxul.so!mozilla::layers::GrallocTextureSourceOGL::DeallocateDeviceData() [GrallocTextureHost.cpp:bfe897476327 : 268 + 0x3]
06:18:50     INFO -       r4 = 0x44df4eb0    r5 = 0x44df4e74    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffba8    pc = 0x40fa4a5b
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   2  libxul.so!mozilla::layers::GrallocTextureHostOGL::DeallocateDeviceData() [GrallocTextureHost.cpp:bfe897476327 : 365 + 0x5]
06:18:50     INFO -       r4 = 0x44df4e80    r5 = 0x44df4e74    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffbb0    pc = 0x40fa45ff
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   3  libxul.so!mozilla::layers::TextureHost::Finalize() [TextureHost.cpp:bfe897476327 : 282 + 0x7]
06:18:50     INFO -       r4 = 0x44df4e80    r5 = 0x44df4e74    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffbb8    pc = 0x40f90399
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   4  libxul.so!mozilla::RefPtr<mozilla::layers::TextureHost>::operator=(mozilla::layers::TextureHost*) [AtomicRefCountedWithFinalize.h : 42 + 0x5]
06:18:50     INFO -       r4 = 0x44df4e80    r5 = 0x44df4e74    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffbc0    pc = 0x40f8d4fd
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   5  libxul.so!mozilla::layers::TextureParent::ActorDestroy(mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::ActorDestroyReason) [TextureHost.cpp:bfe897476327 : 833 + 0x3]
06:18:50     INFO -       r4 = 0x44df4e50    r5 = 0x00000001    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffbd0    pc = 0x40f90597
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   6  libxul.so!mozilla::docshell::POfflineCacheUpdateChild::DestroySubtree(mozilla::ipc::IProtocolManager<mozilla::ipc::IProtocol>::ActorDestroyReason) [POfflineCacheUpdateChild.cpp : 388 + 0x9]
06:18:50     INFO -       r4 = 0x44df4e50    r5 = 0x00000001    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffbe0    pc = 0x40d6709d
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   7  libxul.so!mozilla::layers::PTextureParent::Send__delete__(mozilla::layers::PTextureParent*) [PTextureParent.cpp : 69 + 0x5]
06:18:50     INFO -       r4 = 0x44df4e50    r5 = 0x00000001    r6 = 0x00000000    r7 = 0x00840001
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffbf0    pc = 0x40e03caf
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   8  libxul.so!mozilla::layers::TextureParent::RecvRemoveTexture() + 0x5
06:18:50     INFO -       r4 = 0x44df4e50    r5 = 0x00840005    r6 = 0x453ffd00    r7 = 0x44274270
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffc20    pc = 0x40f9060b
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -   9  libxul.so!mozilla::layers::PTextureParent::OnMessageReceived(IPC::Message const&) [PTextureParent.cpp : 217 + 0x7]
06:18:50     INFO -       r4 = 0x44df4e50    r5 = 0x00840005    r6 = 0x453ffd00    r7 = 0x44274270
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffc28    pc = 0x40e026d3
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  10  libxul.so!mozilla::layers::PCompositorParent::OnMessageReceived(IPC::Message const&) [PCompositorParent.cpp : 373 + 0x7]
06:18:50     INFO -       r4 = 0x44de26a0    r5 = 0x453ffcdc    r6 = 0x453ffd00    r7 = 0x44274270
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffc50    pc = 0x40d8559d
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  11  libxul.so!mozilla::ipc::MessageChannel::DispatchAsyncMessage(IPC::Message const&) [MessageChannel.cpp:bfe897476327 : 1142 + 0x5]
06:18:50     INFO -       r4 = 0x44de26d0    r5 = 0x453ffcdc    r6 = 0x453ffd00    r7 = 0x44274270
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffcb8    pc = 0x40d61e7f
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  12  libxul.so!mozilla::ipc::MessageChannel::DispatchMessage(IPC::Message const&) [MessageChannel.cpp:bfe897476327 : 1056 + 0x3]
06:18:50     INFO -       r4 = 0x00000001    r5 = 0x453ffcdc    r6 = 0x453ffd00    r7 = 0x44274270
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffcd0    pc = 0x40d63abf
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  13  libxul.so!mozilla::ipc::MessageChannel::OnMaybeDequeueOne() [MessageChannel.cpp:bfe897476327 : 1039 + 0x3]
06:18:50     INFO -       r4 = 0x00000001    r5 = 0x453ffcdc    r6 = 0x453ffd00    r7 = 0x44274270
06:18:50     INFO -       r8 = 0x44274270    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffcd8    pc = 0x40d63b57
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  14  libxul.so!RunnableMethod<WebCore::ReverbConvolver, void (WebCore::ReverbConvolver::*)(), Tuple0>::Run() [tuple.h:bfe897476327 : 383 + 0x5]
06:18:50     INFO -       r4 = 0x453ffde4    r5 = 0x402dd968    r6 = 0x453ffd58    r7 = 0x453ffdf0
06:18:50     INFO -       r8 = 0x453ffd50    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffd20    pc = 0x40d61bf7
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  15  libxul.so!mozilla::ipc::MessageChannel::DequeueTask::Run() [MessageChannel.h : 383 + 0x9]
06:18:50     INFO -       r4 = 0x453ffde4    r5 = 0x402dd968    r6 = 0x453ffd58    r7 = 0x453ffdf0
06:18:50     INFO -       r8 = 0x453ffd50    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffd28    pc = 0x40d61b19
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  16  libxul.so!MessageLoop::RunTask(Task*) [message_loop.cc:bfe897476327 : 344 + 0x5]
06:18:50     INFO -       r4 = 0x453ffde4    r5 = 0x402dd968    r6 = 0x453ffd58    r7 = 0x453ffdf0
06:18:50     INFO -       r8 = 0x453ffd50    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffd30    pc = 0x40d58f19
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  17  libxul.so!MessageLoop::DeferOrRunPendingTask(MessageLoop::PendingTask const&) [message_loop.cc:bfe897476327 : 352 + 0x5]
06:18:50     INFO -       r4 = 0x00000001    r5 = 0x453ffd48    r6 = 0x453ffd58    r7 = 0x453ffdf0
06:18:50     INFO -       r8 = 0x453ffd50    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffd40    pc = 0x40d59c7b
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  18  libxul.so!MessageLoop::DoWork() [message_loop.cc:bfe897476327 : 430 + 0x7]
06:18:50     INFO -       r4 = 0x453ffde4    r5 = 0x453ffd48    r6 = 0x453ffd58    r7 = 0x453ffdf0
06:18:50     INFO -       r8 = 0x453ffd50    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffd48    pc = 0x40d5a839
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  19  libxul.so!base::MessagePumpDefault::Run(base::MessagePump::Delegate*) [message_pump_default.cc:bfe897476327 : 34 + 0x7]
06:18:50     INFO -       r4 = 0x44e9d600    r5 = 0x453ffde4    r6 = 0x453ffd94    r7 = 0x453ffd90
06:18:50     INFO -       r8 = 0x44e9d60c    r9 = 0x453ffd80   r10 = 0x00000000    fp = 0x453ffd88
06:18:50     INFO -       sp = 0x453ffd78    pc = 0x40d5abc7
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  20  libxul.so!MessageLoop::RunInternal() [message_loop.cc:bfe897476327 : 226 + 0x5]
06:18:50     INFO -       r4 = 0x453ffde4    r5 = 0x453ffde4    r6 = 0x453ffe76    r7 = 0x00000000
06:18:50     INFO -       r8 = 0x00000000    r9 = 0x44e97714   r10 = 0x00100000    fp = 0x00000001
06:18:50     INFO -       sp = 0x453ffdc0    pc = 0x40d58edd
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  21  libxul.so!MessageLoop::Run() [message_loop.cc:bfe897476327 : 219 + 0x5]
06:18:50     INFO -       r4 = 0x453ffde4    r5 = 0x453ffde4    r6 = 0x453ffe76    r7 = 0x00000000
06:18:50     INFO -       r8 = 0x00000000    r9 = 0x44e97714   r10 = 0x00100000    fp = 0x00000001
06:18:50     INFO -       sp = 0x453ffdc8    pc = 0x40d58f5b
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  22  libxul.so!base::Thread::ThreadMain() [thread.cc:bfe897476327 : 162 + 0x5]
06:18:50     INFO -       r4 = 0x44e97700    r5 = 0x453ffde4    r6 = 0x453ffe76    r7 = 0x00000000
06:18:50     INFO -       r8 = 0x00000000    r9 = 0x44e97714   r10 = 0x00100000    fp = 0x00000001
06:18:50     INFO -       sp = 0x453ffde0    pc = 0x40d5b96b
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  23  libxul.so!ThreadFunc [platform_thread_posix.cc:bfe897476327 : 39 + 0x5]
06:18:50     INFO -       r4 = 0x453fff00    r5 = 0x40d51759    r6 = 0x44e97700    r7 = 0x00000078
06:18:50     INFO -       r8 = 0x40d51759    r9 = 0x44e97700   r10 = 0x00100000    fp = 0x00000001
06:18:50     INFO -       sp = 0x453ffee8    pc = 0x40d51761
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  24  libc.so!__thread_entry [pthread.c : 217 + 0x6]
06:18:50     INFO -       r4 = 0x453fff00    r5 = 0x40d51759    r6 = 0x44e97700    r7 = 0x00000078
06:18:50     INFO -       r8 = 0x40d51759    r9 = 0x44e97700   r10 = 0x00100000    fp = 0x00000001
06:18:50     INFO -       sp = 0x453ffef0    pc = 0x40054e4c
06:18:50     INFO -      Found by: call frame info
06:18:50     INFO -  25  libc.so!pthread_create [pthread.c : 357 + 0xe]
06:18:50     INFO -       r4 = 0x453fff00    r5 = 0x00025d90    r6 = 0xbece30f8    r7 = 0x00000078
06:18:50     INFO -       r8 = 0x40d51759    r9 = 0x44e97700   r10 = 0x00100000    fp = 0x00000001
06:18:50     INFO -       sp = 0x453fff00    pc = 0x4005499c
06:18:50     INFO -      Found by: call frame info
Component: Reftest → Graphics: Layers
Product: Testing → Core
Assignee: nobody → hshih
Blocks: 969146
Attached patch Patch to reproduce (obsolete) — Splinter Review
Note this is not specific to reftests, it happens whenever nsIAppStartup.quit() is called in an emulator. To reproduce, apply this patch and run |mach mochitest-remote|
Crash Signature: [@ mozilla::gl::GLContext::MakeCurrent(bool)]
Summary: Crash at end of reftests - application crashed [@ mozilla::gl::GLContext::MakeCurrent(bool) → Crash on nsIAppStartup.quit() - application crashed [@ mozilla::gl::GLContext::MakeCurrent(bool)]
It seems that we call GrallocTextureSourceOGL::DeallocateDeviceData() after CompositorOGL::CleanupResources().

The gl context is null and we dereference this null ptr for MakeCurrent().
Milan, this is preventing us from making TBPL go orange on shutdown crashes since we'd be permanently orange.

Is this something your team could look into.
See Also: → 987251
Benoit, can you take a look at this?  Jerry, let us know if you've looked at this already, I didn't see any comments.
Assignee: hshih → bjacob
Flags: needinfo?(bjacob)
Blocks: 986113
We will check the bug 985773.
Maybe we have some problem for delete sequence in gfxPlatform::Shutdown()
Vincent Chen([:vichen]) is looking this problem now.
GLContext is released before Texture is released.
Wait result: https://tbpl.mozilla.org/?tree=Try&rev=b527e30e4264
Assignee: bjacob → vichen
Flags: needinfo?(bjacob)
Attached patch 983489.patch (obsolete) — Splinter Review
The crash happen when GLContext released before Texture is released. This patch re-order the release sequence.
Crash in buffer release is fixed, but another crash happen.
https://tbpl.mozilla.org/?tree=Try&rev=5e7a58e17e3a

23:26:09  WARNING -  PROCESS-CRASH | Shutdown | application crashed [Unknown top frame]
23:26:09     INFO -  Crash dump filename: /tmp/tmp5lZPug/2bae3694-f663-1620-7d030544-067ad376.dmp
23:26:09     INFO -  stderr from minidump_stackwalk:
23:26:09     INFO -  2014-03-27 23:26:09: minidump_processor.cc:264: INFO: Processing minidump in file /tmp/tmp5lZPug/2bae3694-f663-1620-7d030544-067ad376.dmp
23:26:09     INFO -  2014-03-27 23:26:09: minidump.cc:3815: INFO: Minidump opened minidump /tmp/tmp5lZPug/2bae3694-f663-1620-7d030544-067ad376.dmp
23:26:09     INFO -  2014-03-27 23:26:09: minidump.cc:3847: ERROR: Minidump header signature mismatch: (0x0, 0x0) != 0x504d444d
23:26:09     INFO -  2014-03-27 23:26:09: minidump_processor.cc:268: ERROR: Minidump /tmp/tmp5lZPug/2bae3694-f663-1620-7d030544-067ad376.dmp could not be read
23:26:09     INFO -  2014-03-27 23:26:09: minidump.cc:3787: INFO: Minidump closing minidump
23:26:09     INFO -  2014-03-27 23:26:09: minidump_stackwalk.cc:529: ERROR: MinidumpProcessor::Process failed
23:26:09     INFO -  minidump_stackwalk exited with return code 1
23:26:09     INFO -  WARNING | leakcheck | refcount logging is off, so leaks can't be detected!
23:26:09     INFO -  REFTEST INFO | runreftest.py | Running tests: end.
23:26:14    ERROR - Return code: 1
Result in local test:
Looks like Bug 987251

Crash reason:  SIGSEGV
Crash address: 0x5a5a5b4a

Thread 21 (crashed)
 0  libxul.so + 0x65a25c
     r4 = 0x4617bcc0    r5 = 0x00000000    r6 = 0x00000000    r7 = 0x455ffdf0
     r8 = 0x455ffd50    r9 = 0x455ffd80   r10 = 0x00000000    fp = 0x455ffd88
     sp = 0x455ffc88    lr = 0x410a225b    pc = 0x410a225c
    Found by: given as instruction pointer in context
 1  libxul.so + 0x65ab23
     sp = 0x455ffc98    pc = 0x410a2b25
    Found by: stack scanning
 2  libxul.so + 0x65ab7f
     sp = 0x455ffca8    pc = 0x410a2b81
    Found by: stack scanning
 3  libxul.so + 0x60e3f9
     sp = 0x455ffcb0    pc = 0x410563fb
    Found by: stack scanning
 4  libxul.so + 0x6693c9
     sp = 0x455ffcb8    pc = 0x410b13cb
    Found by: stack scanning
 5  libxul.so + 0x6693ef
     sp = 0x455ffcc0    pc = 0x410b13f1
    Found by: stack scanning
 6  libxul.so + 0x6645bd
     sp = 0x455ffcc8    pc = 0x410ac5bf
    Found by: stack scanning
 7  libxul.so + 0x6651b1
     sp = 0x455ffcd8    pc = 0x410ad1b3
    Found by: stack scanning
 8  libxul.so + 0x44cb59
     sp = 0x455ffce8    pc = 0x40e94b5b
    Found by: stack scanning
 9  libxul.so + 0x44cec7
     sp = 0x455ffcf8    pc = 0x40e94ec9
    Found by: stack scanning
10  libxul.so + 0x42a309
     sp = 0x455ffd00    pc = 0x40e7230b
    Found by: stack scanning
11  libxul.so + 0x42abd1
     sp = 0x455ffd08    pc = 0x40e72bd3
    Found by: stack scanning
12  libxul.so + 0x42ab6f
     sp = 0x455ffd18    pc = 0x40e72b71
    Found by: stack scanning
13  libxul.so + 0x2cae9d
     sp = 0x455ffd28    pc = 0x40d12e9f
    Found by: stack scanning
14  libxul.so + 0x42163f
     sp = 0x455ffd30    pc = 0x40e69641
    Found by: stack scanning
15  libxul.so + 0x4223a1
     sp = 0x455ffd40    pc = 0x40e6a3a3
    Found by: stack scanning
16  libxul.so + 0x422f5f
     sp = 0x455ffd48    pc = 0x40e6af61
    Found by: stack scanning
17  libxul.so + 0x4232ed
     sp = 0x455ffd78    pc = 0x40e6b2ef
    Found by: stack scanning
18  libxul.so + 0x421603
     sp = 0x455ffdc0    pc = 0x40e69605
    Found by: stack scanning
19  libxul.so + 0x421681
     sp = 0x455ffdc8    pc = 0x40e69683
    Found by: stack scanning
20  libxul.so + 0x424091
     sp = 0x455ffde0    pc = 0x40e6c093
    Found by: stack scanning
21  libxul.so + 0x1947ffe
     sp = 0x455ffde8    pc = 0x42390000
    Found by: stack scanning
(In reply to Vincent Chen [:vichen] from comment #11)
> Result in local test:
> Looks like Bug 987251

FYI, if you're trying to reproduce locally, do a "./build.sh buildsymbols" first so you get function names in your stack traces.
This blocks a blocker.
blocking-b2g: --- → 1.4?
This bug is fixed, but it crashed at another point randomly (same as Bug 987251).
https://tbpl.mozilla.org/?tree=Try&rev=03e110fde6b3
1.4+ this blocks a blocker
blocking-b2g: 1.4? → 1.4+
There are a number of bugs that came in with requests to support better debugging on the emulator. This came in unexpected, and I need to escalate this if it is to be done in 1.4 timeframe, as it will completely mess up the 2.0 plans.  Stay tuned.
Comment on attachment 8397713 [details] [diff] [review]
983489.patch

Review of attachment 8397713 [details] [diff] [review]:
-----------------------------------------------------------------

If call SendWillStop() then Destroy() it will make GLContext being deleted before Texture and it crashed at end of reftest.
Please help to check if switch order is a proper solution.
It still crash somewhere else and I'm still to identify root cause.
Attachment #8397713 - Flags: review?(bas)
Attached patch 983489.patch (obsolete) — Splinter Review
The previous patch is obviously wrong. This patch prevent the crash by delay destruct mGLContext.
Attachment #8397713 - Attachment is obsolete: true
Attachment #8397713 - Flags: review?(bas)
Attached patch 983489.patch (obsolete) — Splinter Review
Root cause:
http://dxr.mozilla.org/mozilla-central/source/widget/xpwidgets/nsBaseWidget.cpp#177
mCompositorChild->SendWillStop(); will trigger CompositorParent RecvWillStop()
mCompositorChild->Destroy(); will trigger TextureParent to clean texture

In RecvWillStop() there are two point which will trigger CompositorOGL to destroy mGLContext and make TextureParent has no valid GLContext.

Solution:
Delay the time to destroy mGLContext, as mGLContext will be destroyed at destructor of CompositorOGL, so remove mCompositor = null in LayerManagerComposite.cpp and CompositorParent.cpp.
Attachment #8401640 - Attachment is obsolete: true
Attached patch 983489.patch (obsolete) — Splinter Review
Attachment #8403118 - Attachment is obsolete: true
Blocks: 922680
Comment on attachment 8403724 [details] [diff] [review]
983489.patch

Review of attachment 8403724 [details] [diff] [review]:
-----------------------------------------------------------------

Please refer: https://bugzilla.mozilla.org/show_bug.cgi?id=922680#c97 and https://bugzilla.mozilla.org/show_bug.cgi?id=983489#c19
GLContext release too early, and we have many chance to release it. So, mark two line which will release GLContext.
Attachment #8403724 - Flags: review?(bas)
Comment on attachment 8403724 [details] [diff] [review]
983489.patch

Review of attachment 8403724 [details] [diff] [review]:
-----------------------------------------------------------------

We can't just do that... CompositorOGL::Destroy does a bunch of work that does need to be done.
Attachment #8403724 - Flags: review?(bas) → review-
(In reply to Bas Schouten (:bas.schouten) from comment #22)
> Comment on attachment 8403724 [details] [diff] [review]
> 983489.patch
> 
> Review of attachment 8403724 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> We can't just do that... CompositorOGL::Destroy does a bunch of work that
> does need to be done.

We still have chance to call CompositorOGL::Destroy, the patch just delay the CompositorOGL::Destroy from CompositorParent::RecvWillStop to CompositorParent::RecvStop.
Flags: needinfo?(bas)
Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".
tracking-e10s: --- → +
Comment on attachment 8403724 [details] [diff] [review]
983489.patch

Review of attachment 8403724 [details] [diff] [review]:
-----------------------------------------------------------------

Bas suggest for you to review.
Attachment #8403724 - Flags: review- → review?(nical.bugzilla)
Comment on attachment 8403724 [details] [diff] [review]
983489.patch

Review of attachment 8403724 [details] [diff] [review]:
-----------------------------------------------------------------

It's not a problem with your patch but I am a bit worried about CompositorOGL making virtual method calls in its destructor. We should mark it MOZ_FINAL with a comment saying that if we want to add a subclass of CompositorOGL (which we might do at some point to have platform specific opengl optimization), then we should remove the error-prone virtual calls in the destructor. I'll file a followup bug.

Also, we should be able to call GLContext::MakeCurrent without crashing even after the destruction of the underlying context (it should return false in that case). Some code already expects that to be the case.
Attachment #8403724 - Flags: review?(nical.bugzilla) → review+
Comment on attachment 8403724 [details] [diff] [review]
983489.patch

Review of attachment 8403724 [details] [diff] [review]:
-----------------------------------------------------------------

Actually I changed my mind on one detail: please call Compositor::Destroy explicitly in RecvStop. Otherwise because of reference counting hazards, we might not call Shutdown by the end of RecvStop and that will make things chaotic at least on Linux.
Attachment #8403724 - Flags: review+ → review-
Re-triage - this doesn't have proof of being a user facing crash on devices, it only happens in debug build situations & tests. So renoming to reevaluate.
blocking-b2g: 1.4+ → 1.4?
Attached patch 983489.patch v2 (obsolete) — Splinter Review
Update patch 
1. Remove potential of calling mCompositor->Destroy() in CompositorParent->RecvWillStop()
2. Call mCompositor->Destroy() in CompositorParent->RecvStop()/CompositorParent->Destroy() explicitly
Attachment #8408087 - Flags: review?(nical.bugzilla)
Comment on attachment 8408087 [details] [diff] [review]
983489.patch v2

Review of attachment 8408087 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks!
Attachment #8408087 - Flags: review?(nical.bugzilla) → review+
Keywords: checkin-needed
Attachment #8392216 - Attachment is obsolete: true
Attachment #8403724 - Attachment is obsolete: true
Looks like you need to check that mCompositor != nullptr before calling Destroy().
blocking-b2g: 1.4? → backlog
Flags: needinfo?(bas)
Status: NEW → ASSIGNED
Attached patch 983489.patch v3 (obsolete) — Splinter Review
Comment on attachment 8415031 [details] [diff] [review]
983489.patch v3

Review of attachment 8415031 [details] [diff] [review]:
-----------------------------------------------------------------

add check mCompositor before call Destroy()
https://tbpl.mozilla.org/?tree=Try&rev=c88c51437df2
Attachment #8415031 - Flags: review?(nical.bugzilla)
Attachment #8415031 - Flags: review?(nical.bugzilla) → review+
Attachment #8408087 - Attachment is obsolete: true
Keywords: checkin-needed
Attached patch 983489.patch v4Splinter Review
update commit message based on v3.
Attachment #8415031 - Attachment is obsolete: true
Attachment #8417157 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/290f4be587a1
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Attachment #8417157 - Attachment is patch: true
backedout since this might have caused the m8 and m10 test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=39049220&tree=Mozilla-Inbound
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Merge of the backout:
https://hg.mozilla.org/mozilla-central/rev/e7735124a892

So far, it appears that this backout did indeed fix the crashes we were seeing.
Target Milestone: mozilla32 → ---
(In reply to Carsten Book [:Tomcat] from comment #40)
> backedout since this might have caused the m8 and m10 test failures like
> https://tbpl.mozilla.org/php/getParsedLog.php?id=39049220&tree=Mozilla-
> Inbound

From the log: https://tbpl.mozilla.org/php/getParsedLog.php?id=39049220&tree=Mozilla-Inbound
it's this pushlog: https://tbpl.mozilla.org/?rev=ba31cd1620bd&tree=Mozilla-Inbound and it's not my patch.

Would you please double check if it's problem of my patch?
Flags: needinfo?(cbook)
Hey Vicent,

"it's this pushlog: https://tbpl.mozilla.org/?rev=ba31cd1620bd&tree=Mozilla-Inbound and it's not my patch." yes its not your push. We sheriffs link to test failures and in some cases this might not the first occurence where the problem was seen. 

In your specific case there was in the same cset (since this was a checkin needed bug) a bustage in builds from a different developer. Thats why we linked to a different cset here.

However we investigated this for some time yesterday and were double checking a lot of csets that could have caused this test failure and after we did the backout of your patch the failures were gone away (see comment #41 from ryan). So we have the high assumption this test failure was caused by your patch.

Btw the reason why this was not seen on your try run is that the try run was done on ics opt and the failure was only on ics debug
Flags: needinfo?(cbook)
Bug 963113 Intermittent debug B2G mochitest "ABORT: corrupted actor state: file PTelephony.cpp, line 35" on shutdown
Not fixed
(In reply to Vincent Chen [:vichen] from comment #44)
> Bug 963113 Intermittent debug B2G mochitest "ABORT: corrupted actor state:
> file PTelephony.cpp, line 35" on shutdown
> Not fixed

Ken,
High repro reate in m7.
https://tbpl.mozilla.org/?tree=Try&rev=5399221c4a8c
Flags: needinfo?(kchang)
1. Cannot repro on local
2. Cannot repro on try after update code: https://tbpl.mozilla.org/?tree=Try&rev=3af70562fd0b
(In reply to Vincent Chen [:vichen] from comment #46)
> 1. Cannot repro on local
> 2. Cannot repro on try after update code:
> https://tbpl.mozilla.org/?tree=Try&rev=3af70562fd0b

2. The only exception in m9 is also happen without the patch.
https://tbpl.mozilla.org/?tree=Try&rev=f2a09c74f6c8
(In reply to Vincent Chen [:vichen] from comment #47)
> (In reply to Vincent Chen [:vichen] from comment #46)
> > 1. Cannot repro on local
> > 2. Cannot repro on try after update code:
> > https://tbpl.mozilla.org/?tree=Try&rev=3af70562fd0b
> 
> 2. The only exception in m9 is also happen without the patch.
> https://tbpl.mozilla.org/?tree=Try&rev=f2a09c74f6c8

1. As I cannot repro on local, do you have any suggestion for me to repro this issue?
2. I can repro it on try, but cannot yesterday. Would you please try it on m-i?
Flags: needinfo?(cbook)
(In reply to Vincent Chen [:vichen] from comment #48)
> (In reply to Vincent Chen [:vichen] from comment #47)
> > (In reply to Vincent Chen [:vichen] from comment #46)
> > > 1. Cannot repro on local
> > > 2. Cannot repro on try after update code:
> > > https://tbpl.mozilla.org/?tree=Try&rev=3af70562fd0b
> > 
> > 2. The only exception in m9 is also happen without the patch.
> > https://tbpl.mozilla.org/?tree=Try&rev=f2a09c74f6c8
> 
> 1. As I cannot repro on local, do you have any suggestion for me to repro
> this issue?
> 2. I can repro it on try, but cannot yesterday. Would you please try it on
> m-i?

Nical,
Need your help to give me some advice. Although the patch fix the crash after reftest test, but it seems to introduce another crash after mochitest. I have no idea why the patch will make telephony crash. Last week, I can repro the telephony crash on try but cannot on local test. This week, I cannot repro the telephony crash both on try and local. Please help.
Flags: needinfo?(nical.bugzilla)
(In reply to Vincent Chen [:vichen] from comment #48)
> (In reply to Vincent Chen [:vichen] from comment #47)
> > (In reply to Vincent Chen [:vichen] from comment #46)
> > > 1. Cannot repro on local
> > > 2. Cannot repro on try after update code:
> > > https://tbpl.mozilla.org/?tree=Try&rev=3af70562fd0b
> > 
> > 2. The only exception in m9 is also happen without the patch.
> > https://tbpl.mozilla.org/?tree=Try&rev=f2a09c74f6c8
> 
> 1. As I cannot repro on local, do you have any suggestion for me to repro
> this issue?
> 2. I can repro it on try, but cannot yesterday. Would you please try it on
> m-i?

in general just setting checkin-needed again should be enough and I or a different Sheriff will take this bug and do the checkin - but i guess in this specific case we might want to wait for the answer from nical to comment #49 right?
Flags: needinfo?(cbook)
It's really unclear what in your patch could cause a regression in telephony. Looking at the last try push, the first thing i'd look at would probably be this:

[Parent 671] ###!!! ASSERTION: Using observer service after XPCOM shutdown!: 'Error', file ../../../gecko/xpcom/ds/nsObserverService.cpp, line 260

Maybe see who is using this observer service and if there could be a link with delaying the destruction of the compositor...
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/3939dc732041
Status: REOPENED → RESOLVED
Closed: 10 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
This bug is resolved.
Flags: needinfo?(kchang)
Flags: needinfo?(nical.bugzilla)
blocking-b2g: backlog → ---
You need to log in before you can comment on or make changes to this bug.