Bug 82673 – new-run-webkit-tests: crashes when it fails to decode a stack trace

• Status: RESOLVED
• Resolution: FIXED
• Component: New Bugs

[Dirk Pranke]

new-run-webkit-tests: crashes when it fails to decode a stack trace

[Dirk Pranke]

Created attachment 134685 [details]
Patch

[Dirk Pranke]

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.

[Dirk Pranke]

Committed r112594: <http://trac.webkit.org/changeset/112594>

[Eric Seidel (no email)]

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.

[Eric Seidel (no email)]

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.

[Dirk Pranke]

(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.