When auido app is killed during mp3 audio playback, mediaserver is also aborted. STR - playback mp3 audio by music app. - long press home button(running apps are shown) - kill music app. stack information when mediaserver is killed. ----------------------------------- (gdb) info stack #0 __libc_android_abort () at bionic/libc/unistd/abort.c:82 #1 0x4006644c in __android_log_assert (cond=<value optimized out>, tag=0x40bf285a "OMXNodeInstance", fmt=0x40bf2fc3 "frameworks/base/media/libstagefright/omx/OMXNodeInstance.cpp:203 !\"should not be here, unknown state.\"") at system/core/liblog/logd_write.c:246 #2 0x40bf06ba in android::OMXNodeInstance::freeNode (this=0x18841f0, master=0x1883568) at frameworks/base/media/libstagefright/omx/OMXNodeInstance.cpp:203 #3 0x40bf07a4 in android::OMXNodeInstance::onObserverDied (this=0x18841f0, master=0x1883568) at frameworks/base/media/libstagefright/omx/OMXNodeInstance.cpp:686 #4 0x40bee9be in android::OMX::binderDied (this=0x1883500, the_late_who=<value optimized out>) at frameworks/base/media/libstagefright/omx/OMX.cpp:189 #5 0x40221118 in android::BpBinder::reportOneDeath (this=<value optimized out>, obit=<value optimized out>) at frameworks/base/libs/binder/BpBinder.cpp:282 #6 0x4022118a in android::BpBinder::sendObituary (this=0x1884198) at frameworks/base/libs/binder/BpBinder.cpp:269 #7 0x40224204 in android::IPCThreadState::executeCommand (this=<value optimized out>, cmd=<value optimized out>) at frameworks/base/libs/binder/IPCThreadState.cpp:1061 #8 0x40224372 in android::IPCThreadState::joinThreadPool (this=0x187f6a0, isMain=true) at frameworks/base/libs/binder/IPCThreadState.cpp:468 #9 0x00008c26 in main (argc=<value optimized out>, argv=<value optimized out>) at frameworks/base/media/mediaserver/main_mediaserver.cpp:66

mediaserver should not be aborted in the STR.

From Firefox OS v1.1, audio codecs are moved to android's mediaserver process by Bug 803471.

Can someone speak to how this looks to the user? Do they get the mediaserver (audio playback) back on the next launch of audio app or is there no more playback?

