Thread Sanitizer FATAL error on kernel version 6.6.6-x #1716

rohumm · 2023-12-30T19:36:07Z

C++ source file:

int main() {}

Build commands tried:
clang-16 -std=c++17 -fsanitize=thread -g -O0 main.cpp -o run.me
clang-18 -std=c++23 -fsanitize=thread -g -O0 main.cpp -o run.me
g++-9 -std=c++17 -fsanitize=thread -g -O0 main.cpp -o run.me
g++-11 -std=c++23 -fsanitize=thread -g -O0 main.cpp -o run.me
g++-13 -std=c++23 -fsanitize=thread -g -O0 main.cpp -o run.me

Error:

$ ./run.me 
FATAL: ThreadSanitizer: unexpected memory mapping 0x70a076c72000-0x70a077100000
$ TSAN_OPTIONS="verbosity=3" ./run.me 
FATAL: ThreadSanitizer: unexpected memory mapping 0x63068b744000-0x63068b773000

System info:

$ uname -a
Linux pop-os 6.6.6-76060606-generic #202312111032~1702306143~22.04~d28ffec SMP PREEMPT_DYNAMIC Mon D x86_64 x86_64 x86_64 GNU/Linux

Misc.:

$ clang-16 --version
Ubuntu clang version 16.0.6 (++20231112100510+7cbf1a259152-1~exp1~20231112100554.106)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ clang-18 --version
Ubuntu clang version 18.0.0 (++20231230042237+ca8441d6dbd3-1~exp1~20231230042349.1401)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin

$ g++-9 --version
g++-9 (Ubuntu 9.5.0-1ubuntu1~22.04) 9.5.0

$ g++-11 --version
g++-11 (Ubuntu 11.4.0-1ubuntu1~22.04) 11.4.0

$ g++-13 --version
g++-13 (Ubuntu 13.1.0-8ubuntu1~22.04) 13.1.0

$ ldd ./run.me 
	linux-vdso.so.1 (0x00007fff98feb000)
	libtsan.so.2 => /lib/x86_64-linux-gnu/libtsan.so.2 (0x00007b878dc00000)
	libstdc++.so.6 => /lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007b878d800000)
	libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007b878db19000)
	libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007b878ece0000)
	libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007b878d400000)
	/lib64/ld-linux-x86-64.so.2 (0x00007b878ed2c000)

$ readlink /lib/x86_64-linux-gnu/libtsan.so.2
libtsan.so.2.0.0

The text was updated successfully, but these errors were encountered:

rohumm · 2024-01-03T20:29:09Z

More information:

$ ./run.me & cat /proc/$!/maps

