918595 - Assertion: mozilla::ipc::FileDescriptor::CloseCurrentProcessHandle at FileDescriptor.cpp:68 MOZ_ASSERT_IF(mHandleCreatedByOtherProcess,

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Gregor Wagner [:gwagner]]

Seen on nexus device with debug build when having the gallery app open and shutting down the device.

Program received signal SIGSEGV, Segmentation fault.
0xb5796822 in mozilla::ipc::FileDescriptor::CloseCurrentProcessHandle (this=<optimized out>) at ../../../ipc/glue/FileDescriptor.cpp:68
68	  MOZ_ASSERT_IF(mHandleCreatedByOtherProcess,
(gdb) bt
#0  0xb5796822 in mozilla::ipc::FileDescriptor::CloseCurrentProcessHandle (this=<optimized out>) at ../../../ipc/glue/FileDescriptor.cpp:68
#1  0xb577d2e4 in ~FileDescriptor (this=0xb28ff72c, __in_chrg=<optimized out>) at ../../dist/include/mozilla/ipc/FileDescriptor.h:75
#2  mozilla::dom::TabChild::CachedFileDescriptorInfo::~CachedFileDescriptorInfo (this=0xb28ff720, __in_chrg=<optimized out>) at ../../../dom/ipc/TabChild.cpp:134
#3  0xb577d2fc in nsAutoPtr<mozilla::dom::TabChild::CachedFileDescriptorInfo>::~nsAutoPtr (this=0xb3e92b80, __in_chrg=<optimized out>)
    at ../../../xpcom/base/nsAutoPtr.h:77
#4  0xb577df3c in Destruct (e=0xb3e92b80) at ../../dist/include/nsTArray.h:534
#5  nsTArray_Impl<nsAutoPtr<mozilla::dom::TabChild::CachedFileDescriptorInfo>, nsTArrayInfallibleAllocator>::DestructRange (this=<optimized out>, start=<optimized out>, 
    count=<optimized out>) at ../../dist/include/nsTArray.h:1569
#6  0xb577fd4a in nsTArray_Impl<nsAutoPtr<mozilla::dom::TabChild::CachedFileDescriptorInfo>, nsTArrayInfallibleAllocator>::RemoveElementsAt (this=0xb3e92b74, start=0, 
    count=1) at ../../dist/include/nsTArray.h:1286
#7  0xb577fda6 in Clear (this=<optimized out>) at ../../dist/include/nsTArray.h:1297
#8  nsTArray_Impl<nsAutoPtr<mozilla::dom::TabChild::CachedFileDescriptorInfo>, nsTArrayInfallibleAllocator>::~nsTArray_Impl (this=0xb3e92b74, __in_chrg=<optimized out>)
    at ../../dist/include/nsTArray.h:748
#9  0xb577feb0 in ~nsTArray (this=0xb3e92b74, __in_chrg=<optimized out>) at ../../dist/include/nsTArray.h:1642
#10 ~nsAutoArrayBase (this=0xb3e92b74, __in_chrg=<optimized out>) at ../../dist/include/nsTArray.h:1681
#11 ~nsAutoTArray (this=0xb3e92b74, __in_chrg=<optimized out>) at ../../dist/include/nsTArray.h:1752
#12 mozilla::dom::TabChild::~TabChild (this=0xb3e92a10, __in_chrg=<optimized out>) at ../../../dom/ipc/TabChild.cpp:1231
#13 0xb577ff54 in mozilla::dom::TabChild::~TabChild (this=0xb3e92a10, __in_chrg=<optimized out>) at ../../../dom/ipc/TabChild.cpp:1231
#14 0xb577c6ea in Release (this=0xb3e92a10) at ../../../dom/ipc/TabChild.cpp:799
#15 mozilla::dom::TabChild::Release (this=0xb3e92a10) at ../../../dom/ipc/TabChild.cpp:799
#16 0xb4d55076 in mozilla::dom::CallbackObjectHolder<mozilla::dom::EventListener, nsIDOMEventListener>::UnlinkSelf (this=0xb2e9835c)
    at ../../../dist/include/mozilla/dom/CallbackObject.h:375
