fast/forms/form-associated-element-crash3.html is a test that's known to hang after it dumps results (see bug 122130). Having a test like this confuses WebKitTestRunner a lot. 1. There is output saying that last line of output was not a newline, and there is a bug. 2. The next test is incorrectly reported as crashing. $ run-webkit-tests -2 --no-retry-failures -v fast/forms --child-processes=1 ... [150/810] fast/forms/form-associated-element-crash3.html passed Last character read from DRT stdout line was not a newline! This indicates either a NRWT or DRT bug. [151/810] fast/forms/form-associated-element-removal.html failed (WebProcess crashed [pid=44775])
This is probably essentially the same as bug 118602. It's not clear that there's a good way to fix this given the current way the test harness communicates w/ WTR.
Created attachment 232579 [details] freeze (dont open!) Updated steps to reproduce: 1. Download attached freeze.html into LayoutTests. 2. run-webkit-tests -2 freeze.html fast/encoding/ahram-org-eg.html --debug-rwt-logging --child-processes=1
<rdar://problem/17184354>
Created attachment 235034 [details] proposed fix
Comment on attachment 235034 [details] proposed fix View in context: https://bugs.webkit.org/attachment.cgi?id=235034&action=review > Tools/WebKitTestRunner/TestInvocation.cpp:206 > + // The process froze while loading about:blank, let's start a fresh one. > + // It would be nice to report that the previous test froze after dumping results, but we have no way to do that. Can we log here?
No, the script doesn't expect any output before the next test begins.
Comment on attachment 235034 [details] proposed fix Clearing flags on attachment: 235034 Committed r171167: <http://trac.webkit.org/changeset/171167>
All reviewed patches have been landed. Closing bug.