(In reply to lsblakk@mozilla.com from comment #3) > Can someone speak to how this looks to the user? Do they get the > mediaserver (audio playback) back on the next launch of audio app or is > there no more playback? This isn't appropriate for qawanted. This is a better question to ask the reporter. Pulling the keyword as such. Sotaro - Can you address the questions in comment 3?

On v1.1, mediaserver process handle following things. Some apps use mediaserver concurretly. - audio out, camera hw, video codec, audio codec If mediaserver is killed because of music app, Other apps using mediaserver capability get affected. Example STR - start music app and start mp3 audio - push home button (music continue) - start video app and start to play h.264 video when start to play the video the audio of music app stops. But the music app still uses audio codec. - long push home button and start task manager. kill music app - back to video app. video app can not continue to play video. hw video codec is killed when music app killed.

Hi Sotaro & Diego, The crash point is at the code as below, and it seems to be happened by the patch on bug 860760. That patch will set omx state to OMX_StatePause by killing music app during playing but OMXNodeInstance::freeNode() doesn't expect that state appeared. If i removed that patch the state will be OMX_StateExecuting and accepted by OMXNodeInstance::freeNode(). https://www.codeaurora.org/gitweb/quic/la/?p=platform/frameworks/base.git;a=blob;f=media/libstagefright/omx/OMXNodeInstance.cpp;h=f388a818e7256581184b318f0ac183250e6a5e06;hb=3cd20030a6de3eea555eaab4991a6842c8b56999#l203

I am going to investigate about the crash.

It seems the OMX Decoder is not being stopped upon destruction. Can someone check if this line is being hit? https://mxr.mozilla.org/mozilla-central/source/content/media/omx/OmxDecoder.cpp#160

(In reply to Diego Wilson [:diego] from comment #8) > It seems the OMX Decoder is not being stopped upon destruction. Can someone > check if this line is being hit? > > https://mxr.mozilla.org/mozilla-central/source/content/media/omx/OmxDecoder. > cpp#160 No, that line is not fired when this issue is happened.

Then the OmdDecoder may be leaked. Can you check if the destructor is called? If not, the music app is not deinitializing correctly.

(In reply to Diego Wilson [:diego] from comment #10) > Then the OmdDecoder may be leaked. Can you check if the destructor is > called? If not, the music app is not deinitializing correctly. Hi Diego, The deconstructor of OMXDecoder didn't be called I think it is related to behavior of HTMLMediaElement::AddRemoveSelfReference() when child process received NS_XPCOM_SHUTDOWN_OBSERVER_ID.

I'm trying to figure out what's going on here. The OmxDecoder gets destroyed as part of the cleanup that is triggered by nsDecoderDisposeEvent. This event get's scheduled by MediaDecoderStateMachine::RunStateMachine when MediaDecoderStateMachine::mState has been changed to DECODER_STATE_SHUTDOWN. When the audio is not paused and everything works correctly, I found that this state change is generated by MediaDecoder::Observe, which calls shutdown. When the audio is paused, this function is not executed at all.

Here is a stack trace from the correct shutdown. > #0 mozilla::MediaDecoderStateMachine::Shutdown (this=0x43d85f40) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/media/MediaDecoderStateMachine.cpp:1465 > #1 0x40a0a34e in mozilla::MediaDecoder::Shutdown (this=0x456a8e40) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/media/MediaDecoder.cpp:387 > #2 0x40a08abc in mozilla::MediaDecoder::Observe (this=0x456a8e40, aSubjet=<value optimized out>, aTopic=0x41f01e02 "xpcom-shutdown", someData=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/media/MediaDecoder.cpp:876 > #3 0x413fdb10 in nsObserverList::NotifyObservers (this=<value optimized out>, aSubject=0x42e23704, aTopic=0x41f01e02 "xpcom-shutdown", someData=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/ds/nsObserverList.cpp:99 > #4 0x413fde1e in nsObserverService::NotifyObservers (this=<value optimized out>, aSubject=0x42e23704, aTopic=0x41f01e02 "xpcom-shutdown", someData=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/ds/nsObserverService.cpp:161 > #5 0x413ef69c in mozilla::ShutdownXPCOM (servMgr=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/build/nsXPComInit.cpp:576 > #6 0x413efc74 in NS_ShutdownXPCOM (servMgr=0x1) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/build/nsXPComInit.cpp:536 > #7 0x40440750 in XRE_TermEmbedding () at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/toolkit/xre/nsEmbedFunctions.cpp:196 > #8 0x410d849a in mozilla::ipc::ScopedXREEmbed::Stop (this=0x42e31658) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/ScopedXREEmbed.cpp:110 > #9 0x410a3028 in mozilla::dom::ContentProcess::CleanUp (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/ipc/ContentProcess.cpp:37 > #10 0x40440650 in XRE_InitChildProcess (aArgc=0x2, aArgv=0xbef289a4, aProcess=1122178048) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/toolkit/xre/nsEmbedFunctions.cpp:500 > #11 0x00008682 in main (argc=0x7, argv=0xbef28a24) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/app/MozillaRuntimeMain.cpp:60 Frame #9 does not show up when the music app is paused during exit. XRE_InitChildProcess near line 500 does > // Run the UI event loop on the main thread. > uiMessageLoop.MessageLoop::Run(); > > // Allow ProcessChild to clean up after itself before going out of > // scope and being deleted > process->CleanUp(); This means that the paused music app' content process exists while running the main event loop. There is no obvious error message in the logcat and according to gdb, the content process exits with code 0.

The crash happened bacause OMXNodeInstance can not handle binderDied event correctly. The event is called when a Binder object in different process that is observed is died by some reason. From v1.1 OMX instance is moved to android's mediaserver process in Bug 803471. So, even when the shutdown sequence do not happened correctly, the binderDied event should clean up the omx il component.

The patch add handling of OMX_StatePause state. Confirmed that the patches fixed the crash on MozBuild v1.1 buri.

(In reply to Sotaro Ikeda [:sotaro] from comment #15) > So, even when the shutdown sequence do not happened correctly, the > binderDied event should clean up the omx il component. Given that the app is being closed properly, why is the shutdown sequence not proper?

I'm concerned that proper nsOmxDecoder destruction is not happening for what seems to me a normal app closing procedure

There are 2 problems. It is better to split one to different bug. - app's shut down sequence do not work properly. - mediaserver abort when app get killed without shut down.

(In reply to Sotaro Ikeda [:sotaro] from comment #19) > - mediaserver abort when app get killed without shut down. Bug 871018 is created for the mediaserver abort fix.

Comment on attachment 746964 [details] [diff] [review] patch - handle OMX_StatePause state in OMXNodeInstance::freeNode() move to Bug 871018.

An update on the shutdown problem. When I break on _exit and close the paused music player, I get the following stack trace > gdb> break _exit > Breakpoint 1 at 0x400d9114: file bionic/libc/arch-arm/syscalls/_exit.S, line 7. > gdb> c > _______________________________________________________________________________ > Error while running hook_stop: > Value can't be converted to integer. > > Breakpoint 1, _exit () at bionic/libc/arch-arm/syscalls/_exit.S:8 > 8 ldr r7, =__NR_exit_group > gdb> bt > #0 _exit () at bionic/libc/arch-arm/syscalls/_exit.S:8 > #1 0x410dc6fe in mozilla::dom::ContentChild::QuickExit (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/ipc/ContentChild.cpp:968 > #2 0x410dc71e in mozilla::dom::ContentChild::ProcessingError (this=0x0, what=16225944) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/ipc/ContentChild.cpp:949 > #3 0x411d482c in mozilla::dom::PContentChild::OnProcessingError (this=0x0, code=16225944) at /home/tdz/Projects/mozilla/src/B2G-unagi-inbound/objdir-gecko-debug/ipc/ipdl/PContentChild.cpp:3413 > #4 0x41102b14 in mozilla::ipc::AsyncChannel::ReportConnectionError (this=0x42e31428, channelName=0x420eed71 "RPCChannel") at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/AsyncChannel.cpp:670 > #5 0x41109aca in mozilla::ipc::RPCChannel::OnMaybeDequeueOne (this=0x42e31428) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/RPCChannel.cpp:374 > #6 0x410d52b0 in DispatchToMethod<mozilla::dom::ContentParent, void (mozilla::dom::ContentParent::*)()> (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/tuple.h:383 > #7 RunnableMethod<mozilla::dom::ContentParent, void (mozilla::dom::ContentParent::*)(), Tuple0>::Run (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/task.h:307 > #8 0x41107fc2 in mozilla::ipc::RPCChannel::RefCountedTask::Run (this=0x44e3ad20) at ../../dist/include/mozilla/ipc/RPCChannel.h:425 > #9 mozilla::ipc::RPCChannel::DequeueTask::Run (this=0x44e3ad20) at ../../dist/include/mozilla/ipc/RPCChannel.h:448 > #10 0x4149a92a in MessageLoop::RunTask (this=0xbec42890, task=0x44e3ad20) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:337 > #11 0x4149b154 in MessageLoop::DeferOrRunPendingTask (this=0x0, pending_task=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:345 > #12 0x4149bea6 in MessageLoop::DoWork (this=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:445 > #13 0x411075bc in mozilla::ipc::DoWorkRunnable::Run (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/MessagePump.cpp:42 > #14 0x41455baa in nsThread::ProcessNextEvent (this=0x42e07160, mayWait=<value optimized out>, result=0xbec41d9f) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/threads/nsThread.cpp:627 > #15 0x4141c148 in NS_ProcessNextEvent (thread=0x0, mayWait=0x0) at /home/tdz/Projects/mozilla/src/B2G-unagi-inbound/objdir-gecko-debug/xpcom/build/nsThreadUtils.cpp:238 > #16 0x41107772 in mozilla::ipc::MessagePump::Run (this=0x42e02370, aDelegate=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/MessagePump.cpp:82 > #17 0x411078fa in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x42e02370, aDelegate=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/MessagePump.cpp:231 > #18 0x4149aede in MessageLoop::RunInternal (this=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:219 > #19 0x4149af3e in MessageLoop::RunHandler (this=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:212 > #20 MessageLoop::Run (this=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:186 > #21 0x4103cffe in nsBaseAppShell::Run (this=0x44b46880) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/widget/xpwidgets/nsBaseAppShell.cpp:163 > #22 0x40471d16 in XRE_RunAppShell () at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/toolkit/xre/nsEmbedFunctions.cpp:663 > #23 0x41107864 in mozilla::ipc::MessagePumpForChildProcess::Run (this=0x42e02370, aDelegate=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/MessagePump.cpp:198 > #24 0x4149aede in MessageLoop::RunInternal (this=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:219 > #25 0x4149af3e in MessageLoop::RunHandler (this=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:212 > #26 MessageLoop::Run (this=0xbec42890) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/chromium/src/base/message_loop.cc:186 > #27 0x40472642 in XRE_InitChildProcess (aArgc=0x2, aArgv=<value optimized out>, aProcess=1122178048) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/toolkit/xre/nsEmbedFunctions.cpp:497 > #28 0x00008682 in main (argc=0x7, argv=0xbec42a24) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/app/MozillaRuntimeMain.cpp:60 Frame 4 shows up in the logcat as > I/Gecko ( 435): > I/Gecko ( 435): ###!!! [Child][RPCChannel] Error: Channel closing: too late to send/recv, messages will be lost > I/Gecko ( 435): Afterwards, the program terminates. It looks like the order of operation is incorrect here: some messages are being send when the channel is about to be closed. I've also seen this line in logcats when the audio was not paused, so I suspect it just happens later in this case.

For reference, here is the stack trace for exiting the app while it's still playing. We still trigger the same error, but it happens later during the shutdown. > gdb> bt > #0 _exit () at bionic/libc/arch-arm/syscalls/_exit.S:8 > #1 0x410db6fe in mozilla::dom::ContentChild::QuickExit (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/ipc/ContentChild.cpp:968 > #2 0x410db71e in mozilla::dom::ContentChild::ProcessingError (this=0x0, what=23582360) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/ipc/ContentChild.cpp:949 > #3 0x411d382c in mozilla::dom::PContentChild::OnProcessingError (this=0x0, code=23582360) at /home/tdz/Projects/mozilla/src/B2G-unagi-inbound/objdir-gecko-debug/ipc/ipdl/PContentChild.cpp:3413 > #4 0x41101b14 in mozilla::ipc::AsyncChannel::ReportConnectionError (this=0x42e34428, channelName=0x420ee922 "SyncChannel") at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/AsyncChannel.cpp:670 > #5 0x4110b30e in mozilla::ipc::SyncChannel::Send (this=0x42e34428, _msg=<value optimized out>, reply=0xbec7da68) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/SyncChannel.cpp:88 > #6 0x411086e6 in mozilla::ipc::RPCChannel::Send (this=0x42e34428, msg=0x43dfec80, reply=0xbec7da68) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/RPCChannel.cpp:118 > #7 0x411dad42 in mozilla::dom::PContentChild::SendAudioChannelUnregisterType (this=0x42e34418, aType=@0xbec7db8c, aElementHidden=@0xbec7db90) at /home/tdz/Projects/mozilla/src/B2G-unagi-inbound/objdir-gecko-debug/ipc/ipdl/PContentChild.cpp:2033 > #8 0x40bbf6d8 in mozilla::dom::AudioChannelServiceChild::UnregisterAudioChannelAgent (this=0x47edf980, aAgent=0x47f1b2e0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/audiochannel/AudioChannelServiceChild.cpp:123 > #9 0x40bbfba2 in mozilla::dom::AudioChannelAgent::StopPlaying (this=0x47f1b2e0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/audiochannel/AudioChannelAgent.cpp:122 > #10 0x409d4d84 in mozilla::dom::HTMLMediaElement::UpdateAudioChannelPlayingState (this=0x43d25bc0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLMediaElement.cpp:3760 > #11 0x40997c5e in mozilla::dom::HTMLAudioElement::UpdateAudioChannelPlayingState (this=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLAudioElement.cpp:277 > #12 0x409d3aac in mozilla::dom::HTMLMediaElement::AddRemoveSelfReference (this=0x43d25bc0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLMediaElement.cpp:3330 > #13 0x409d402c in mozilla::dom::HTMLMediaElement::Pause (this=0x43d25bc0, aRv=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLMediaElement.cpp:1467 > #14 0x409d4094 in mozilla::dom::HTMLMediaElement::Pause (this=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLMediaElement.cpp:1481 > #15 0x409978fc in mozilla::dom::HTMLAudioElement::Pause (this=0x0) at ../../../../dist/include/mozilla/dom/HTMLAudioElement.h:42 > #16 0x409d28d4 in mozilla::dom::HTMLMediaElement::UnbindFromTree (this=0x0, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLMediaElement.cpp:2323 > #17 0x408bc4ca in mozilla::dom::Element::UnbindFromTree (this=0x458d7650, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/base/src/Element.cpp:1329 > #18 0x40987d7e in nsGenericHTMLElement::UnbindFromTree (this=0x458d7650, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/nsGenericHTMLElement.cpp:655 > #19 0x408bc4ca in mozilla::dom::Element::UnbindFromTree (this=0x458d0290, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/base/src/Element.cpp:1329 > #20 0x40987d7e in nsGenericHTMLElement::UnbindFromTree (this=0x458d0290, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/nsGenericHTMLElement.cpp:655 > #21 0x408bc4ca in mozilla::dom::Element::UnbindFromTree (this=0x4588abf0, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/base/src/Element.cpp:1329 > #22 0x40987d7e in nsGenericHTMLElement::UnbindFromTree (this=0x4588abf0, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/nsGenericHTMLElement.cpp:655 > #23 0x4099c028 in mozilla::dom::HTMLBodyElement::UnbindFromTree (this=0x4588abf0, aDeep=0x1, aNullParent=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLBodyElement.cpp:357 > #24 0x408bc4ca in mozilla::dom::Element::UnbindFromTree (this=0x4583c9a0, aDeep=0x1, aNullParent=0x1) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/base/src/Element.cpp:1329 > #25 0x40987d7e in nsGenericHTMLElement::UnbindFromTree (this=0x4583c9a0, aDeep=0x1, aNullParent=0x1) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/nsGenericHTMLElement.cpp:655 > #26 0x409f64dc in mozilla::dom::HTMLSharedElement::UnbindFromTree (this=0x4583c9a0, aDeep=0x1, aNullParent=0x1) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/content/src/HTMLSharedElement.cpp:305 > #27 0x408a8b60 in nsDocument::cycleCollection::UnlinkImpl (p=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/base/src/nsDocument.cpp:1815 > #28 0x40a217ba in nsHTMLDocument::cycleCollection::UnlinkImpl (p=0x4519d800) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/content/html/document/src/nsHTMLDocument.cpp:231 > #29 0x41465a14 in nsCycleCollector::CollectWhite (this=0x42e51000, aListener=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/base/nsCycleCollector.cpp:2402 > #30 0x41465ac0 in nsCycleCollector::FinishCollection (this=0x0, aListener=0x167d698) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/base/nsCycleCollector.cpp:2831 > #31 0x41465b7a in nsCycleCollector::MainThreadCollect (this=0x42e51000, aMergeZones=0x0, aResults=0x0, aTryCollections=0x5, aListener=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/base/nsCycleCollector.cpp:2752 > #32 0x41465c7e in nsCycleCollector::Shutdown (this=0x42e51000) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/base/nsCycleCollector.cpp:2866 > #33 0x41465cd8 in nsCycleCollector_shutdown () at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/base/nsCycleCollector.cpp:3065 > #34 0x41420972 in mozilla::ShutdownXPCOM (servMgr=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/build/nsXPComInit.cpp:647 > #35 0x41420d0c in NS_ShutdownXPCOM (servMgr=0x0) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/xpcom/build/nsXPComInit.cpp:536 > #36 0x404717c0 in XRE_TermEmbedding () at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/toolkit/xre/nsEmbedFunctions.cpp:196 > #37 0x41109532 in mozilla::ipc::ScopedXREEmbed::Stop (this=0x42e34658) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/glue/ScopedXREEmbed.cpp:110 > #38 0x410d40c0 in mozilla::dom::ContentProcess::CleanUp (this=<value optimized out>) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/dom/ipc/ContentProcess.cpp:37 > #39 0x40471680 in XRE_InitChildProcess (aArgc=0x2, aArgv=<value optimized out>, aProcess=1122190336) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/toolkit/xre/nsEmbedFunctions.cpp:502 > #40 0x00008682 in main (argc=0x7, argv=0xbec82a24) at /home/tdz/Projects/mozilla/src/mozilla-inbound/bug-867396/ipc/app/MozillaRuntimeMain.cpp:60 > gdb>

This bug seems to be related to bug 871383 and bug 870327

The patch fixes the reported problem by treating closing connections as still connected. It doesn't seem like the full solution, but might be a start. Nico, I see you have been working on AsyncChannel. Fell free to re-assign if you don't work in this any more. Dave, nsVolumeService.spp crashed during shutdown. The patch contains a fix for this, but I'm not sure if the problem isn't somewhere else. Thanks everyone!

Comment on attachment 748847 [details] [diff] [review] Remain connected while closing app Review of attachment 748847 [details] [diff] [review]: ----------------------------------------------------------------- The nsVolumeService.cpp change looks fine to me.

Comment on attachment 748847 [details] [diff] [review] Remain connected while closing app Review of attachment 748847 [details] [diff] [review]: ----------------------------------------------------------------- Seems like a reasonable change. I am not close enough to this code right now to predict if it will cause unexpected interactions, however.

Hey Ben! I added you as reviewer because I was told that you know some of that code. Could you have a look? This issue's deadline is tomorrow, but it's a one-liner, so it shouldn't take much time. Thanks a lot! Thomas

I've read over this bug several times now and I'm at a loss... What is the problem that we are trying to solve here? The change proposed in attachment 749827 [details] [diff] [review] is quite scary and almost surely not what we want to do.

The problem is that apps aborts themselves during shutdown because the RPC channel to the main process is already closed. During app shutdown the RPC channel to the main process gets set to state 'ChannelClosing'. The app expects the channel to be open during shutdown, or otherwise it aborts itself. For the music app, this can lead to a crash in the mediaserver (depending on what state the mediaserver is in). This crash is also the problem that has been reported originally. To fix this problem we need to execute the app's shutdown code, which sets the mediaserver to a valid state. The current fix is to treat an RPC channel that is in the state ChannelClosing as open.

But what happens if the process is killed without a chance to shutdown (like out-of-memory).

(In reply to Dave Hylands [:dhylands] from comment #33) > But what happens if the process is killed without a chance to shutdown (like > out-of-memory). Sotaro already fired a Bug 871018 for this situation.

(In reply to Marco Chen [:mchen] from comment #34) > Sotaro already fired a Bug 871018 for this situation. That should be sufficient to solve this bug then, right? Child processes can be killed at any time for a variety of reasons. IMO we shouldn't make any risky changes to the IPC infrastructure that might help them shut down a little more cleanly in one particular case.

Another possible thing we could do is to detect the dead child process in the parent and alert the mediaserver from there...

android Binder ipc has a capability to detect "binder object dead event". The mediaserver crash happened just because of bug in OMXNodeInstance. attachment 748235 [details] [diff] [review] in Bug 871018 fix the crash.

Ok. Can we just land attachment 864188 and call this done?

> That should be sufficient to solve this bug then, right? Yes. > Child processes can be killed at any time for a variety of reasons. IMO we > shouldn't make any risky changes to the IPC infrastructure that might help > them shut down a little more cleanly in one particular case. If we want to fix the problem by merging the patch from 871018, I'm ok with this. But in general, I don't think we should avoid fixing bugs just because the fix is risky. Especially in the cases like this one, where it looks like the RPC protocol or implementation is broken. Anyway, thanks Ben for having a look here.

Please make this bug leo-, and make bug 871018 leo+ instead.

(In reply to ben turner [:bent] from comment #38) > Ok. Can we just land attachment 864188 and call this done? Yes.

This problem is already fixed by Bug 871018.