6004e9242000-6004e9243000 r--p 00000000 fc:01 4099534                    /home/USER/workspace/sanitizer_test/cmake-build-debug/run.me
6004e9243000-6004e9244000 r-xp 00001000 fc:01 4099534                    /home/USER/workspace/sanitizer_test/cmake-build-debug/run.me
6004e9244000-6004e9245000 r--p 00002000 fc:01 4099534                    /home/USER/workspace/sanitizer_test/cmake-build-debug/run.me
6004e9245000-6004e9247000 rw-p 00002000 fc:01 4099534                    /home/USER/workspace/sanitizer_test/cmake-build-debug/run.me
75b06ee00000-75b06ee9c000 r--p 00000000 fc:01 34999046                   /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32
75b06ee9c000-75b06efcd000 r-xp 0009c000 fc:01 34999046                   /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32
75b06efcd000-75b06f05a000 r--p 001cd000 fc:01 34999046                   /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32
75b06f05a000-75b06f05b000 ---p 0025a000 fc:01 34999046                   /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32
75b06f05b000-75b06f069000 rw-p 0025a000 fc:01 34999046                   /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.32
75b06f069000-75b06f06d000 rw-p 00000000 00:00 0 
75b06f119000-75b06f127000 r--p 00000000 fc:01 34998039                   /usr/lib/x86_64-linux-gnu/libm.so.6
75b06f127000-75b06f1a3000 r-xp 0000e000 fc:01 34998039                   /usr/lib/x86_64-linux-gnu/libm.so.6
75b06f1a3000-75b06f1fe000 r--p 0008a000 fc:01 34998039                   /usr/lib/x86_64-linux-gnu/libm.so.6
75b06f1fe000-75b06f200000 rw-p 000e4000 fc:01 34998039                   /usr/lib/x86_64-linux-gnu/libm.so.6
75b06f200000-75b06f228000 r--p 00000000 fc:01 34999014                   /usr/lib/x86_64-linux-gnu/libtsan.so.2.0.0
75b06f228000-75b06f2e6000 r-xp 00028000 fc:01 34999014                   /usr/lib/x86_64-linux-gnu/libtsan.so.2.0.0
75b06f2e6000-75b06f31c000 r--p 000e6000 fc:01 34999014                   /usr/lib/x86_64-linux-gnu/libtsan.so.2.0.0
75b06f31c000-75b06f31d000 ---p 0011c000 fc:01 34999014                   /usr/lib/x86_64-linux-gnu/libtsan.so.2.0.0
75b06f31d000-75b06f328000 rw-p 0011c000 fc:01 34999014                   /usr/lib/x86_64-linux-gnu/libtsan.so.2.0.0
75b06f328000-75b070274000 rw-p 00000000 00:00 0 
75b0702b2000-75b0702d9000 r--p 00000000 fc:01 60032318                   /etc/ld.so.cache
75b0702d9000-75b0702db000 rw-p 00000000 00:00 0 
75b0702db000-75b0702dd000 r--p 00000000 fc:01 34997065                   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
75b0702dd000-75b070307000 r-xp 00002000 fc:01 34997065                   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
75b070307000-75b070312000 r--p 0002c000 fc:01 34997065                   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
75b070313000-75b070317000 rw-p 00037000 fc:01 34997065                   /usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
7fff9b1be000-7fff9b1df000 rw-p 00000000 00:00 0                          [stack]
7fff9b1e7000-7fff9b1eb000 r--p 00000000 00:00 0                          [vvar]
7fff9b1eb000-7fff9b1ed000 r-xp 00000000 00:00 0                          [vdso]
ffffffffff600000-ffffffffff601000 --xp 00000000 00:00 0                  [vsyscall]

FATAL: ThreadSanitizer: unexpected memory mapping 0x6004e9242000-0x6004e9243000

rohumm · 2024-01-05T19:51:03Z

And more info; disabling virtual memory address randomization fixes the issue:

$ TSAN_OPTIONS="verbosity=3" setarch `uname -m` -R ./run.me 
==142298==Installed the sigaction for signal 11
==142298==Installed the sigaction for signal 7
==142298==Installed the sigaction for signal 8
==142298==Using libbacktrace symbolizer.
***** Running under ThreadSanitizer v3 (pid 142298) *****
ThreadSanitizer: growing sync allocator: 0 out of 1048576*1024
ThreadSanitizer: growing heap block allocator: 0 out of 262144*4096
==142298==__tls_get_addr: DTLS_Find 0x7ffff7e84ec8 2
==142298==__tls_get_addr: DTLS_NextBlock 0x7ffff7e84ec8 0
==142298==__tls_get_addr: 0x7ffff6c64fa0 {0x2,0x0} => 0x7ffff7e84ee0; tls_beg: 0x7ffff7e84ee0; sp: 0x7fffffffd9c0 num_live_dtls 1
==142298==__tls_get_addr: static tls: 0x7ffff7e84ee0
==142298==__tls_get_addr: DTLS_Find 0x7ffff7e84ec8 2
Stats: SizeClassAllocator64: 0M mapped (0M rss) in 513 allocations; remains 513
  02 (    32): mapped:     64K allocs:     128 frees:       0 inuse:    128 num_freed_chunks    1920 avail:   2048 rss:      4K releases:      0 last released:      0K region: 0x7b0800000000
  04 (    64): mapped:     64K allocs:     128 frees:       0 inuse:    128 num_freed_chunks     896 avail:   1024 rss:      4K releases:      0 last released:      0K region: 0x7b1000000000
  05 (    80): mapped:     64K allocs:     128 frees:       0 inuse:    128 num_freed_chunks     691 avail:    819 rss:      4K releases:      0 last released:      0K region: 0x7b1400000000
  06 (    96): mapped:     64K allocs:     128 frees:       0 inuse:    128 num_freed_chunks     554 avail:    682 rss:      4K releases:      0 last released:      0K region: 0x7b1800000000
  49 ( 81920): mapped:    128K allocs:       1 frees:       0 inuse:      1 num_freed_chunks       0 avail:      1 rss:      4K releases:      0 last released:      0K region: 0x7bc400000000
