Bug 265994

Detected running API tests in Debug mode: Unhandled network process message 'NetworkStorageManager_DisconnectFromStorageArea' SHOULD NEVER BE REACHED /app/webkit/Source/WebKit/NetworkProcess/NetworkConnectionToWebProcess.cpp(340) : virtual void WebKit::NetworkConnectionToWebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) Mesa: The provided filesystem timestamp for the cache is bogus! Disabling On-disk cache. 1 0x7f8128f6aadd WTFCrash 2 0x7f81332f75bd WTF::isIntegralOrPointerType() 3 0x7f8133c9143e WebKit::NetworkConnectionToWebProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 4 0x7f813417c925 IPC::Connection::dispatchMessage(IPC::Decoder&) 5 0x7f813417cb70 IPC::Connection::dispatchMessage(std::unique_ptr<IPC::Decoder, std::default_delete<IPC::Decoder> >) 6 0x7f813417cf2e IPC::Connection::dispatchOneIncomingMessage() 7 0x7f813417c568 operator() 8 0x7f8134183ce2 call 9 0x7f812795c98d WTF::Function<void ()>::operator()() const 10 0x7f8129006f07 WTF::RunLoop::performWork() 11 0x7f81290c0474 operator() 12 0x7f81290c0498 _FUN 13 0x7f81290c0407 operator() 14 0x7f81290c0455 _FUN 15 0x7f8124917d36 g_main_context_dispatch 16 0x7f81249752b8 g_main_context_iterate.isra.0 17 0x7f81249173ff g_main_loop_run 18 0x7f81290c0ac8 WTF::RunLoop::run() 19 0x7f813401bdad WebKit::AuxiliaryProcessMainBase<WebKit::NetworkProcess, false>::run(int, char**) 20 0x7f8134018ef6 int WebKit::AuxiliaryProcessMain<WebKit::NetworkProcessMainSoup>(int, char**) 21 0x7f813400a8af WebKit::NetworkProcessMain(int, char**) 22 0x562df2678959 main 23 0x7f8121b5208a __libc_start_call_main 24 0x7f8121b5214b __libc_start_main 25 0x562df2678875 _start

Pull request: https://github.com/WebKit/WebKit/pull/21437

<rdar://problem/119663231>

Starting from iOS 17.4.1, WKWebView occasionally experiences this issue, which we are unable to reproduce, but this problem needs to be fixed by WebKit.

