Closed Bug 975550 Opened 11 years ago Closed 11 years ago

TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/xpcshell/tests/chat/protocols/irc/test/test_ctcpDequote.js + /builds/slave/talos-slave/test/build/xpcshell/tests/dom/encoding/test/unit/test_misc.js

Categories

(Thunderbird :: Testing Infrastructure, defect)

Product:
Thunderbird
Component:
Testing Infrastructure
Platform:
x86_64
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(thunderbird30 fixed, thunderbird31 fixed, thunderbird32 fixed)

Status:
RESOLVED FIXED
Milestone:
Thunderbird 32.0
Tracking Flags:
Tracking Status
thunderbird30 --- fixed
thunderbird31 --- fixed
thunderbird32 --- fixed

People

(Reporter: mkmelin, Assigned: standard8)

References

Details

(Keywords: intermittent-failure, regression)

Attachments

(1 file)

The fix
632 bytes, patch
ted
: review+
Details | Diff | Splinter Review
TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/xpcshell/tests/chat/protocols/irc/test/test_ctcpDequote.js | Process still running after test! TEST-UNEXPECTED-FAIL | /builds/slave/talos-slave/test/build/xpcshell/tests/dom/encoding/test/unit/test_misc.js | Process still running after test! Filing these two as one bug as it seems likely to be the same. Perma orange on OSX. https://tbpl.mozilla.org/php/getParsedLog.php?id=34865505&tree=Thunderbird-Trunk
Is this actually thought to be a chat bug of some sort? I thought this was a bustage of some sort? (I.e. why was this filed under Chat Core)? This is the assumption all of the chat developers are under right now and we are NOT currently looking at this.
Well, it's a broken test that is affecting chat only. It's unclear if it's an actual bug in "real" code or in the test. I don't know of a more suitable place it could have been filed.
@clokep: It is likely that a change in mozilla-central has either broken the test, or shown up a previously hidden issue in the test. Unfortunately, due to bug 964379, the regression range covers from Mon Jan 27 - Tue Feb 18 Something like: http://hg.mozilla.org/comm-central/pushloghtml?fromchange=5a029594d5f0&tochange=6589c23c8ea4 http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=611698b4a246&tochange=9019cc90719c This could be regression tested on try, though I appreciate it might take a while. For the mozilla-central changes, you can fix a specific version of m-c by adding 'MOZILLA_REV' as a value in the table at the top of client.py.
(In reply to Magnus Melin from comment #6) > Well, it's a broken test that is affecting chat only. Well, it's also affecting dom/encoding/test/unit/test_misc.js, which is completely unrelated to chat/. > It's unclear if it's > an actual bug in "real" code or in the test. Could this be related to the build machine? All the failures I've seen are on OS X 10.6. I haven't seen a single one on 10.8.
(In reply to Florian Quèze [:florian] [:flo] from comment #8) > > It's unclear if it's > > an actual bug in "real" code or in the test. > > Could this be related to the build machine? All the failures I've seen are > on OS X 10.6. I haven't seen a single one on 10.8. I'm pretty sure those machines haven't been changed in a while, and it would be more likely that something has caused this from the m-c side.
I did a try run with all the chat tests disabled and this causes a gloda test to start failing: https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=cbaa127dce33
Per comment 38, this is definitely not a chat bug.
Component: Instant Messaging → Testing Infrastructure
Looks like this is a regression from bug 933885 - I just tested on try server with that backed out and this passed. I'm guessing there's some sort of characters that aren't liked on 10.6 in this case. This is the failure mode we're seeing: <<<<<<< INFO | Following exceptions were raised: Traceback (most recent call last): File "xpcshell/runxpcshelltests.py", line 166, in run self.run_test() File "xpcshell/runxpcshelltests.py", line 629, in run_test stdout, stderr = self.communicate(proc) File "xpcshell/runxpcshelltests.py", line 228, in communicate self.process_line(line) File "xpcshell/runxpcshelltests.py", line 513, in process_line self.report_message(line_object) File "xpcshell/runxpcshelltests.py", line 482, in report_message message = cleanup_encoding(self.message_from_line(line)) File "xpcshell/runxpcshelltests.py", line 100, in cleanup_encoding s = _cleanup_encoding_re.sub(_cleanup_encoding_repl, s) File "xpcshell/runxpcshelltests.py", line 85, in _cleanup_encoding_repl return '\\\\' if c == '\\' else '\\x{:02X}'.format(ord(c)) ValueError: zero length field name in format Traceback (most recent call last): File "xpcshell/runxpcshelltests.py", line 1617, in <module> main() File "xpcshell/runxpcshelltests.py", line 1613, in main if not xpcsh.runTests(args[0], testdirs=args[1:], **options.__dict__): File "xpcshell/runxpcshelltests.py", line 1498, in runTests raise exceptions[0] ValueError: zero length field name in format
Blocks: 933885
Keywords: regression
(In reply to Mark Banner (:standard8) from comment #168) > Looks like this is a regression from bug 933885 - I just tested on try > server with that backed out and this passed. I'm guessing there's some sort > of characters that aren't liked on 10.6 in this case. ... > File "xpcshell/runxpcshelltests.py", line 85, in _cleanup_encoding_repl > return '\\\\' if c == '\\' else '\\x{:02X}'.format(ord(c)) > ValueError: zero length field name in format If that error message means what I think it does, this is because the older build workers are still on Python 2.6, and it should be fixed by changing that line to + return '\\\\' if c == '\\' else '\\x{0:02X}'.format(ord(c)) I don't have time to try that myself until probably next week.
I've just tried this and it seems to work. I can attach the patch tomorrow. Thanks Zack.
Attached patch The fix — — Splinter Review
This is the patch that Zack suggested. I've tested that it works on the Thunderbird try servers. We are looking to get our final builders switched to python 2.7 (see bug 979550), but I'm not sure of the ETA for that yet, so given this is a small change, lets get it fixed and it can always be backed out later if we really don't want it.
Assignee: nobody → standard8
Status: NEW → ASSIGNED
Attachment #8416387 - Flags: review?(ted)
FWIW, I don't see any reason to back this out after we get rid of 2.6 -- it's just a slightly more verbose way of writing the same thing, and will continue to work reliably with newer Python.
Attachment #8416387 - Flags: review?(ted) → review+
https://hg.mozilla.org/integration/mozilla-inbound/rev/eaefe44c50e2
Target Milestone: --- → Thunderbird 32.0
https://hg.mozilla.org/mozilla-central/rev/eaefe44c50e2
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: