With a gdb build with -fsanitize=thread, and test-case
gdb.python/py-inferior.exp I run into:
...
(gdb) python gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)^M
ERROR: ThreadSanitizer: requested allocation size 0xffffffffffffffff exceeds \
maximum supported size of 0x10000000000^M
...
There's already a workaround for this using ASAN_OPTIONS, and apparently the
same is needed for TSAN_OPTIONS.
Add the allocator_may_return_null=1 workaround also in TSAN_OPTIONS.
Likewise in gdb.dap/memory.exp.
Tested on x86_64-linux.
return
}
-save_vars { env(ASAN_OPTIONS) } {
+save_vars { env(ASAN_OPTIONS) env(TSAN_OPTIONS) } {
# The request readMemory with count 18446744073709551615 triggers address
# sanitizer. Suppress the error, leaving us with just this warning:
# WARNING: AddressSanitizer failed to allocate 0xffffffffffffffff bytes
set_sanitizer ASAN_OPTIONS allocator_may_return_null 1
+ set_sanitizer TSAN_OPTIONS allocator_may_return_null 1
if {[dap_initialize] == ""} {
return
}
# Start with a fresh gdb.
-save_vars { env(ASAN_OPTIONS) } {
+save_vars { env(ASAN_OPTIONS) env(TSAN_OPTIONS) } {
# The call to gdb.selected_inferior().read_memory (0, 0xffffffffffffffff)
# triggers address sanitizer. Suppress the error, leaving us with just
# this warning:
# WARNING: AddressSanitizer failed to allocate 0xffffffffffffffff bytes
set_sanitizer ASAN_OPTIONS allocator_may_return_null 1
+ set_sanitizer TSAN_OPTIONS allocator_may_return_null 1
clean_restart ${testfile}
}