Bug 148951 - fast/dom/rtl-scroll-to-leftmost-and-resize.html is a flaky timeout - IPC drops messages
Summary: fast/dom/rtl-scroll-to-leftmost-and-resize.html is a flaky timeout - IPC drop...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit2 (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Alexey Proskuryakov
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-09-07 23:40 PDT by Alexey Proskuryakov
Modified: 2015-09-09 13:39 PDT (History)
4 users (show)

See Also:


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

Note You need to log in before you can comment on or make changes to this bug.
Description Alexey Proskuryakov 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.
Comment 1 Alexey Proskuryakov 2015-09-07 23:46:09 PDT
The message doesn't even reach Connection::enqueueIncomingMessage in UI process...
Comment 2 Alexey Proskuryakov 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.
Comment 3 Alexey Proskuryakov 2015-09-08 09:55:26 PDT
Added a test expectation in r189491. But this likely affects more tests.
Comment 4 Alexey Proskuryakov 2015-09-08 22:59:34 PDT
Created attachment 260838 [details]
proposed fix
Comment 5 Alexey Proskuryakov 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.
Comment 6 WebKit Commit Bot 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>
Comment 7 WebKit Commit Bot 2015-09-09 13:39:46 PDT
All reviewed patches have been landed.  Closing bug.