Closed Bug 983489 Opened 12 years ago Closed 12 years ago

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

Categories

(Core :: Graphics: Layers, defect)

Product:
Core
Component:
Graphics: Layers
Platform:
ARM
Gonk (Firefox OS)
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED
Milestone:
mozilla32
Project Flags:
tracking-b2g backlog
Tracking Flags:
Tracking Status
e10s - ---

People

(Reporter: vichen, Assigned: vichen)

References

Details

(Keywords: crash)

Crash Data

Attachments

(1 file, 7 obsolete files)

983489.patch v4
1.98 KB, patch
vichen
: review+
Details | Diff | Splinter Review
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 v4 — — Splinter 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: 12 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: 12 years ago → 12 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
This bug is resolved.
Flags: needinfo?(kchang)
Flags: needinfo?(nical.bugzilla)
blocking-b2g: backlog → ---
tracking-b2g: --- → backlog
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: