WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 162938
136012
REGRESSION (
r172660
): WebKit2.TerminateTwice asserts
https://bugs.webkit.org/show_bug.cgi?id=136012
Summary
REGRESSION (r172660): WebKit2.TerminateTwice asserts
Alexey Proskuryakov
Reported
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
Attachments
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
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
>.
Radar WebKit Bug Importer
Comment 2
2015-07-09 12:32:38 PDT
<
rdar://problem/21751480
>
David Kilzer (:ddkilzer)
Comment 3
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
David Kilzer (:ddkilzer)
Comment 4
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
>
Anders Carlsson
Comment 5
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
***
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug