Bug 82673

Summary: new-run-webkit-tests: crashes when it fails to decode a stack trace
Product: WebKit Reporter: Dirk Pranke <dpranke>
Component: New BugsAssignee: Dirk Pranke <dpranke>
Status: RESOLVED FIXED    
Severity: Normal CC: abarth, eric, mrobinson, ojan, pnormand, tony, webkit.review.bot
Priority: P2    
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch none

Dirk Pranke
Reported 2012-03-29 15:50:15 PDT
new-run-webkit-tests: crashes when it fails to decode a stack trace
Attachments
Patch (3.13 KB, patch)
2012-03-29 15:51 PDT, Dirk Pranke
no flags
Dirk Pranke
Comment 1 2012-03-29 15:51:34 PDT
Dirk Pranke
Comment 2 2012-03-29 15:52:33 PDT
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
Comment 3 2012-03-29 15:53:51 PDT
Eric Seidel (no email)
Comment 4 2012-03-29 15:55:08 PDT
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)
Comment 5 2012-03-29 15:55:57 PDT
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
Comment 6 2012-03-29 16:00:22 PDT
(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.
Note You need to log in before you can comment on or make changes to this bug.