RESOLVED FIXED 58770
REGRESSION(r84112): Chromium linux layout tests are broken. (Requested by loislo2 on #webkit).
https://bugs.webkit.org/show_bug.cgi?id=58770
Summary REGRESSION(r84112): Chromium linux layout tests are broken. (Requested by loi...
WebKit Review Bot
Reported 2011-04-18 02:41:59 PDT
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
Attachments
ROLLOUT of r84112 (3.09 KB, patch)
2011-04-18 02:42 PDT, WebKit Review Bot
no flags
WebKit Review Bot
Comment 1 2011-04-18 02:42:21 PDT
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 2 2011-04-18 02:45:41 PDT
Comment on attachment 90008 [details] ROLLOUT of r84112 Clearing flags on attachment: 90008 Committed r84127: <http://trac.webkit.org/changeset/84127>
Ilya Tikhonovsky
Comment 3 2011-04-18 02:45:50 PDT
All reviewed patches have been landed. Closing bug.
WebKit Review Bot
Comment 4 2011-04-18 04:45:35 PDT
http://trac.webkit.org/changeset/84127 might have broken GTK Linux 64-bit Debug
Dirk Pranke
Comment 5 2011-04-18 12:03:18 PDT
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.
Note You need to log in before you can comment on or make changes to this bug.