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)
Tracking
()
Tracking | Status | |
---|---|---|
e10s | - | --- |
People
(Reporter: vichen, Assigned: vichen)
References
Details
(Keywords: crash)
Crash Data
Attachments
(1 file, 7 obsolete files)
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
Comment 1•10 years ago
|
||
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
Updated•10 years ago
|
Assignee: nobody → hshih
Comment 2•10 years ago
|
||
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|
Updated•10 years ago
|
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)]
Comment 3•10 years ago
|
||
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.
Comment 5•10 years ago
|
||
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)
Comment 6•10 years ago
|
||
We will check the bug 985773. Maybe we have some problem for delete sequence in gfxPlatform::Shutdown()
Comment 7•10 years ago
|
||
Vincent Chen([:vichen]) is looking this problem now.
Assignee | ||
Comment 8•10 years ago
|
||
GLContext is released before Texture is released. Wait result: https://tbpl.mozilla.org/?tree=Try&rev=b527e30e4264
Updated•10 years ago
|
Assignee: bjacob → vichen
Flags: needinfo?(bjacob)
Assignee | ||
Comment 9•10 years ago
|
||
The crash happen when GLContext released before Texture is released. This patch re-order the release sequence.
Assignee | ||
Comment 10•10 years ago
|
||
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
Assignee | ||
Comment 11•10 years ago
|
||
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
Comment 12•10 years ago
|
||
(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.
Assignee | ||
Comment 14•10 years ago
|
||
This bug is fixed, but it crashed at another point randomly (same as Bug 987251). https://tbpl.mozilla.org/?tree=Try&rev=03e110fde6b3
Comment 16•10 years ago
|
||
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.
Assignee | ||
Comment 17•10 years ago
|
||
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)
Assignee | ||
Comment 18•10 years ago
|
||
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)
Assignee | ||
Comment 19•10 years ago
|
||
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
Assignee | ||
Comment 20•10 years ago
|
||
Attachment #8403118 -
Attachment is obsolete: true
Assignee | ||
Comment 21•10 years ago
|
||
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 22•10 years ago
|
||
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-
Assignee | ||
Comment 23•10 years ago
|
||
(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)
Comment 24•10 years ago
|
||
Mass tracking-e10s flag change. Filter bugmail on "2be0fcce-e36a-4e2c-aa80-0e3d33eb5406".
tracking-e10s:
--- → +
Assignee | ||
Comment 25•10 years ago
|
||
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 26•10 years ago
|
||
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 27•10 years ago
|
||
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-
Comment 28•10 years ago
|
||
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?
Assignee | ||
Comment 29•10 years ago
|
||
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 30•10 years ago
|
||
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+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Assignee | ||
Updated•10 years ago
|
Attachment #8392216 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Attachment #8403724 -
Attachment is obsolete: true
Comment 31•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/b032a90ee083
Keywords: checkin-needed
Comment 32•10 years ago
|
||
had to backout this change for test failures like https://tbpl.mozilla.org/php/getParsedLog.php?id=38002451&tree=Mozilla-Inbound
Comment 33•10 years ago
|
||
Looks like you need to check that mCompositor != nullptr before calling Destroy().
Updated•10 years ago
|
blocking-b2g: 1.4? → backlog
Updated•10 years ago
|
Updated•10 years ago
|
Flags: needinfo?(bas)
Assignee | ||
Comment 34•10 years ago
|
||
Assignee | ||
Comment 35•10 years ago
|
||
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)
Updated•10 years ago
|
Attachment #8415031 -
Flags: review?(nical.bugzilla) → review+
Assignee | ||
Updated•10 years ago
|
Attachment #8408087 -
Attachment is obsolete: true
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 36•10 years ago
|
||
Please include commit information with your patch, including a commit message that says what the patch is doing (not restating the problem it's solving). https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F https://developer.mozilla.org/en-US/docs/Developer_Guide/Committing_Rules_and_Responsibilities#Checkin_comment
Keywords: checkin-needed
Assignee | ||
Comment 37•10 years ago
|
||
update commit message based on v3.
Attachment #8415031 -
Attachment is obsolete: true
Attachment #8417157 -
Flags: review+
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 38•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/290f4be587a1
Keywords: checkin-needed
Comment 39•10 years ago
|
||
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
Comment 40•10 years ago
|
||
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 → ---
Comment 41•10 years ago
|
||
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 → ---
Assignee | ||
Comment 42•10 years ago
|
||
(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)
Comment 43•10 years ago
|
||
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)
Assignee | ||
Comment 44•10 years ago
|
||
Bug 963113 Intermittent debug B2G mochitest "ABORT: corrupted actor state: file PTelephony.cpp, line 35" on shutdown Not fixed
Assignee | ||
Comment 45•10 years ago
|
||
(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)
Assignee | ||
Comment 46•10 years ago
|
||
1. Cannot repro on local 2. Cannot repro on try after update code: https://tbpl.mozilla.org/?tree=Try&rev=3af70562fd0b
Assignee | ||
Comment 47•10 years ago
|
||
(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
Assignee | ||
Comment 48•10 years ago
|
||
(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)
Assignee | ||
Comment 49•10 years ago
|
||
(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)
Comment 50•10 years ago
|
||
(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)
Comment 51•10 years ago
|
||
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...
Assignee | ||
Updated•10 years ago
|
Keywords: checkin-needed
Comment 52•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/3939dc732041
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/3939dc732041
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
Updated•10 years ago
|
Flags: needinfo?(nical.bugzilla)
Updated•9 years ago
|
blocking-b2g: backlog → ---
tracking-b2g:
--- → backlog
You need to log in
before you can comment on or make changes to this bug.
Description
•