Bug 226125 – [ Debug ] TestWebKitAPI.IPCTestingAPI.CanDetectNilReplyBlocks (API-tests) is a constant crash

• Component: New Bugs
• Status: RESOLVED FIXED

[Robert Jenner]

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

[Robert Jenner]

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.

[Robert Jenner]

Created attachment 429364 [details]
Full crashlog for API

Attaching full crashlog for crashing API.

[Radar WebKit Bug Importer]

<rdar://problem/78334962>

[Ryosuke Niwa]

We need to skip this test in debug.

[Ryosuke Niwa]

I don't think this is correct to call this a regression. There is nothing that regressed since this is a new test.

[Robert Jenner]

(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.

[Ryosuke Niwa]

(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 :)

[Julian Gonzalez]

Created attachment 429399 [details]
Patch

[EWS]

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].

[Alexey Proskuryakov]

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.

[Ryosuke Niwa]

(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.