Bug 193770 - [ Mojave Release ] ProcessSwap.PageShowHide is a flakey API crash
Summary: [ Mojave Release ] ProcessSwap.PageShowHide is a flakey API crash
Status: RESOLVED DUPLICATE of bug 193716
Alias: None
Product: WebKit
Classification: Unclassified
Component: Tools / Tests (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Chris Dumez
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-24 09:04 PST by Truitt Savell
Modified: 2019-01-24 13:38 PST (History)
9 users (show)

See Also:


Attachments
Patch (1.92 KB, patch)
2019-01-24 09:20 PST, Chris Dumez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Truitt Savell 2019-01-24 09:04:24 PST
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
Comment 1 Chris Dumez 2019-01-24 09:13:50 PST
No way to get the crash trace?
Comment 2 Chris Dumez 2019-01-24 09:17:34 PST
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
Comment 3 Chris Dumez 2019-01-24 09:20:40 PST
Created attachment 360016 [details]
Patch
Comment 4 Chris Dumez 2019-01-24 09:56:38 PST
Antti's patch fixes this too.

*** This bug has been marked as a duplicate of bug 193716 ***
Comment 5 Antti Koivisto 2019-01-24 10:16:09 PST
I'm not entirely convinced that that patch fixes any existing flakiness.
Comment 6 Chris Dumez 2019-01-24 10:16:55 PST
(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.
Comment 7 Chris Dumez 2019-01-24 10:17:38 PST
(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.
Comment 8 Antti Koivisto 2019-01-24 10:22:09 PST
I think I saw this test flake once even with delaying applied (hanging in the wait loop).
Comment 9 Antti Koivisto 2019-01-24 10:23:17 PST
But bots will tell.