WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED FIXED
82673
new-run-webkit-tests: crashes when it fails to decode a stack trace
https://bugs.webkit.org/show_bug.cgi?id=82673
Summary
new-run-webkit-tests: crashes when it fails to decode a stack trace
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
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Dirk Pranke
Comment 1
2012-03-29 15:51:34 PDT
Created
attachment 134685
[details]
Patch
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
Committed
r112594
: <
http://trac.webkit.org/changeset/112594
>
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.
Top of Page
Format For Printing
XML
Clone This Bug