Stats: LargeMmapAllocator: allocated 0 times, remains 0 (0 K) max 0 M; by size logs:

rohumm · 2024-01-05T19:59:14Z

This may or may not be considered a TSAN "bug" per se; regardless, it may be worth considering modifying the error message to give a hint to the user about a possible workaround.

Instead of:

FATAL: ThreadSanitizer: unexpected memory mapping 0x6004e9242000-0x6004e9243000

Print out something like:

FATAL: ThreadSanitizer: unexpected memory mapping 0x6004e9242000-0x6004e9243000; as a potential workaround, you might consider disabling virtual memory address randomization and retrying.

That's a trivial change I can make myself, and open a pull request. Before I do that, I would like to ask TSAN maintainer(s) whether or not they agree with modifying the error message.

dvyukov · 2024-01-06T09:48:12Z

May be related to https://bugs.chromium.org/p/chromium/issues/detail?id=1496730
We discussed doing re-exec with disabled aslr: https://bugs.chromium.org/p/chromium/issues/detail?id=1496730#c28
cc @thurstond

thurstond · 2024-01-11T00:27:07Z

@dvyukov

May be related to https://bugs.chromium.org/p/chromium/issues/detail?id=1496730 We discussed doing re-exec with disabled aslr: https://bugs.chromium.org/p/chromium/issues/detail?id=1496730#c28 cc @thurstond

Many people might not be able to view that bug.

In any case, I prototyped the re-exec approaches (disabling ASLR or re-exec'ing until the layout is compatible) and it will need some more work. The problem is that, with high-entropy ASLR, it occasionally segfaults before it can reach the "FATAL: ThreadSanitizer: unexpected memory mapping" error. Essentially, the checks in CheckAndProtect() are happening too late.

@rohumm
A corollary is that changing the "FATAL: ThreadSanitizer: unexpected memory mapping" error message is an incomplete solution, because it sometimes it will segfault instead of printing that.

Btw, in many cases, lowering the ASLR entropy (sudo sysctl vm.mmap_rnd_bits=30) would be preferable to disabling ASLR entirely.

thurstond · 2024-01-11T01:21:26Z

it occasionally segfaults before it can reach the "FATAL: ThreadSanitizer: unexpected memory mapping" error. Essentially, the checks in CheckAndProtect() are happening too late.

Specifically, the allocator is initialized before CheckAndProtect happens. This means if the randomized layout conflicts with the allocator's intended location, it will segfault.

I'll upload a patch (to avoid the segfault and enable re-exec) for review in a day or two.

TSan's shadow mappings only support 30-bits of ASLR entropy on x86, and it is not practical to support the maximum of 32-bits (due to pointer compression and the overhead of shadow mappings). Instead, this patch changes TSan to re-exec without ASLR if it encounters an incompatible memory layout, as suggested by Dmitry in google/sanitizers#1716. If ASLR is already disabled, it will abort. This patch involves a bit of refactoring, because the old code is: InitializePlatformEarly() InitializeAllocator() InitializePlatform(): CheckAndProtect() but it may already segfault during InitializeAllocator() if the memory layout is incompatible, before we get a chance to check in CheckAndProtect. This patch adds CheckAndProtect during InitializePlatformEarly(), before the allocator is initialized. Naturally, it is necessary to ensure that CheckAndProtect does *not* allow the heap regions to be occupied there, hence we generalize CheckAndProtect to optionally check the heap regions. We keep the original behavior of CheckAndProtect() in InitializePlatform() as a last line of defense. We need to careful not to prematurely abort if ASLR is disabled but TSan was going to re-exec for other reasons (e.g., unlimited stack size); we implement this by moving all the re-exec logic into ReExecIfNeeded().

…78351) TSan's shadow mappings only support 30-bits of ASLR entropy on x86 Linux, and it is not practical to support the maximum of 32-bits (due to pointer compression and the overhead of shadow mappings). Instead, this patch changes TSan to re-exec without ASLR if it encounters an incompatible memory layout, as suggested by Dmitry in google/sanitizers#1716. If ASLR is already disabled but the memory layout is still incompatible, it will abort. This patch involves a bit of refactoring, because the old code is: 1. InitializePlatformEarly() 2. InitializeAllocator() 3. InitializePlatform(): CheckAndProtect() but it may already segfault during InitializeAllocator() if the memory layout is incompatible, before we get a chance to check in CheckAndProtect(). This patch adds CheckAndProtect() during InitializePlatformEarly(), before the allocator is initialized. Naturally, it is necessary to ensure that CheckAndProtect() does *not* allow the heap regions to be occupied here, hence we generalize CheckAndProtect() to optionally check the heap regions. We keep the original behavior of CheckAndProtect() in InitializePlatform() as a last line of defense. We need to be careful not to prematurely abort if ASLR is disabled but TSan was going to re-exec for other reasons (e.g., unlimited stack size); we implement this by moving all the re-exec logic into ReExecIfNeeded().

