Bug 193770 – [ Mojave Release ] ProcessSwap.PageShowHide is a flakey API crash

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Tools / Tests

[Truitt Savell]

ProcessSwap.PageShowHide is a flakey API crash on Mojave for Release builds. failure only happens every 25 runs or so, very infrequently. No repro case yet. 

Crashed

    TestWebKitAPI.ProcessSwap.PageShowHide
        _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
        Received data during response processing, queuing it.
        _RegisterApplication(), FAILED TO establish the default connection to the WindowServer, _CGSDefaultConnection() is NULL.
        Received data during response processing, queuing it.
        2019-01-18 06:52:59.632 com.apple.WebKit.WebContent.Development[41741:67269154] Application does not have the 'com.apple.security.network.client' entitlement.

API Log:
https://build.webkit.org/builders/Apple%20Mojave%20Release%20WK2%20%28Tests%29/builds/1886/steps/run-api-tests/logs/stdio

run with failure:
https://build.webkit.org/builders/Apple%20Mojave%20Release%20WK2%20%28Tests%29/builds/2019

[Chris Dumez]

No way to get the crash trace?

[Chris Dumez]

Never mind, I was able to reproduce:
Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000000
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [25431]

VM Regions Near 0:
--> 
    __TEXT                 0000000107242000-00000001076c7000 [ 4628K] r-x/rwx SM=COW  /Volumes/VOLUME/*

Thread 0 Crashed:: Dispatch queue: com.apple.main-thread
0   libsystem_platform.dylib      	0x00007fff77c4c712 _platform_strlen + 18
1   TestWebKitAPI                 	0x00000001074d1b88 TestWebKitAPI::Printer::OnTestPartResult(testing::TestPartResult const&) + 302 (TestsController.cpp:43)
2   TestWebKitAPI                 	0x00000001075b1c34 testing::internal::TestEventRepeater::OnTestPartResult(testing::TestPartResult const&) + 48
3   TestWebKitAPI                 	0x00000001075a5155 testing::UnitTest::AddTestPartResult(testing::TestPartResult::Type, char const*, int, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 717
4   TestWebKitAPI                 	0x00000001075ae14d testing::internal::ReportFailureInUnknownLocation(testing::TestPartResult::Type, std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > const&) + 64
5   TestWebKitAPI                 	0x00000001075aea41 void testing::internal::HandleExceptionsInMethodIfSupported<testing::Test, void>(testing::Test*, void (testing::Test::*)(), char const*) + 236
6   TestWebKitAPI                 	0x00000001075ae906 testing::Test::Run() + 184
7   TestWebKitAPI                 	0x00000001075af850 testing::TestInfo::Run() + 220
8   TestWebKitAPI                 	0x00000001075affd9 testing::TestCase::Run() + 273
9   TestWebKitAPI                 	0x00000001075b96e3 testing::internal::UnitTestImpl::RunAllTests() + 697
10  TestWebKitAPI                 	0x00000001075b9313 bool testing::internal::HandleExceptionsInMethodIfSupported<testing::internal::UnitTestImpl, bool>(testing::internal::UnitTestImpl*, bool (testing::internal::UnitTestImpl::*)(), char const*) + 72
11  TestWebKitAPI                 	0x00000001075b929e testing::UnitTest::Run() + 108
12  TestWebKitAPI                 	0x00000001074d19ec TestWebKitAPI::TestsController::run(int, char**) + 120 (TestsController.cpp:86)
13  TestWebKitAPI                 	0x0000000107588729 main + 344 (mainMac.mm:52)
14  libdyld.dylib                 	0x00007fff77a64ed9 start + 1

[Chris Dumez]

Created attachment 360016 [details]
Patch

[Chris Dumez]

Antti's patch fixes this too.

*** This bug has been marked as a duplicate of bug 193716 ***

[Antti Koivisto]

I'm not entirely convinced that that patch fixes any existing flakiness.

[Chris Dumez]

(In reply to Antti Koivisto from comment #5)
> I'm not entirely convinced that that patch fixes any existing flakiness.

I have verified locally that waiting for all 7 messages fixes the flaky crashes.

[Chris Dumez]

(In reply to Chris Dumez from comment #6)
> (In reply to Antti Koivisto from comment #5)
> > I'm not entirely convinced that that patch fixes any existing flakiness.
> 
> I have verified locally that waiting for all 7 messages fixes the flaky
> crashes.

This was a pre-existing issue, your patch just made it even flakier by delaying the Closing.

[Antti Koivisto]

I think I saw this test flake once even with delaying applied (hanging in the wait loop).

[Antti Koivisto]

But bots will tell.