Searched hist:"2 ab5d5e67f7ab2d2ecf67b8855ac65691f4e4b4d" (Results 1 – 2 of 2) sorted by relevance
/linux/tools/testing/kunit/ |
H A D | kunit_kernel.py | diff 2ab5d5e67f7ab2d2ecf67b8855ac65691f4e4b4d Thu Oct 21 01:21:21 CEST 2021 Daniel Latypov <dlatypov@google.com> kunit: tool: continue past invalid utf-8 output
kunit.py currently crashes and fails to parse kernel output if it's not fully valid utf-8.
This can come from memory corruption or just inadvertently printing out binary data as strings.
E.g. adding this line into a kunit test pr_info("\x80") will cause this exception UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 1961: invalid start byte
We can tell Python how to handle errors, see https://docs.python.org/3/library/codecs.html#error-handlers
Unfortunately, it doesn't seem like there's a way to specify this in just one location, so we need to repeat ourselves quite a bit.
Specify `errors='backslashreplace'` so we instead: * print out the offending byte as '\x80' * try and continue parsing the output. * as long as the TAP lines themselves are valid, we're fine.
Fixed spelling/grammar in commit log: Shuah Khan <<skhan@linuxfoundation.org>
Signed-off-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Tested-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
|
H A D | kunit.py | diff 2ab5d5e67f7ab2d2ecf67b8855ac65691f4e4b4d Thu Oct 21 01:21:21 CEST 2021 Daniel Latypov <dlatypov@google.com> kunit: tool: continue past invalid utf-8 output
kunit.py currently crashes and fails to parse kernel output if it's not fully valid utf-8.
This can come from memory corruption or just inadvertently printing out binary data as strings.
E.g. adding this line into a kunit test pr_info("\x80") will cause this exception UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 1961: invalid start byte
We can tell Python how to handle errors, see https://docs.python.org/3/library/codecs.html#error-handlers
Unfortunately, it doesn't seem like there's a way to specify this in just one location, so we need to repeat ourselves quite a bit.
Specify `errors='backslashreplace'` so we instead: * print out the offending byte as '\x80' * try and continue parsing the output. * as long as the TAP lines themselves are valid, we're fine.
Fixed spelling/grammar in commit log: Shuah Khan <<skhan@linuxfoundation.org>
Signed-off-by: Daniel Latypov <dlatypov@google.com> Reviewed-by: Brendan Higgins <brendanhiggins@google.com> Tested-by: David Gow <davidgow@google.com> Signed-off-by: Shuah Khan <skhan@linuxfoundation.org>
|