1638807 - Crash in [@ IPCError-browser | ShutDownKill | __pthread_cond_wait | mozilla::ipc::IProtocol::ChannelSend]

Status: RESOLVED DUPLICATE of bug 1623768

(Core :: Layout: Text and Fonts, defect)

Description

[Gabriele Svelto [:gsvelto]]

This bug is for crash report bp-77c25824-f565-40b3-96dc-185b60200517.

Top 10 frames of crashing thread:

0 libpthread.so.0 __pthread_cond_wait 
1 firefox-bin mozilla::detail::ConditionVariableImpl::wait_for mozglue/misc/ConditionVariable_posix.cpp:115
2 libxul.so mozilla::ipc::IProtocol::ChannelSend ipc/glue/ProtocolUtils.cpp:482
3 libxul.so mozilla::dom::PContentChild::SendGetFontListShmBlock ipc/ipdl/PContentChild.cpp:5458
4 libxul.so mozilla::fontlist::FontList::GetBlockFromParent gfx/thebes/SharedFontList.cpp:563
5 libxul.so mozilla::fontlist::FontList::UpdateShmBlocks gfx/thebes/SharedFontList.cpp:583
6 libxul.so mozilla::fontlist::FontList::FontList gfx/thebes/SharedFontList.cpp:503
7 libxul.so gfxPlatformFontList::InitFontList gfx/thebes/gfxPlatformFontList.cpp:482
8 libxul.so gfxPlatformGtk::CreatePlatformFontList gfx/thebes/gfxPlatformGtk.cpp:255
9 libxul.so gfxPlatform::Init gfx/thebes/gfxPlatform.cpp:990

This appears to be a deadlock during content process shutdown: the content process has received a shutdown message but it's stuck in mozilla::dom::PContentChild::SendGetFontListShmBlock() which is a synchronous IPC call. So apparently the main process did not respond to that call before sending the shutdown message, leaving the content process stuck and unable to shut down. This seems to have started with buildid 20200514211114.

Comment 1

[Jonathan Kew [:jfkthame]]

This must be a case where the browser is being shut down while a content process is still starting up... we're in gfxPlatform::Init, which AFAIK is only called during process startup. So it seems like something that could happen if the browser is launched and then immediately quit, but it could also happen at other times if a new content process is being launched, and then the main process is asked to shut down while that's happening.

What's the proper way to handle this -- should the main process be responsible to ensure it has responded to any sync IPC calls before it sends a shutdown message to a child (and when it knows it wants to send a shutdown message, it would have to reject any new sync calls)?

Comment 2

[Andrew McCreight [:mccr8]]

This looks like a dupe of bug 1623768.

Comment 3

[Gabriele Svelto [:gsvelto]]

Yep, definitely a duplicate.