new-run-webkit-tests: crashes when it fails to decode a stack trace
Created attachment 134685 [details] Patch
landing w/o review because this is causing build crashes, but I'm still not 100% sure this is the best thing to do, or if we should even be assuming DRT/WTR emit utf-8 by default.
Committed r112594: <http://trac.webkit.org/changeset/112594>
Comment on attachment 134685 [details] Patch The output from the driver is not UTF8. The diffs can contain all sorts of non-utf8 characters, effectively binary. We shouldn't be decoding the output at all, assuming I'm remembering correctly.
By "diffs" I meant, the output from the tests. It's common for a test to have non-utf8 characters rendered in it. At least that's my recollection. I'm surprised that we were interpreting the output from the drivers as utf8 in teh first place.
(In reply to comment #5) > By "diffs" I meant, the output from the tests. It's common for a test to have non-utf8 characters rendered in it. At least that's my recollection. I'm surprised that we were interpreting the output from the drivers as utf8 in teh first place. You're correct, generally speaking. The case in question is what happens when we get a stack trace, though. pnormand thought we were getting utf-8, but that might be gtk-specific. It might be that we should decode utf-8 for stderr, but not decode stdout at all, or it might be that we should just do something port-specific. This patch is strictly better than what was there before (since we were trying to decode and crashing), but we should continue to look at the crash logs and perhaps change the implementation if there are issues.