1801281 - [@ mozilla::dom::FileSystemWritableFileStreamParent::Close()]

Status: RESOLVED FIXED

(Core :: DOM: File, defect, P2)

Description

[Olli Pettay [:smaug][[e-mail]]]

When trying to land the crashtest for bug 1800470, I got the following crash on MacOS [TV]

#01: mozilla::dom::FileSystemWritableFileStreamParent::Close() [dom/fs/parent/FileSystemWritableFileStreamParent.cpp:0]
#02: mozilla::ipc::IProtocol::DestroySubtree(mozilla::ipc::IProtocol::ActorDestroyReason) [ipc/glue/ProtocolUtils.cpp:586]
#03: mozilla::ipc::IProtocol::DestroySubtree(mozilla::ipc::IProtocol::ActorDestroyReason) [ipc/glue/ProtocolUtils.cpp:0]
#04: mozilla::dom::PFileSystemManagerParent::OnChannelClose() [s3:gecko-generated-sources:43e973160b2fd7787130f11674d5a6a1cdaca46fff094dd8e9259992e9801ab3849ab477dd30f81c63d733900ad23202dd18e32b94e5ea6b1dcf50f4e962f519/ipc/ipdl/PFileSystemManagerParent.cpp::1180]
#05: mozilla::ipc::MessageChannel::OnNotifyMaybeChannelError() [ipc/glue/MessageChannel.cpp:2035]
#06: mozilla::detail::RunnableMethodImpl<mozilla::ipc::MessageChannel*, void (mozilla::ipc::MessageChannel::)(), false, (mozilla::RunnableKind)1, >::Run() [xpcom/threads/nsThreadUtils.h:1218]
#07: mozilla::TaskQueue::Runner::Run() [xpcom/threads/TaskQueue.cpp:266]
#08: nsThreadPool::Run() [xpcom/threads/nsThreadPool.cpp:311]
#09: nsThread::ProcessNextEvent(bool, bool) [xpcom/threads/nsThread.cpp:0]
#10: NS_ProcessNextEvent(nsIThread*, bool) [xpcom/threads/nsThreadUtils.cpp:474]
#11: mozilla::ipc::MessagePumpForNonMainThreads::Run(base::MessagePump::Delegate*) [ipc/glue/MessagePump.cpp:301]
#12: MessageLoop::Run() [ipc/chromium/src/base/message_loop.cc:357]
#13: nsThread::ThreadFunc(void*) [xpcom/threads/nsThread.cpp:385]
#14: _pt_root [nsprpub/pr/src/pthreads/ptthread.c:204]

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

If I'm reading the code correctly, mManager is never null, but DataManagerStrongRef may return null
https://searchfox.org/mozilla-central/rev/aa329cf7506ddd966542e642ec00223fd7461599/dom/fs/parent/FileSystemWritableFileStreamParent.cpp#40
https://searchfox.org/mozilla-central/rev/aa329cf7506ddd966542e642ec00223fd7461599/dom/fs/parent/FileSystemManagerParent.cpp#496

Comment 2

[Jan Varga [:janv]]

I think I know what's wrong.

Comment 3

[Jan Varga [:janv]]

Attachment: Bug 1801281 - Make sure that FileSystemManagerParent::mDataManager is set to null after subprotocol destruction; r=smaug,#dom-storage

Calling AllowToClose in OnChannelClose/OnChannelError is tricky because we can
only do it either before or after calling
PFileSystemManagerParent::OnChannelClose/OnChannelError. When we call it before,
it can happen that mDataManager is already null when a subprotocol tries to use in its ActorDestroy (destruction of subprotocols is triggered by calling
PFileSystemManagerParent::OnChannelClose/OnChannelError). Calling AllowToClose
after calling PFileSystemManagerParent::OnChannelClose/OnChannelError makes no
sense because the object is deleted at that point.
The solution is to override ActorDestroy instead of overriding
OnChannelClose/OnChannelError. When ActorDestroy is called all subprotocols are
already destroyed but the object itself hasn't been deleted yet.

Comment 4

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/de595a0ae022
Make sure that FileSystemManagerParent::mDataManager is set to null after subprotocol destruction; r=smaug

Comment 5

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/de595a0ae022