Some output from after my logging improvement yesterday (http://trac.webkit.org/changeset/127547): From http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20(Tests)/r127606%20(613)/dom/xhtml/level3/core/nodelookupnamespaceuri09-crash-log.txt > No crash log found for WebKitTestRunner:63827. > > stdout: > > stderr: > #CRASHED - WebProcess (pid 63828) From http://build.webkit.org/results/Apple%20MountainLion%20Release%20WK2%20(Tests)/r127608%20(614)/fast/scrolling/scrollable-area-overflow-auto-display-none-crash-log.txt > No crash log found for WebKitTestRunner:68370. > > stdout: > Content-Type: text/plain > PASS true is true > > #EOF > #EOF > > stderr: > #EOF > #CRASHED - WebProcess (pid 68371) Why is NRWT looking for WKTR crash logs instead of WebProcess crash logs, when WKTR clearly told NRWT that it was the WebProcess that crashed? Or, is there more information that I'm missing here, like that WKTR also crashed *after* printing out the crash message from WebProcess? Is that possible? Something odd is going on, anyway.
Good question. Maybe there's something wrong with the regexps we're using to figure out which process to look for in driver.py _check_for_driver_crash()? You could also confirm that the right list of process names and pids is making it back to the manager process so we look for the right things at the end of the run in _look_for_new_crash_logs() in manager.py.
I don't think the regexes in are wrong (in _check_for_driver_crash), but which-process-crashed is swapped out in driver.has_crashed() (swapped out to be the server process if it thinks the server process has crashed). So, maybe the server process (I assume this means WKTR itself) *also* crashed? And didn't leave any crash logs behind? Or maybe we're misidentifying something else as a WKTR crash?
I think that this has been fixed since.