Closed Bug 1034523 Opened 11 years ago Closed 11 years ago

TextureClient sends IPC message after we call MessageLoop::Quit

Categories

(Core :: Graphics: Layers, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 774388

People

(Reporter: slee, Unassigned)

References

Details

After calling MessageLoop::Quit, we should not send IPC message. Here is the back trace. #0 __futex_syscall3 () at bionic/libc/arch-arm/bionic/atomics_arm.S:183 #1 0x40076198 in _normal_unlock (mutex=0x44550ab0) at bionic/libc/bionic/pthread.c:1011 #2 pthread_mutex_unlock (mutex=0x44550ab0) at bionic/libc/bionic/pthread.c:1120 #3 0x42d15dd4 in PR_Unlock (lock=0x44550ab0) at /home/steven/workspace/b2g/gecko-dev/nsprpub/pr/src/pthreads/ptsynch.c:209 #4 0x40629fea in mozilla::OffTheBooksMutex::Unlock (this=0x44074de0) at /home/steven/workspace/b2g/gecko-dev/xpcom/glue/BlockingResourceBase.cpp:238 #5 0x4085d7e8 in mozilla::Monitor::Unlock (this=0x4407f020, aMsg=<value optimized out>) at ../../dist/include/mozilla/Monitor.h:42 #6 ~MonitorAutoLock (this=0x4407f020, aMsg=<value optimized out>) at ../../dist/include/mozilla/Monitor.h:97 #7 mozilla::ipc::MessageChannel::Send (this=0x4407f020, aMsg=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/ipc/glue/MessageChannel.cpp:427 #8 0x4096fc6c in mozilla::layers::PTextureChild::SendRemoveTexture (this=0x44cff550) at /home/steven/workspace/b2g/gecko-dev/obj-emulator-debug/ipc/ipdl/PTextureChild.cpp:115 #9 0x40b7c424 in mozilla::layers::TextureClient::ForceRemove (this=0x44060400) at /home/steven/workspace/b2g/gecko-dev/gfx/layers/client/TextureClient.cpp:365 #10 0x40b9a7e2 in mozilla::layers::ShadowLayerForwarder::RemoveTexture (this=<value optimized out>, aTexture=0x4407f020) at /home/steven/workspace/b2g/gecko-dev/gfx/layers/ipc/ShadowLayers.cpp:459 #11 0x40b791c0 in mozilla::layers::TextureClient::Finalize (this=0x44060400) at /home/steven/workspace/b2g/gecko-dev/gfx/layers/client/TextureClient.cpp:409 #12 0x40b544d0 in mozilla::AtomicRefCountedWithFinalize<mozilla::layers::TextureClient>::Release (t=0x44060400) at ../../dist/include/mozilla/layers/AtomicRefCountedWithFinalize.h:45 #13 mozilla::RefPtr<mozilla::layers::TextureClient>::unref (t=0x44060400) at ../../dist/include/mozilla/RefPtr.h:283 #14 0x40b54520 in ~RefPtr (table=<value optimized out>, entry=0x440aa424) at ../../dist/include/mozilla/RefPtr.h:233 #15 ~nsBaseHashtableET (table=<value optimized out>, entry=0x440aa424) at ../../dist/include/nsBaseHashtable.h:370 #16 nsTHashtable<nsBaseHashtableET<nsUint32HashKey, mozilla::RefPtr<mozilla::layers::TextureClient> > >::s_ClearEntry ( table=<value optimized out>, entry=0x440aa424) at ../../dist/include/nsTHashtable.h:460 #17 0x4062c072 in PL_DHashTableFinish (table=0x45d699f4) at /home/steven/workspace/b2g/gecko-dev/xpcom/glue/pldhash.cpp:320 #18 0x40b54936 in ~nsTHashtable (this=0x45d699b0, __in_chrg=<value optimized out>) at ../../dist/include/nsTHashtable.h:399 #19 ~nsBaseHashtable (this=0x45d699b0, __in_chrg=<value optimized out>) at ../../dist/include/nsBaseHashtable.h:54 #20 ~nsDataHashtable (this=0x45d699b0, __in_chrg=<value optimized out>) at ../../dist/include/nsDataHashtable.h:23 #21 ~CairoImage (this=0x45d699b0, __in_chrg=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/gfx/layers/ImageContainer.cpp:617 #22 0x40b54964 in ~CairoImage (this=0x45d699f4, __in_chrg=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/gfx/layers/ImageContainer.cpp:617 #23 0x409fee52 in mozilla::layers::Image::Release (this=0x45d699b0) at ../../../../dist/include/ImageContainer.h:144 #24 0x40b5534c in ~nsRefPtr (this=0x45d7a830, __in_chrg=<value optimized out>) at ../../dist/include/nsAutoPtr.h:852 #25 ~ImageContainer (this=0x45d7a830, __in_chrg=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/gfx/layers/ImageContainer.cpp:142 #26 0x409ffe6c in mozilla::layers::ImageContainer::Release (this=0x45d7a830) at ../../../../dist/include/ImageContainer.h:347 #27 0x416117ac in ~nsRefPtr (table=<value optimized out>, entry=<value optimized out>) at ../../dist/include/nsAutoPtr.h:852 #28 ~MaskLayerImageEntry (table=<value optimized out>, entry=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/layout/base/MaskLayerImageCache.h:214 #29 nsTHashtable<mozilla::MaskLayerImageCache::MaskLayerImageEntry>::s_ClearEntry (table=<value optimized out>, entry=<value optimized out>) at ../../dist/include/nsTHashtable.h:460 #30 0x4062c072 in PL_DHashTableFinish (table=0x44c07c20) at /home/steven/workspace/b2g/gecko-dev/xpcom/glue/pldhash.cpp:320 #31 0x416117dc in ~nsTHashtable (this=0x44c07c20, __in_chrg=<value optimized out>) at ../../dist/include/nsTHashtable.h:399 #32 ~MaskLayerImageCache (this=0x44c07c20, __in_chrg=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/layout/base/MaskLayerImageCache.cpp:20 #33 0x416117f4 in mozilla::FrameLayerBuilder::Shutdown () at /home/steven/workspace/b2g/gecko-dev/layout/base/FrameLayerBuilder.cpp:889 #34 0x40f94ae6 in nsLayoutStatics::Shutdown () at /home/steven/workspace/b2g/gecko-dev/layout/build/nsLayoutStatics.cpp:366 #35 0x40f94bc4 in nsLayoutStatics::Release () at /home/steven/workspace/b2g/gecko-dev/layout/build/nsLayoutStatics.h:46 #36 Shutdown () at /home/steven/workspace/b2g/gecko-dev/layout/build/nsLayoutModule.cpp:411 #37 0x40f94bf6 in LayoutModuleDtor () at /home/steven/workspace/b2g/gecko-dev/layout/build/nsLayoutModule.cpp:1269 #38 0x40673edc in ~KnownModule (this=0x4027d5a0, __in_chrg=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/xpcom/components/nsComponentManager.h:226 #39 0x40676632 in ~nsAutoPtr (this=0x4024d9b8) at ../../dist/include/nsAutoPtr.h:73 #40 nsTArrayElementTraits<nsAutoPtr<nsComponentManagerImpl::KnownModule> >::Destruct (this=0x4024d9b8) at ../../dist/include/nsTArray.h:536 #41 nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayInfallibleAllocator>::DestructRange (this=0x4024d9b8) at ../../dist/include/nsTArray.h:1583 #42 nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayInfallibleAllocator>::RemoveElementsAt (this=0x4024d9b8) at ../../dist/include/nsTArray.h:1300 #43 nsTArray_Impl<nsAutoPtr<nsComponentManagerImpl::KnownModule>, nsTArrayInfallibleAllocator>::Clear (this=0x4024d9b8) at ../../dist/include/nsTArray.h:1311 #44 0x40676b5a in nsComponentManagerImpl::Shutdown (this=0x4024d900) at /home/steven/workspace/b2g/gecko-dev/xpcom/components/nsComponentManager.cpp:788 #45 0x40633ada in mozilla::ShutdownXPCOM (servMgr=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/xpcom/build/nsXPComInit.cpp:923 #46 0x40633cde in NS_ShutdownXPCOM (servMgr=0x4024d900) at /home/steven/workspace/b2g/gecko-dev/xpcom/build/nsXPComInit.cpp:746 #47 0x4190bb70 in XRE_TermEmbedding () at /home/steven/workspace/b2g/gecko-dev/toolkit/xre/nsEmbedFunctions.cpp:191 #48 0x408572d0 in mozilla::ipc::ScopedXREEmbed::Stop (this=0x40262680) at /home/steven/workspace/b2g/gecko-dev/ipc/glue/ScopedXREEmbed.cpp:110 #49 0x40f398a6 in mozilla::dom::ContentProcess::CleanUp (this=<value optimized out>) at /home/steven/workspace/b2g/gecko-dev/dom/ipc/ContentProcess.cpp:37 #50 0x4190ba84 in XRE_InitChildProcess (aArgc=2, aArgv=0xbed4c8a8, aProcess=3201616028) at /home/steven/workspace/b2g/gecko-dev/toolkit/xre/nsEmbedFunctions.cpp:534 #51 0x00008894 in main (argc=7, argv=0xbed4c924) at /home/steven/workspace/b2g/gecko-dev/ipc/app/MozillaRuntimeMain.cpp:149
Depends on: 1034527
For the STR, please check bug 1016184 comment 34.
No longer depends on: 1034527
Assignee: nobody → sotaro.ikeda.g
Before calling PTextureChild::SendRemoveTexture(), ipc availability is checked by TextureChild::IPCOpen(). But it does not recognize NS_ShutdownXPCOM() use case.
Assignee: sotaro.ikeda.g → nobody
This problem might be a part of Bug 774388.
:bjacob, is this bug related to Bug 774388?
Flags: needinfo?(bjacob)
Yes, this seems like bug 1007284. The current thinking (assuming that this in fact is bug 1007284) is that the patches that just landed on bug 774388 should fix all of that. In bug 1007284, the MessageLoop that has already quitted and that we are posting a message on, is the message loop of the compositor thread. So the present bug is similar to bug 1007284 if, and only if the dead messageLoop here is also that of the compositor thread. The problem was that we were shutting down the compositor thread (and its message loop) without waiting for IPDL protocols to be shut down. That is one of the things that bug 774388 intends to fix. See specifically patch 5 there.
Flags: needinfo?(bjacob)
Note that this just landed on inbound, so you are very welcome to try and report if it fixes this bug or not. Thanks!
(In reply to Benoit Jacob [:bjacob] from comment #6) > Note that this just landed on inbound, so you are very welcome to try and > report if it fixes this bug or not. Thanks! I used the patches in bug 774388(it was back out and re-land yesterday). It seems works fine. Here is the try server log. https://tbpl.mozilla.org/?tree=Try&rev=8e5b6c90019d So I mark this is a duplicated bug.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.