PhilippMDoerner · 2024-01-20T10:33:42Z

I can confirm similar issues on a 6.7 Kernel (Arch Linux).

clang version:

~/dev/playground % clang -v
clang version 16.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
~/dev/playground % uname -a
Linux framefrog 6.7.0-arch3-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14 +0000 x86_64 GNU/Linux
~/dev/playground %

I can not claim to have a very high understanding here since I only recently started using tsan and diving into low-level and thus can barely use tsan to debug data-races.

Because of that, if the solution turns out to change the error message, could said new error message include a link to some resource on the topic or more concrete suggestions for flags to use or the like? To make finding a work-around for the problem a smidge easier if you're entirely new on the topic.

Mentioning e.g. earlier mentioned sudo sysctl vm.mmap_rnd_bits=30 or other directly actionable information would be really nice for this.

(On that note though, running sudo sysctl vm.mmap_rnd_bits=30 and re-compiling + executing a helloworld example in C did not remove the issue at hand)

russelltg · 2024-01-21T21:34:26Z

A workaround that I've been using (note that this does decrease the security of your system, do not use on production systems) is to disable ASLR entirely:

echo 0 | sudo tee /proc/sys/kernel/randomize_va_space

thurstond · 2024-01-21T22:09:56Z

To confirm the root cause, could you please paste the output from:

sudo sysctl vm.mmap_rnd_bits

?
(this shows the number of bits of entropy for address space layout randomization)

The patch to automatically re-execute the TSan'ified process without randomization, if needed, landed in llvm/llvm-project@0784b1e

A less risky alternative than disabling ASLR for all of Linux is to slightly reduce the amount of randomization:

sudo sysctl vm.mmap_rnd_bits=30

jeremiahar · 2024-01-21T22:20:44Z

I also experienced this problem under Linux 6.7.0 and can confirm that disabling ASLR for the process with setarch `uname -m` -R resolves the issue.

[jeremiah@jeremiah ~]$ sudo sysctl vm.mmap_rnd_bits
vm.mmap_rnd_bits = 32
[jeremiah@jeremiah ~]$

thurstond · 2024-01-21T22:24:43Z

@jeremiahar Thanks for posting the output! That shows your Linux is maxing out the randomization (32 bits), which is incompatible with TSan (max supported is 30 bits on x86 Linux).

PhilippMDoerner · 2024-01-21T22:41:36Z

@jeremiahar Thanks for posting the output! That shows your Linux is maxing out the randomization (32 bits), which is incompatible with TSan (max supported is 30 bits on x86 Linux).

I am not entirely sure if this suffices or if maybe the problem changed with Linux 6.7.0.
Setting vm.mmap_rnd_bits to 30 or even 29 does not resolve this issue (at least it did not for me).

~/dev/playground % sudo sysctl vm.mmap_rnd_bits
vm.mmap_rnd_bits = 30
~/dev/playground % echo "int main(void){}" > hello.c                                                              
~/dev/playground % clang -o hello -fsanitize=thread -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer hello.c
~/dev/playground % ./hello 
FATAL: ThreadSanitizer: unexpected memory mapping 0x7d9ee6e00000-0x7d9ee718e000

This does work if I go down to 28 (it is not possible to select a lower value for me).

~/dev/playground % sudo sysctl vm.mmap_rnd_bits=28
vm.mmap_rnd_bits = 28
~/dev/playground % sudo sysctl vm.mmap_rnd_bits                                                                   
vm.mmap_rnd_bits = 28
~/dev/playground % clang -o hello -fsanitize=thread -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer hello.c
~/dev/playground % ./hello

As double blind, I jumped back to 29 and tried again, starts failing again:

~/dev/playground % sudo sysctl vm.mmap_rnd_bits=29                                                              
vm.mmap_rnd_bits = 29
~/dev/playground % clang -o hello -fsanitize=thread -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer hello.c
~/dev/playground % ./hello                                                                                      
FATAL: ThreadSanitizer: unexpected memory mapping 0x5709a7666000-0x5709a7686000

