Bug 193770

Summary: [ Mojave Release ] ProcessSwap.PageShowHide is a flakey API crash
Product: WebKit Reporter: Truitt Savell <tsavell>
Component: Tools / TestsAssignee: Chris Dumez <cdumez>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: achristensen, ap, beidson, cdumez, ggaren, jlewis3, koivisto, lforschler, ryanhaddad
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch none

Truitt Savell
Reported 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
Attachments
Patch (1.92 KB, patch)
2019-01-24 09:20 PST, Chris Dumez 		no flags
DetailsFormatted DiffDiff
View All Add attachment proposed patch, testcase, etc.
Chris Dumez
Comment 1 2019-01-24 09:13:50 PST
No way to get the crash trace?
Chris Dumez
Comment 2 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
Chris Dumez
Comment 3 2019-01-24 09:20:40 PST
Created attachment 360016 [details] Patch
Chris Dumez
Comment 4 2019-01-24 09:56:38 PST
Antti's patch fixes this too. *** This bug has been marked as a duplicate of bug 193716 ***
Antti Koivisto
Comment 5 2019-01-24 10:16:09 PST
I'm not entirely convinced that that patch fixes any existing flakiness.
Chris Dumez
Comment 6 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.
Chris Dumez
Comment 7 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.
Antti Koivisto
Comment 8 2019-01-24 10:22:09 PST
I think I saw this test flake once even with delaying applied (hanging in the wait loop).
Antti Koivisto
Comment 9 2019-01-24 10:23:17 PST
But bots will tell.
Note You need to log in before you can comment on or make changes to this bug.