Summary: | [Win] webkitpy test suite frequently fails to complete | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | WebKit | Reporter: | Brent Fulgham <bfulgham> | ||||||
Component: | Tools / Tests | Assignee: | Brent Fulgham <bfulgham> | ||||||
Status: | RESOLVED FIXED | ||||||||
Severity: | Normal | CC: | bfulgham, commit-queue, dbates, glenn | ||||||
Priority: | P2 | ||||||||
Version: | 528+ (Nightly build) | ||||||||
Hardware: | All | ||||||||
OS: | All | ||||||||
Attachments: |
|
Description
Brent Fulgham
2014-09-04 14:35:21 PDT
The first problem is due to a non-number value being stored in the PID file. This patch adds logging to identify what this content includes so that we can fix any underlying issue. The second problem appears to be a nuance in the Windows port of Python when the 'codec.open' call is made using the encoding string "utf8" rather than "utf-8". Other ports do not seem to suffer from this problem; perhaps they default to utf-8 when the codec is an unexpected string. This patch adds error handling for the case of non-numeric (or mixed numeric) pids, and switches the encoding string type from "utf8" to "utf-8", which matches other uses of the codec function in our code base. Created attachment 237648 [details]
Patch
Comment on attachment 237648 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=237648&action=review > Tools/ChangeLog:9 > + (FileSystem.open_text_file_for_reading): Switch from "utf8" to "utf-8" Is this necessary? Do you feel it improves the readability of the code? From my understanding of <https://docs.python.org/2/library/codecs.html#standard-encodings> "utf8" is an alias for "utf-8". (In reply to comment #3) > (From update of attachment 237648 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=237648&action=review > > > Tools/ChangeLog:9 > > + (FileSystem.open_text_file_for_reading): Switch from "utf8" to "utf-8" > > Is this necessary? Do you feel it improves the readability of the code? From my understanding of <https://docs.python.org/2/library/codecs.html#standard-encodings> "utf8" is an alias for "utf-8". You are right; that wasn't the problem. The issue is that we are in some cases (e.g., the crash log) getting the contents of the file as a byte string, and passing that value to this function, which assumes it will be given a unicode value that can encode itself as utf-8. Since we pass a byte string, the moment the codecs class asks it to convert itself to a utf-8 encoding, it (being an ASCII-only byte representation) refuses and throws an exception. I need to find where this log file is getting read, and make sure it is converted to unicode as early as possible so that this doesn't happen. Created attachment 237658 [details]
Patch
Comment on attachment 237658 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=237658&action=review > Tools/ChangeLog:12 > + We were mixing ascii/unicode strings under Windows, which was Nit: ascii => ASCII unicode => Unicode > Tools/Scripts/webkitpy/common/system/crashlogs.py:92 > + log_file = self._host.filesystem.read_binary_file(path).decode('ascii', 'ignore') I assume it's always acceptable to decode the file as ASCII regardless of the platform. Comment on attachment 237658 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=237658&action=review >> Tools/Scripts/webkitpy/common/system/crashlogs.py:92 >> + log_file = self._host.filesystem.read_binary_file(path).decode('ascii', 'ignore') > > I assume it's always acceptable to decode the file as ASCII regardless of the platform. Disregard this comment. This function is specific to Windows. Committed r173290: <http://trac.webkit.org/changeset/173290> |