#17 0xb51bc7c8 in ~CallbackObjectHolder (this=0xb2e9835c, __in_chrg=<optimized out>) at ../../../dist/include/mozilla/dom/CallbackObject.h:229
#18 ~nsListenerStruct (this=0xb2e9835c, __in_chrg=<optimized out>) at ../../../../content/events/src/nsEventListenerManager.h:188
#19 Destruct (e=0xb2e9835c) at ../../../dist/include/nsTArray.h:534
#20 DestructRange (count=7, start=0, this=0xb2ea9d14) at ../../../dist/include/nsTArray.h:1569
#21 nsTArray_Impl<nsListenerStruct, nsTArrayInfallibleAllocator>::RemoveElementsAt (this=0xb2ea9d14, start=0, count=7) at ../../../dist/include/nsTArray.h:1286
#22 0xb51bcbde in Clear (this=0xb2ea9d10) at ../../../dist/include/nsTObserverArray.h:241
#23 RemoveAllListeners (this=0xb2ea9d00) at ../../../../content/events/src/nsEventListenerManager.cpp:131
#24 nsEventListenerManager::RemoveAllListeners (this=0xb2ea9d00) at ../../../../content/events/src/nsEventListenerManager.cpp:125
#25 0xb5354f52 in nsWindowRoot::~nsWindowRoot (this=0xb2ed1100, __in_chrg=<optimized out>) at ../../../dom/base/nsWindowRoot.cpp:40
#26 0xb5354fa0 in nsWindowRoot::~nsWindowRoot (this=0xb2ed1100, __in_chrg=<optimized out>) at ../../../dom/base/nsWindowRoot.cpp:42
#27 0xb5354c52 in nsWindowRoot::DeleteCycleCollectable (this=<optimized out>) at ../../../dom/base/nsWindowRoot.cpp:59
#28 0xb5355212 in nsWindowRoot::cycleCollection::DeleteCycleCollectable (this=<optimized out>, p=<optimized out>) at ../../../dom/base/nsWindowRoot.h:56
#29 0xb5b00f4e in SnowWhiteKiller::~SnowWhiteKiller (this=0xbeae3d84, __in_chrg=<optimized out>) at ../../../xpcom/base/nsCycleCollector.cpp:1993
#30 0xb5b00fbc in nsCycleCollector::FreeSnowWhite (this=0xb3e84000, aUntilNoSWInPurpleBuffer=<optimized out>) at ../../../xpcom/base/nsCycleCollector.cpp:2102
#31 0xb55e6cc2 in AsyncFreeSnowWhite::Run (this=0xb3103050) at ../../../../js/xpconnect/src/XPCJSRuntime.cpp:231
#32 0xb5af6b1a in nsThread::ProcessNextEvent (this=0xb3e02390, mayWait=<optimized out>, result=0xbeae3e2f) at ../../../xpcom/threads/nsThread.cpp:622
#33 0xb5ac5da8 in NS_ProcessPendingEvents (thread=0xb3e02390, timeout=4294967295) at ../../../xpcom/glue/nsThreadUtils.cpp:188
#34 0xb5aca122 in mozilla::ShutdownXPCOM (servMgr=0x0) at ../../../xpcom/build/nsXPComInit.cpp:660
#35 0xb4d395e4 in XRE_TermEmbedding () at ../../../toolkit/xre/nsEmbedFunctions.cpp:187
#36 0xb579bb2a in mozilla::ipc::ScopedXREEmbed::Stop (this=0xb3e45ad0) at ../../../ipc/glue/ScopedXREEmbed.cpp:110
#37 0xb4d39d2a in XRE_InitChildProcess (aArgc=5, aArgv=<optimized out>, aProcess=<optimized out>) at ../../../toolkit/xre/nsEmbedFunctions.cpp:520
#38 0x0000876e in main (argc=6, argv=0xbeae49f4) at ../../../ipc/app/MozillaRuntimeMain.cpp:85

