WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED WORKSFORME
95879
NRWT sometimes (maybe?) looks for crash logs for the wrong process
https://bugs.webkit.org/show_bug.cgi?id=95879
Summary
NRWT sometimes (maybe?) looks for crash logs for the wrong process
Tim Horton
Reported
2012-09-05 11:35:56 PDT
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.
Attachments
Add attachment
proposed patch, testcase, etc.
Dirk Pranke
Comment 1
2012-09-05 11:44:11 PDT
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.
Tim Horton
Comment 2
2012-09-05 14:13:33 PDT
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?
Alexey Proskuryakov
Comment 3
2015-10-15 17:19:38 PDT
I think that this has been fixed since.
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug