TestWebKitAPI.IPCTestingAPI.CanDetectNilReplyBlocks is a constantly crashing API on Debug Catalina and up, as well as on iOS14-Simulator. Coincidentally, it's only running on four queues, and it is constantly crashing on all four of them. HISTORY: https://results.webkit.org/?suite=api-tests&test=TestWebKitAPI.IPCTestingAPI.CanDetectNilReplyBlocks It appears to have been crashing since it was introduced at r277849: https://trac.webkit.org/changeset/277849/webkit CRASH TEXT: TestWebKitAPI.IPCTestingAPI.CanDetectNilReplyBlocks SHOULD NEVER BE REACHED /Volumes/Data/worker/bigsur-debug/build/Source/WebKit/Shared/UserData.cpp(502) : static bool WebKit::UserData::decode(IPC::Decoder &, RefPtr<API::Object> &) 1 0x109e7aff9 WTFCrash 2 0x115f3a95b WTFCrashWithInfo(int, char const*, char const*, int) 3 0x117199a5e WebKit::UserData::decode(IPC::Decoder&, WTF::RefPtr<API::Object, WTF::RawPtrTraits<API::Object>, WTF::DefaultRefDerefTraits<API::Object> >&) 4 0x1171993c9 WebKit::UserData::decode(IPC::Decoder&, WTF::RefPtr<API::Object, WTF::RawPtrTraits<API::Object>, WTF::DefaultRefDerefTraits<API::Object> >&) 5 0x1171993c9 WebKit::UserData::decode(IPC::Decoder&, WTF::RefPtr<API::Object, WTF::RawPtrTraits<API::Object>, WTF::DefaultRefDerefTraits<API::Object> >&) 6 0x1171993c9 WebKit::UserData::decode(IPC::Decoder&, WTF::RefPtr<API::Object, WTF::RawPtrTraits<API::Object>, WTF::DefaultRefDerefTraits<API::Object> >&) 7 0x116b3bc2e WebKit::RemoteObjectInvocation::decode(IPC::Decoder&, WebKit::RemoteObjectInvocation&) 8 0x116251f67 IPC::ArgumentCoder<WebKit::RemoteObjectInvocation, void>::decode(IPC::Decoder&) 9 0x116251d54 IPC::Decoder& IPC::Decoder::operator>><WebKit::RemoteObjectInvocation>(WTF::Optional<WebKit::RemoteObjectInvocation>&) 10 0x116815f97 IPC::TupleDecoderImpl<WebKit::RemoteObjectInvocation>::decode(IPC::Decoder&) 11 0x116815f53 IPC::TupleDecoder<1ul, WebKit::RemoteObjectInvocation>::decode(IPC::Decoder&) 12 0x116815df3 IPC::ArgumentCoder<std::__1::tuple<WebKit::RemoteObjectInvocation>, void>::decode(IPC::Decoder&) 13 0x116815ba4 IPC::Decoder& IPC::Decoder::operator>><std::__1::tuple<WebKit::RemoteObjectInvocation> >(WTF::Optional<std::__1::tuple<WebKit::RemoteObjectInvocation> >&) 14 0x11681595e void IPC::handleMessage<Messages::RemoteObjectRegistry::InvokeMethod, WebKit::RemoteObjectRegistry, void (WebKit::RemoteObjectRegistry::*)(WebKit::RemoteObjectInvocation const&)>(IPC::Decoder&, WebKit::RemoteObjectRegistry*, void (WebKit::RemoteObjectRegistry::*)(WebKit::RemoteObjectInvocation const&)) 15 0x1168157e3 WebKit::RemoteObjectRegistry::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 16 0x1164db675 IPC::MessageReceiverMap::dispatchMessage(IPC::Connection&, IPC::Decoder&) 17 0x11765fc5e WebKit::WebProcessPool::dispatchMessage(IPC::Connection&, IPC::Decoder&) 18 0x11766d2a3 WebKit::WebProcessProxy::didReceiveMessage(IPC::Connection&, IPC::Decoder&) 19 0x115fbbc74 IPC::Connection::dispatchMessage(IPC::Decoder&) 20 0x115fbc43c IPC::Connection::dispatchMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >) 21 0x115fbaa11 IPC::Connection::dispatchIncomingMessages() 22 0x115fdde52 IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >)::$_12::operator()() 23 0x115fddd5e WTF::Detail::CallableWrapper<IPC::Connection::enqueueIncomingMessage(std::__1::unique_ptr<IPC::Decoder, std::__1::default_delete<IPC::Decoder> >)::$_12, void>::call() 24 0x109ea81b2 WTF::Function<void ()>::operator()() const 25 0x109f2b1b5 WTF::RunLoop::performWork() 26 0x109f2fa71 WTF::RunLoop::performWork(void*) 27 0x7fff205bfa8c __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__ 28 0x7fff205bf9f4 __CFRunLoopDoSource0 29 0x7fff205bf774 __CFRunLoopDoSources0 30 0x7fff205be19c __CFRunLoopRun 31 0x7fff205bd75c CFRunLoopRunSpecific
Was able to reproduce the crash at BigSur Debug ToT using the following test: run-api-tests TestWebKitAPI.IPCTestingAPI.CanDetectNilReplyBlocks Full crashlog from my results has been attached below.
Created attachment 429364 [details] Full crashlog for API Attaching full crashlog for crashing API.
<rdar://problem/78334962>
We need to skip this test in debug.
I don't think this is correct to call this a regression. There is nothing that regressed since this is a new test.
(In reply to Ryosuke Niwa from comment #5) > I don't think this is correct to call this a regression. There is nothing > that regressed since this is a new test. Okay, that's fair. As far as your other comment goes for skipping in debug, I have never done this for an API test before. I'm happy to skip this test for debug, but I'm not certain how. I've been led to believe it's not as simple as just updating a test expectation.
(In reply to Robert Jenner from comment #6) > (In reply to Ryosuke Niwa from comment #5) > > I don't think this is correct to call this a regression. There is nothing > > that regressed since this is a new test. > > Okay, that's fair. > > As far as your other comment goes for skipping in debug, I have never done > this for an API test before. I'm happy to skip this test for debug, but I'm > not certain how. I've been led to believe it's not as simple as just > updating a test expectation. I've asked Julian to post a patch :)
Created attachment 429399 [details] Patch
Committed r277916 (238049@main): <https://commits.webkit.org/238049@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 429399 [details].
To clarify, is this correct behavior for this test to assert in debug, or something that we'd like to fix at some point? If it's the former, it would be good to have a comment in code (or at least here) explaining why; and if it's the latter, it would be good to have a bug tracking that or at least a FIXME.
(In reply to Alexey Proskuryakov from comment #10) > To clarify, is this correct behavior for this test to assert in debug, or > something that we'd like to fix at some point? Probably neither. It's okay for this test to hit assertion since we only care that we don't have a crash in release builds but this debug assertion stopped happening in debug build, we don't care either.