Summary: | [ Mojave Release ] ProcessSwap.PageShowHide is a flakey API crash | ||||||
---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Truitt Savell <tsavell> | ||||
Component: | Tools / Tests | Assignee: | 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
Truitt Savell
2019-01-24 09:04:24 PST
No way to get the crash trace? 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 Created attachment 360016 [details]
Patch
Antti's patch fixes this too. *** This bug has been marked as a duplicate of bug 193716 *** I'm not entirely convinced that that patch fixes any existing flakiness. (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. (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. I think I saw this test flake once even with delaying applied (hanging in the wait loop). But bots will tell. |