-
-
Notifications
You must be signed in to change notification settings - Fork 31.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
UBSAN: test_ctypes, test_faulthandler and test_hashlib are failing #91069
Comments
I recently changed how tests are skipped in ASAN, MSAN and UBSAN CIs (buildbot workers and GitHub Action jobs): 3 tests are now failing on "AMD64 Arch Linux Usan 3.x":
First failed build: |
test_ctypes: test_shorts() of ctypes.test.test_bitfields.C_Test is failing with: --- It's a test on the "h" format code: #define LOW_BIT(x) ((x) & 0xFFFF)
#define NUM_BITS(x) ((x) >> 16)
#define GET_BITFIELD(v, size) \
if (NUM_BITS(size)) { \
v <<= (sizeof(v)*8 - LOW_BIT(size) - NUM_BITS(size)); \
v >>= (sizeof(v)*8 - NUM_BITS(size)); \
static PyObject *
h_get(void *ptr, Py_ssize_t size)
{
short val;
memcpy(&val, ptr, sizeof(val));
GET_BITFIELD(val, size); // <==== HERE
return PyLong_FromLong((long)val);
}
static struct fielddesc formattable[] = {
...
{ 'h', h_set, h_get, NULL, h_set_sw, h_get_sw},
...
}; |
test_hashlib: test_gil() fails with: |
test_faulthandler: test_sigfpe() fails with: ====================================================================== Traceback (most recent call last):
File "/home/vstinner/python/main/Lib/test/test_faulthandler.py", line 228, in test_sigfpe
self.check_fatal_error("""
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/vstinner/python/main/Lib/test/test_faulthandler.py", line 129, in check_fatal_error
self.check_error(code, line_number, fatal_error, **kw)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/vstinner/python/main/Lib/test/test_faulthandler.py", line 122, in check_error
self.assertRegex(output, regex)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Regex didn't match: '(?m)^Fatal Python error: Floating point exception\n\nCurrent thread 0x[0-9a-f]+ \\(most recent call first\\):\n File "<string>", line 3 in <module>' not found in 'Modules/faulthandler.c:1112:11: runtime error: division by zero\nSUMMARY: UndefinedBehaviorSanitizer: undefined-behavior Modules/faulthandler.c:1112:11 in ' |
Reproducer of test_ctypes undefined behavior: from ctypes import *
class BITS(Structure):
_fields_ = [("A", c_int, 1),
("B", c_int, 2),
("C", c_int, 3),
("D", c_int, 4),
("E", c_int, 5),
("F", c_int, 6),
("G", c_int, 7),
("H", c_int, 8),
("I", c_int, 9),
b = BITS()
a = getattr(b, "M")
I expanded the macro: if (NUM_BITS(size)) {
size_t s = sizeof(val)*8;
Py_ssize_t low = LOW_BIT(size);
Py_ssize_t nbits = NUM_BITS(size);
// val=0, size=65553 = (1 << 16) + 17
// s=16, low=17, nbits=1
// s - low - nbits = (size_t)-2
val <<= (s - low - nbits);
val >>= (s - nbits);
} The problem is that (s - low - nbits) is negative (-2), but becomes a very large number since it's unsigned (s is unsigned: "sizeof(v)*8" in the macro). C code: #include <stdio.h>
int main()
{
short s = 0x7fff;
size_t z = (size_t)-2;
s <<= z;
printf("s = %hi\n", s);
return 0;
} GCC and clang disagree :-D $ gcc x.c -o x -O3 -Wall -Wextra -Wconversion && ./x
s = 0
$ clang x.c -o x -O3 -Wall -Wextra -Wconversion && ./x
s = -5784 Moreover, runtime the binary built by clang produces a different result at each run... $ ./x
s = -4824
$ ./x
s = 4120
$ ./x
s = -22344
$ ./x
s = -26744
$ ./x
s = -18184 |
Previously, 4 tests were skipped on the UBSAN buildbot
It's not a regression, it's just that I made the buildbot stricter. I'm planning to attempt to fix the 3 failing tests, or at least skip them in Python, rather than skipping them in the buildbot configuration. |
See also bpo-46887: ./Programs/_freeze_module fails with MSAN: Uninitialized value was created by an allocation of 'stat.i'. |
I pushed changes just to turn back the buildbot back to green, but undefined behaviors in test_ctypes.test_shorts() and _sha3 (tested by test_hashlib) must be fixed. Previously, test_ctypes, test_hashlib and test_faulthandler were fully skipped on UBSan. Now only 1 test_ctypes test and a few test_hashlib tests are skipped on the UBSan buildbot (test_faulthandler now pass on UBSan). |
I don't agree with #75854. Did you try defining NO_MISALIGNED_ACCESSES instead? |
Did you read the commit message? The change is not about skipping the test, but fixing the CI. Previously, test_hashlib was not run at all on the UBSan buildbot, now most test_hashlib tests are run. The intent is to make sure that we don't add *new* undefined behavior. As I wrote in the commit, the UD must be fixed in _sha3. No, I didn't try NO_MISALIGNED_ACCESSES, I don't know this macro. If you have an idea on how _sha3 can be fixed on the UBSan buildbot, please go head! |
Current status of tests skipped on ASAN, MSAN and UBSAN. Only ASAN (1):
ASAN and MSAN (10):
Only UB (1):
|
I enabled the test on ASAN on test_crypt and I confirm that I get a crash on calling a NULL function. The Python crypt.crypt() function calls the C function crypt_r() which is intercepted by libasan, but the libasan implementation calls a NULL function. I don't know why. $ ./configure --with-address-sanitizer --with-pydebug
$ make clean
$ ASAN_OPTIONS="detect_leaks=0:allocator_may_return_null=1:handle_segv=0" make
$ ASAN_OPTIONS="detect_leaks=0:allocator_may_return_null=1:handle_segv=0" gdb -args ./python -m test -v test_crypt
(gdb) run
(...)
0:00:00 load avg: 0.53 Run tests sequentially
0:00:00 load avg: 0.53 [1/1] test_crypt Program received signal SIGSEGV, Segmentation fault. (gdb) where $ ASAN_OPTIONS="detect_leaks=0:allocator_may_return_null=1:handle_segv=0" ./python -m test -v test_crypt
(...)
0:00:00 load avg: 0.56 Run tests sequentially
0:00:00 load avg: 0.56 [1/1] test_crypt
Fatal Python error: Segmentation fault Current thread 0x00007f367c6c77c0 (most recent call first): |
The crypt_r() interceptor issue was reported in January 2021 to libasan:
Note: I built Python with GCC ASAN (-fsanitize=address). |
Well, IMO I enhanced the situation enough. I close the issue :-) Open new issues if you want to fix a specific test on UBSan buildbots ;-) |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: