Bug 136012

Summary: REGRESSION (r172660): WebKit2.TerminateTwice asserts
Product: WebKit Reporter: Alexey Proskuryakov <ap>
Component: WebKit2Assignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Normal CC: andersca, ddkilzer, kling, webkit-bug-importer
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=162624
Bug Depends on: 162077    
Bug Blocks:    

Description Alexey Proskuryakov 2014-08-15 19:49:52 PDT
http://build.webkit.org/builders/Apple%20Mavericks%20Debug%20WK2%20(Tests)/builds/6284/steps/run-api-tests/logs/stdio

Note: Google Test filter = WebKit2.TerminateTwice
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from WebKit2
[ RUN      ] WebKit2.TerminateTwice
ASSERTION FAILED: m_process->state() != WebProcessProxy::State::Launching
/Volumes/Data/slave/mavericks-debug/build/Source/WebKit2/UIProcess/WebPageProxy.cpp(1876) : void WebKit::WebPageProxy::terminateProcess()
1   0x109ad93b0 WTFCrash
2   0x10b4d6ccc WebKit::WebPageProxy::terminateProcess()
3   0x10b6ddcad WKPageTerminate
4   0x108c921b3 TestWebKitAPI::WebKit2_TerminateTwice_Test::TestBody()
5   0x108e5549a testing::Test::Run()
6   0x108e55d1d testing::internal::TestInfoImpl::Run()
7   0x108e568cd testing::TestCase::Run()
8   0x108e5c657 testing::internal::UnitTestImpl::RunAllTests()
9   0x108e5c2a9 testing::UnitTest::Run()
10  0x108e1c830 TestWebKitAPI::TestsController::run(int, char**)
11  0x108e4bfc5 main
12  0x7fff927d05fd start
13  0x2
Comment 1 Alexey Proskuryakov 2014-08-15 20:03:00 PDT
This is an interesting issue. This test checks for a quick crash in a code path that is still obviously and seriously broken (as far as I can tell). Doing what the test does corrupts WebKit2 data structures in a way that will cause crashes and other bugs later.

So r172660 added an assertion to catch Safari and other clients doing this. So the options are to either remove the assertion and keep the test, or to keep the assertion and remove the test. The fact that the assertion started to fail doesn't mean that anything regressed, it's just a new assertion.

Given the above, I think that keeping the assertion is more valuable. Skipped the test (in debug mode only) in <http://trac.webkit.org/r172680>.
Comment 2 Radar WebKit Bug Importer 2015-07-09 12:32:38 PDT
<rdar://problem/21751480>
Comment 3 David Kilzer (:ddkilzer) 2016-09-16 11:25:38 PDT
This ASSERT was accidentally commented out in r204916 for Bug 161103:

<http://trac.webkit.org/changeset/204916>

I'm assuming the ASSERT is still valid, so will be posting a patch to restore it.

I filed:  Bug 162077: ASSERT accidentally commented out in r204916
Comment 4 David Kilzer (:ddkilzer) 2016-09-16 13:19:29 PDT
(In reply to comment #3)
> This ASSERT was accidentally commented out in r204916 for Bug 161103:
> 
> <http://trac.webkit.org/changeset/204916>
> 
> I'm assuming the ASSERT is still valid, so will be posting a patch to
> restore it.
> 
> I filed:  Bug 162077: ASSERT accidentally commented out in r204916

The ASSERT was re-enabled by:

Committed r206040: <http://trac.webkit.org/changeset/206040>
Comment 5 Anders Carlsson 2016-10-04 15:43:53 PDT
Was fixed with the fix for 162938.

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