Filed by: hskupin [at] mozilla.com https://treeherder.mozilla.org/logviewer.html#?job_id=174283915&repo=try https://queue.taskcluster.net/v1/task/BNnpzJyITieBLM3iajZ5GA/runs/0/artifacts/public/logs/live_backing.log This is happening when the profile has a Unicode character included: https://treeherder.mozilla.org/#/jobs?repo=try&revision=85ef901be939607846a699ea60e59bb663679e6d&selectedJob=174283915

It fails all in Popen and looks to be a recent regression because it was working some days ago: > 10:15:48 INFO - self = <subprocess.Popen object at 0x00000000043B4D30> > 10:15:48 INFO - args = 'z:/build/build/src/obj-firefox\\dist\\bin\\firefox.exe --headless -profile c:\\users\\task_1524041731\\appdata\\local\\temp\\tmp1ertyb.mozrunner\U0001f36a' [..] > 10:15:48 INFO - E UnicodeEncodeError: 'ascii' codec can't encode characters in position 135-136: ordinal not in range(128) > 10:15:48 INFO - c:\mozilla-build\python\Lib\subprocess.py:640: UnicodeEncodeError Andrew, might your large refactoring on bug 1445944 have caused this?

It's certainly possible, though I don't understand why it would make a difference as far as unicode is concerned. So to clarify it consistently fails when there's unicode in the profile name, but somehow we intermittently have unicode profiles? How does that happen? Or is the "Intermittent" part of this bug just added by the bug filer, and the unicode paths haven't landed yet?

Right, as long as the patch on bug 918097 cannot land, there will not be a Unicode character present, and the failure is not visible on Treeherder. And I just filed it with the intermittent bug filer based on my try push.

Please note that those failures only happen on Windows in that try build. This is most likely due to bug 1065583.

So, it's not intermittent. 100% of the time, if a non-ascii character is in the profile name, we fail. We don't intermittently have one in the profile name, and even if we did randomly include either 0 or 1 non-ascii character in the profile name, it still wouldn't be intermittent.