Closed Bug 968044 Opened 7 years ago Closed 7 years ago
xpcshell tests have trailing \x0D on every log output of individual tests
This started happening last week. eg: ... 0:03.81 Retrying tests that failed when run in parallel. 0:04.91 TEST-UNEXPECTED-FAIL | o:/src/mozilla-git/gecko-dev/obj-release/_tests/xpcshell/services/sync/tests/unit/test_service_detect_upgrade.js | test failed (with xpcshell return code: 0), see following log: 0:04.91 >>>>>>> 0:04.91 1391578503323 Sync.EngineManager ERROR Engine 'tabs' is already registered!\x0D 0:04.91 \x0D 0:04.91 TEST-INFO | (xpcshell/head.js) | test MAIN run_test pending (1) 0:04.91 \x0D 0:04.91 TEST-INFO | (xpcshell/head.js) | test run_next_test 0 pending (2) 0:04.91 \x0D 0:04.91 TEST-INFO | (xpcshell/head.js) | test MAIN run_test finished (2) 0:04.91 \x0D 0:04.91 TEST-INFO | (xpcshell/head.js) | running event loop 0:04.91 TEST-INFO | o:/src/mozilla-git/gecko-dev/obj-release/_tests/xpcshell/services/sync/tests/unit/test_service_detect_upgrade.js | Starting v4_upgrade\x0D 0:04.91 \x0D 0:04.91 TEST-INFO | (xpcshell/head.js) | test v4_upgrade pending (2) 0:04.91 Set up some tabs.\x0D 0:04.91 1391578503329 Sync.Status INFO Resetting Status.\x0D 0:04.91 1391578503329 Sync.Status DEBUG Status.service: service.client_not_configured => success.status_ok\x0D 0:04.91 Logging in.\x0D etc
Possible fallout from bug 933885? Specifically: http://hg.mozilla.org/mozilla-central/rev/73733b06cbf7
Possibly also a Windows line ending in a file / string literal somewhere. I don't see this on OS X.
(In reply to Ted Mielczarek [:ted.mielczarek] from comment #1) > Possible fallout from bug 933885? Specifically: > http://hg.mozilla.org/mozilla-central/rev/73733b06cbf7 Almost certainly: 1.32 +# TODO: perhaps this should be in a more generally shared location? 1.33 +# This regex matches all of the C0 and C1 control characters 1.34 +# (U+0000 through U+001F; U+007F; U+0080 through U+009F), 1.35 +# except TAB (U+0009) and LF (U+000A); also, backslash (U+005C). 1.36 +# A raw string is deliberately not used. The lines on Windows are terminated with carriage-return + linefeed, and this block will turn the CR (0xD) chars with the escaped version.
Not escaping CR characters solves this.
Assignee: nobody → mhammond
Status: NEW → ASSIGNED
Attachment #8371098 - Flags: review?(gps)
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
You need to log in before you can comment on or make changes to this bug.