OS: Arch-Linux, Linux framefrog 6.7.0-arch3-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14 +0000 x86_64 GNU/Linux.

CPU: AMD Ryzen 7 7840U

thurstond · 2024-01-21T22:46:28Z

What version is your clang?

The TSan fix to support 30 bits of ASLR landed last November (llvm/llvm-project@7d039ef), so my initial guess is you have an older version of TSan that only supports 28 bits.

The Linux 6.7 kernel has a default setting of 28 bits of entropy (https://elixir.bootlin.com/linux/v6.7/source/arch/x86/Kconfig). It's likely customized by your distro be higher (which is generally a good thing).

PhilippMDoerner · 2024-01-21T22:49:23Z

Clang version is 16.0.6.

~/dev/playground % clang -v
clang version 16.0.6
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-pc-linux-gnu/13.2.1
Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-pc-linux-gnu/13.2.1
Candidate multilib: .;@m64
Candidate multilib: 32;@m32
Selected multilib: .;@m64
~/dev/playground % uname -a
Linux framefrog 6.7.0-arch3-1 #1 SMP PREEMPT_DYNAMIC Sat, 13 Jan 2024 14:37:14 +0000 x86_64 GNU/Linux
~/dev/playground %

The package appears to have last been updated this january: https://archlinux.org/packages/extra/x86_64/clang/

thurstond · 2024-01-21T22:56:24Z

@PhilippMDoerner Thank you for sharing all the output!

clang 16.0.6 is based on June 13, 2023 source from upstream (https://github.com/llvm/llvm-project/releases/tag/llvmorg-16.0.6), so it doesn't have either of the recent TSan ASLR compatibility fixes (hence TSan is limited to 28 bits of ASLR).

PhilippMDoerner · 2024-01-21T23:00:01Z

Thanks for the clarification! I was trying to figure out what the age of that clang-version was by skimming through docs and other txt files in the repo to little success, this helps immensely in that regard.

Seems like it'll take a bit then until arch catches up to that particular fix. For now I think 28 shouldn't be too bad (?). Better than turning it off for sure I'd imagine. I'll note it down in a related stack-overflow question.

ayushgun · 2024-02-06T18:28:22Z

On Arch with kernal 6.7.1-arch1-1, changing vm.mmap_rnd_bits from 32 to 30 did not resolve the error. However, changing vm.mmap_rnd_bits to 28 successfully resolved the error.

Formak21 · 2024-02-29T17:30:41Z

On Arch with kernal 6.7.1-arch1-1, changing vm.mmap_rnd_bits from 32 to 30 did not resolve the error. However, changing vm.mmap_rnd_bits to 28 successfully resolved the error.

Same situation. Arch, kernel 6.7.6-arch1-1. Changing vm.mmap_rnd_bits to 28 helps. (clang 16.0.6)

cmazakas · 2024-03-07T22:46:14Z

I'm on Ubuntu 23.10 and today I had a kernel update that led me here because it broke all my code too.

I also had to drop down to 28 bits from 32 to make my test suite finally start passing again. Not only did tsan break but asan and ubsan also broke in mysterious ways as well.

When the time comes, I guess I'll eventually increment it back up to 30 or 32 but until then, I can't complain too much.

DimitryAndric · 2024-03-13T13:53:33Z

I reported this in https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056762 for Ubuntu's recent kernel update, which also bumped vm.mmap_rnd_bits for most architectures, and for amd64 from 28 to 32 in particular.

I observed the same as people above: ThreadSanitizer fails with "unexpected memory mapping" when vm.mmap_rnd_bits is at 32. I only tried setting it to 28, then it started working again.

- google/sanitizers#1716

…13150) There is a new change in linux kernel 6.6.6 that uses randomization of address space to harden security, but it interferes with the way ASAN works. Folks are working on a fix, but this is a temporary mitigation for us to get our CI to be green again. See google/sanitizers#1716 for more information See https://github.com/redis/redis/actions/runs/8305126288/job/22731614306?pr=13149 for a recent failure

See google/sanitizers#1716

See: google/sanitizers#1716

thurstond · 2024-03-20T19:07:59Z

To sum up: older versions of TSan are not compatible with very high ASLR entropy, which is the default in some recent Linux distros. The workaround is to reduce ASLR entropy: sudo sysctl vm.mmap_rnd_bits=28.

Newer versions of TSan (LLVM 18.1.0 onwards: llvm/llvm-project@0784b1e) will automatically re-exec without ASLR, if the layout is incompatible. Additionally, TSan in LLVM 18.1.0 onwards can support 30 bits of ASLR entropy without disabling ASLR (llvm/llvm-project@7d039ef).

The ThreadSanitizer version currently available from Fedora 39 repositories is unable to cope with very high ASLR entropy, which is the default in some recent Linux distributions [1]. This causes all TSAN-enabled builds to fail on the affected systems with an error like: FATAL: ThreadSanitizer: unexpected memory mapping 0x7d00e0772000-0x7d00e0c00000 Work around the problem by reducing ASLR entropy for all TSAN-enabled builds until the problem is resolved upstream. [1] google/sanitizers#1716 (cherry picked from commit 05b09f2)

See: google/sanitizers#1716

Since Linux Kernel 6.5 we are getting false positives from the ci, lower the ALSR entropy to disable ALSR, which works as a temporary workaround. google/sanitizers#1716 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056762 closes official-stockfish#5115 No functional change

…it tests. There is a incompatibility between address sanitizer and recent ubuntu versions that causes an eternal loop of deadly signal when running unit tests in local environment. See this issue for more info google/sanitizers#1716

rohumm changed the title ~~Thread Sanitizer FATAL error on kernel version 6.6.6.x~~ Thread Sanitizer FATAL error on kernel version 6.6.6-x Dec 30, 2023

thurstond self-assigned this Jan 13, 2024

thurstond mentioned this issue Jan 16, 2024

Re-exec TSan with no ASLR if memory layout is incompatible on Linux llvm/llvm-project#78351

Merged

vrodedanya mentioned this issue Jan 29, 2024

Empty code randomly crashes with SEGV on unknown address #1724

Open

ggerganov mentioned this issue Mar 12, 2024

ggml : reuse quantum structs across backends ggerganov/llama.cpp#5943

Merged

4 tasks

mirostauder mentioned this issue Mar 12, 2024

Fix clang compilation for tests dep 'cppdotenv' sysown/proxysql#4468

Merged

DimitryAndric mentioned this issue Mar 13, 2024

Crash with memory sanitizer on Linux 6.5.0-25 llvm/llvm-project#85013

Open

samuelkgutierrez mentioned this issue Mar 13, 2024

Attempt to fix CI. hpc/quo-vadis#84

Merged

gitrj95 added a commit to gitrj95/librj that referenced this issue Mar 16, 2024

Patch TSan complaint; Length check in test header write.

e575e61

- google/sanitizers#1716

gitrj95 added a commit to gitrj95/librj that referenced this issue Mar 16, 2024

Patch TSan complaint; Length check in test header write.

b46886f

- google/sanitizers#1716

gitrj95 added a commit to gitrj95/librj that referenced this issue Mar 16, 2024

Sanitizers are broken on kernel >=v6.6.

6883d26

- google/sanitizers#1716

gitrj95 added a commit to gitrj95/librj that referenced this issue Mar 16, 2024

Threads with sanitizers are broken on kernel >=v6.6.

413ec60

- google/sanitizers#1716

gitrj95 added a commit to gitrj95/librj that referenced this issue Mar 16, 2024

Threads and sanitizers are broken on kernel >=v6.6.

8357572

- google/sanitizers#1716

gitrj95 added a commit to gitrj95/librj that referenced this issue Mar 16, 2024

Threads and sanitizers are broken on kernel >=v6.6.

b51aa30

- google/sanitizers#1716

gitrj95 added a commit to gitrj95/librj that referenced this issue Mar 16, 2024

Threads and sanitizers are broken on kernel >=v6.6.

967e281

- google/sanitizers#1716

madolson mentioned this issue Mar 17, 2024

Change mmap rand bits as a temporary mitigation to resolve asan bug redis/redis#13150

Merged

csegarragonz mentioned this issue Mar 18, 2024

tsan: fix random gha failures faasm/faasm#859

Merged

hoffmang9 mentioned this issue Mar 18, 2024

Fix TSAN mode Chia-Network/chiavdf#173

Merged

cmmarslender mentioned this issue Mar 18, 2024

Fix TSAN Chia-Network/chiapos#423

Merged

hoffmang9 pushed a commit to Chia-Network/chiapos that referenced this issue Mar 18, 2024

Fix TSAN (#423)

867cde1

See google/sanitizers#1716

psychocoderHPC mentioned this issue Mar 19, 2024

Fix tsan error: change memory randomization alpaka-group/alpaka#2250

Merged

q2ven mentioned this issue Mar 19, 2024

lib/pty-session: Don't ignore SIGHUP. util-linux/util-linux#2836

Closed

matejk mentioned this issue Mar 20, 2024

GitHub runner: Linux thread sanitizer tests fail with "unexpected memory mapping" pocoproject/poco#4503

Closed

fabbing added a commit to fabbing/ocaml that referenced this issue Mar 20, 2024

Github CI/TSan: tune mmap_rnd_bits for TSan

4a4d28a

See: google/sanitizers#1716

fabbing mentioned this issue Mar 20, 2024

Github CI/TSan: tune mmap_rnd_bits for TSan ocaml/ocaml#13039

Merged

thurstond closed this as completed Mar 20, 2024

OlivierNicole pushed a commit to ocaml/ocaml that referenced this issue Mar 21, 2024

Github CI/TSan: tune mmap_rnd_bits for TSan (#13039)

b83b15f

See: google/sanitizers#1716

thurstond mentioned this issue Mar 21, 2024

Backport MSan ASLR compatibility improvements llvm/llvm-project#86199

Closed

mschwager mentioned this issue Apr 2, 2024

Harness ends with DEADLYSIGNAL at start trailofbits/ruzzy#20

Open

jtcaraball mentioned this issue Apr 6, 2024

[PSA] AddressSanitizer:DEADLYSIGN loop infinito DiegoEmilio01/IIC3413#4

Open

al42and mentioned this issue Apr 11, 2024

ThreadSanitizer: thread leak from HIP runtime ROCm/HIP#3182

Open

ToveRumar mentioned this issue Apr 22, 2024

Documentation: Add instructions for workaround for deadlysignal in un… bitcraze/crazyflie-firmware#1366

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Thread Sanitizer FATAL error on kernel version 6.6.6-x #1716

Thread Sanitizer FATAL error on kernel version 6.6.6-x #1716

rohumm commented Dec 30, 2023 •

edited

rohumm commented Jan 3, 2024

rohumm commented Jan 5, 2024

rohumm commented Jan 5, 2024

dvyukov commented Jan 6, 2024

thurstond commented Jan 11, 2024

thurstond commented Jan 11, 2024

PhilippMDoerner commented Jan 20, 2024 •

edited

russelltg commented Jan 21, 2024

thurstond commented Jan 21, 2024

jeremiahar commented Jan 21, 2024

thurstond commented Jan 21, 2024

PhilippMDoerner commented Jan 21, 2024 •

edited

thurstond commented Jan 21, 2024

PhilippMDoerner commented Jan 21, 2024

thurstond commented Jan 21, 2024

PhilippMDoerner commented Jan 21, 2024

ayushgun commented Feb 6, 2024

Formak21 commented Feb 29, 2024

cmazakas commented Mar 7, 2024

DimitryAndric commented Mar 13, 2024

thurstond commented Mar 20, 2024

Thread Sanitizer FATAL error on kernel version 6.6.6-x #1716

Thread Sanitizer FATAL error on kernel version 6.6.6-x #1716

Comments

rohumm commented Dec 30, 2023 • edited

rohumm commented Jan 3, 2024

rohumm commented Jan 5, 2024

rohumm commented Jan 5, 2024

dvyukov commented Jan 6, 2024

thurstond commented Jan 11, 2024

thurstond commented Jan 11, 2024

PhilippMDoerner commented Jan 20, 2024 • edited

russelltg commented Jan 21, 2024

thurstond commented Jan 21, 2024

jeremiahar commented Jan 21, 2024

thurstond commented Jan 21, 2024

PhilippMDoerner commented Jan 21, 2024 • edited

thurstond commented Jan 21, 2024

PhilippMDoerner commented Jan 21, 2024

thurstond commented Jan 21, 2024

PhilippMDoerner commented Jan 21, 2024

ayushgun commented Feb 6, 2024

Formak21 commented Feb 29, 2024

cmazakas commented Mar 7, 2024

DimitryAndric commented Mar 13, 2024

thurstond commented Mar 20, 2024

rohumm commented Dec 30, 2023 •

edited

PhilippMDoerner commented Jan 20, 2024 •

edited

PhilippMDoerner commented Jan 21, 2024 •

edited