WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
148951
fast/dom/rtl-scroll-to-leftmost-and-resize.html is a flaky timeout - IPC drops messages
https://bugs.webkit.org/show_bug.cgi?id=148951
Summary
fast/dom/rtl-scroll-to-leftmost-and-resize.html is a flaky timeout - IPC drop...
Alexey Proskuryakov
Reported
2015-09-07 23:40:14 PDT
fast/dom/rtl-scroll-to-leftmost-and-resize.html frequently times out on Mac. This usually reproduces the problem on my MacBook Pro: run-webkit-tests fast/dom/rtl-scroll-to-leftmost-and-resize.html --repeat 100 --no-build --no-retry -f Via printf debugging, I found that WebContent sends DrawingAreaProxy::DidUpdateGeometry, but the message never reaches Connection::dispatchMessage in UI process.
Attachments
proposed fix
(3.54 KB, patch)
2015-09-08 22:59 PDT
,
Alexey Proskuryakov
no flags
Details
Formatted Diff
Diff
proposed fix
(4.60 KB, patch)
2015-09-08 23:17 PDT
,
Alexey Proskuryakov
no flags
Details
Formatted Diff
Diff
Show Obsolete
(1)
View All
Add attachment
proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1
2015-09-07 23:46:09 PDT
The message doesn't even reach Connection::enqueueIncomingMessage in UI process...
Alexey Proskuryakov
Comment 2
2015-09-08 00:17:04 PDT
Okay, a little less mysterious. We do get the message in Connection::processIncomingMessage in UI process, but in the failing case, it gets processed by this block: // Check if we're waiting for this message. { std::lock_guard<Lock> lock(m_waitForMessageMutex); if (m_waitingForMessage && m_waitingForMessage->messageReceiverName == message->messageReceiverName() && m_waitingForMessage->messageName == message->messageName() && m_waitingForMessage->destinationID == message->destinationID()) { m_waitingForMessage->decoder = WTF::move(message); ASSERT(m_waitingForMessage->decoder); m_waitForMessageCondition.notifyOne(); return; } ... So, Connection::waitForAndDispatchImmediately must be buggy, the message that it's waiting for can get dropped altogether. Once a DidUpdateGeometry message gets dropped, that makes UI process never again send any DrawingArea::UpdateGeometry messages for this drawing area.
Alexey Proskuryakov
Comment 3
2015-09-08 09:55:26 PDT
Added a test expectation in
r189491
. But this likely affects more tests.
Alexey Proskuryakov
Comment 4
2015-09-08 22:59:34 PDT
Created
attachment 260838
[details]
proposed fix
Alexey Proskuryakov
Comment 5
2015-09-08 23:17:45 PDT
Created
attachment 260841
[details]
proposed fix Actually, let's also make sure that we don't overwrite m_waitingForMessage->decoder when two messages come in quickly.
WebKit Commit Bot
Comment 6
2015-09-09 13:39:42 PDT
Comment on
attachment 260841
[details]
proposed fix Clearing flags on attachment: 260841 Committed
r189546
: <
http://trac.webkit.org/changeset/189546
>
WebKit Commit Bot
Comment 7
2015-09-09 13:39:46 PDT
All reviewed patches have been landed. Closing bug.
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