Comment 1

[Gregor Wagner [:gwagner]]

It's the application.zip file for apps.

Comment 2

[Jason Duell]

So the assert is conditional on mHandleCreatedByOtherProcessWasUsed=false, which means the child never called PlatformHandle(), i.e. client code never tried to get the OS file handle.

If this is only happening at shutdown I can imagine the issue might be here:

   http://mxr.mozilla.org/mozilla-central/source/netwerk/ipc/RemoteOpenFileChild.cpp#224

i.e we launch a new event to close the FD, but if we never get to run that event (XPCOM shutdown might prevent it), then we never call PlatformHandle(), so we'll hit the assert.

If this is the issue we could change CloseFileRunnable to take a PRFileDesc instead of a FileDescriptor and the assert will go away.  

Given that all fds get closed by the OS automatically at exit, I don't think there's a real bug here, just a trigger-happy assert.

Comment 3

[Andrew Overholt [:overholt]]

(In reply to Jason Duell (:jduell) from comment #2)
> So the assert is conditional on mHandleCreatedByOtherProcessWasUsed=false,
> which means the child never called PlatformHandle(), i.e. client code never
> tried to get the OS file handle.
> 
> If this is only happening at shutdown I can imagine the issue might be here:
> 
>   
> http://mxr.mozilla.org/mozilla-central/source/netwerk/ipc/
> RemoteOpenFileChild.cpp#224
> 
> i.e we launch a new event to close the FD, but if we never get to run that
> event (XPCOM shutdown might prevent it), then we never call
> PlatformHandle(), so we'll hit the assert.
> 
> If this is the issue we could change CloseFileRunnable to take a PRFileDesc
> instead of a FileDescriptor and the assert will go away.  
> 
> Given that all fds get closed by the OS automatically at exit, I don't think
> there's a real bug here, just a trigger-happy assert.

This makes me think blocking-b2g:- but I suspect Gregor disagrees :)

Comment 4

[Gregor Wagner [:gwagner]]

I am happy that someone looked at the bug and we found that it's not a serious problem and I agree that we shouldn't block on it.
The koi? was more to get this bug on a list of things we have to fix.

Comment 5

[Andrew Overholt [:overholt]]

Cool.

Comment 6

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

(In reply to Jason Duell (:jduell) from comment #2)

Well, as far as I can tell this is not happening with a quick shutdown-after-startup. And even if it was I would expect to see one of the warnings in http://mxr.mozilla.org/mozilla-central/source/ipc/glue/FileDescriptorUtils.cpp#42 in the logs. I don't see that anywhere in the logs.

Since that's not happening I think this is instead a FD that is getting leaked for the lifetime of the child process and never used which is a bit more serious.

Comment 7

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

Attachment: Fix, v1

This properly closes files that are opened and never used. However, I still think we should try to detect these leaks sooner...

Comment 8

[Jason Duell]

Comment on attachment 8412884 [details] [diff] [review]
Fix, v1

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

I'm assuming ~TabChild can be called at some point other than child process shutdown? (otherwise we could presumably just rely on the OS closing fd's as part of process shutdown).

Comment 9

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

(In reply to Jason Duell (:jduell) from comment #8)
> I'm assuming ~TabChild can be called at some point other than child process
> shutdown?

Yep, there can be more than one tabchild per process.

> (otherwise we could presumably just rely on the OS closing fd's as
> part of process shutdown).

Well, this makes us assert-free too. But yes.

Comment 10

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

https://hg.mozilla.org/integration/b2g-inbound/rev/ff9afcc49b24

Comment 11

[Ryan VanderMeulen [:RyanVM]]

http://hg.mozilla.org/mozilla-central/rev/ff9afcc49b24