I also observed a following crash after this reported crash when run API tests in TestWebKitAPI/WPE/TestWebKitWebContext. Logs for the 2nd crash - ASSERTION FAILED: Completion handler should always be called !m_function /app/webkit/WebKitBuild/WPE/Release/WTF/Headers/wtf/CompletionHandler.h(66) : WTF::CompletionHandler<Out(In ...)>::~CompletionHandler() [with Out = void; In = {}] 1 0x7f21c14789ea WebKit::LayerTreeHost::~LayerTreeHost() 2 0x7f21c1478ba7 WebKit::DrawingAreaCoordinatedGraphics::~DrawingAreaCoordinatedGraphics() 3 0x7f21c1478c39 WebKit::DrawingAreaCoordinatedGraphics::~DrawingAreaCoordinatedGraphics() 4 0x7f21c143dce4 WebKit::WebPage::close() 5 0x7f21c0955d73 WebKit::WebPage::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 6 0x7f21c0e32527 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) 7 0x7f21c0e43196 WebKit::AuxiliaryProcess::dispatchMessage(IPC::Connection&, IPC::Decoder&) 8 0x7f21c0819781 WebKit::AuxiliaryProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 9 0x7f21c0e2c72d IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) [clone .part.0] 10 0x7f21c0e2ce57 IPC::Connection::dispatchOneIncomingMessage() 11 0x7f21c31f5a5f WTF::RunLoop::performWork() 12 0x7f21c32c28d9 WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) 13 0x7f21c32c3caf WTF::RunLoop::{lambda(_GSource*, int (*)(void*), void*)#1}::_FUN(_GSource*, int (*)(void*), void*) 14 0x7f21bbf9ad36 g_main_context_dispatch 15 0x7f21bbff82b8 g_main_context_iterate.isra.0 16 0x7f21bbf9a3ff g_main_loop_run 17 0x7f21c32c3e98 WTF::RunLoop::run() 18 0x7f21c14a184f int WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) 19 0x7f21bb7a708a __libc_start_call_main 20 0x7f21bb7a714b __libc_start_main 21 0x5633952ca7e5 _start

*** Bug 281137 has been marked as a duplicate of this bug. ***

(In reply to zsun from comment #5) > I also observed a following crash after this reported crash when run API > tests in TestWebKitAPI/WPE/TestWebKitWebContext. Logs for the 2nd crash - > > ASSERTION FAILED: Completion handler should always be called > !m_function > /app/webkit/WebKitBuild/WPE/Release/WTF/Headers/wtf/CompletionHandler.h(66) > : WTF::CompletionHandler<Out(In ...)>::~CompletionHandler() [with Out = > void; In = {}] > 1 0x7f21c14789ea WebKit::LayerTreeHost::~LayerTreeHost() > 2 0x7f21c1478ba7 > WebKit::DrawingAreaCoordinatedGraphics::~DrawingAreaCoordinatedGraphics() > 3 0x7f21c1478c39 > WebKit::DrawingAreaCoordinatedGraphics::~DrawingAreaCoordinatedGraphics() > 4 0x7f21c143dce4 WebKit::WebPage::close() > 5 0x7f21c0955d73 WebKit::WebPage::didReceiveMessage(IPC::Connection&, > IPC::Decoder&) > 6 0x7f21c0e32527 > IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) > 7 0x7f21c0e43196 > WebKit::AuxiliaryProcess::dispatchMessage(IPC::Connection&, IPC::Decoder&) > 8 0x7f21c0819781 > WebKit::AuxiliaryProcess::didReceiveMessage(IPC::Connection&, IPC::Decoder&) > 9 0x7f21c0e2c72d > IPC::Connection::dispatchMessage(WTF::UniqueRef<IPC::Decoder>) [clone > .part.0] > 10 0x7f21c0e2ce57 IPC::Connection::dispatchOneIncomingMessage() > 11 0x7f21c31f5a5f WTF::RunLoop::performWork() > 12 0x7f21c32c28d9 WTF::RunLoop::RunLoop()::{lambda(void*)#1}::_FUN(void*) > 13 0x7f21c32c3caf WTF::RunLoop::{lambda(_GSource*, int (*)(void*), > void*)#1}::_FUN(_GSource*, int (*)(void*), void*) > 14 0x7f21bbf9ad36 g_main_context_dispatch > 15 0x7f21bbff82b8 g_main_context_iterate.isra.0 > 16 0x7f21bbf9a3ff g_main_loop_run > 17 0x7f21c32c3e98 WTF::RunLoop::run() > 18 0x7f21c14a184f int > WebKit::AuxiliaryProcessMain<WebKit::WebProcessMainWPE>(int, char**) > 19 0x7f21bb7a708a __libc_start_call_main > 20 0x7f21bb7a714b __libc_start_main > 21 0x5633952ca7e5 _start Correct myself - this might not be related.

Analysis so far - 1. WebsiteDataStore::~WebsiteDataStore -> NetworkProcessProxy::removeSession->NetworkProcess::destroySession->NetworkStorageManager::close->connection.removeWorkQueueMessageReceiver() 2. In StorageAreaMap::~StorageAreaMap() ->StorageAreaMap::didConnect()->connection->send(Messages::NetworkStorageManager::DisconnectFromStorageArea() This seems a racing condition, when 1 runs quick, the WorkQueueMessageReceiver has already been removed from the work queue when we call 2, so connection does not know how to handle the message. This case can be produced with test TestWebKitWebContext -p /webkit/WebKitWebContext/uri-scheme.

See bug 284812.