REGRESSION(r84112): Chromium linux layout tests are broken. (Requested by loislo2 on #webkit).

• Component: New Bugs
• Status: RESOLVED FIXED

[WebKit Review Bot]

http://trac.webkit.org/changeset/84112 broke the build:
Chromium linux layout tests are broken. (Requested by loislo2 on #webkit).

This is an automatic bug report generated by the sheriff-bot. If this bug
report was created because of a flaky test, please file a bug for the flaky
test (if we don't already have one on file) and dup this bug against that bug
so that we can track how often these flaky tests case pain.

"Only you can prevent forest fires." -- Smokey the Bear

[WebKit Review Bot]

Created attachment 90008 [details]
ROLLOUT of r84112

Any committer can land this patch automatically by marking it commit-queue+.  The commit-queue will build and test the patch before landing to ensure that the rollout will be successful.  This process takes approximately 15 minutes.

If you would like to land the rollout faster, you can use the following command:

  webkit-patch land-attachment ATTACHMENT_ID --ignore-builders

where ATTACHMENT_ID is the ID of this attachment.

[Ilya Tikhonovsky]

Comment on attachment 90008 [details]
ROLLOUT of r84112

Clearing flags on attachment: 90008

Committed r84127: <http://trac.webkit.org/changeset/84127>

[Ilya Tikhonovsky]

All reviewed patches have been landed.  Closing bug.

[WebKit Review Bot]

http://trac.webkit.org/changeset/84127 might have broken GTK Linux 64-bit Debug

[Dirk Pranke]

Okay, there's an actual bug here as well. Doing a read on a non-blocking socket may raise EAGAIN / EWOULDBLOCK if there is no data available, and we weren't catching that case. I'm not sure why I didn't see this when I tested this the first time, since it's a pretty pervasive failure.

It's easy to patch this, but I wonder what the performance cost will be of catching errors vs. doing a select first to see if data is available, since raising an error is the common case.