Description of problem: I installed gcc, gdb, and libtsan packages to the "fedora:35" Docker image and compiled a trivial C program with "-fsanitize=thread". The binary segfaults with a trace in libtsan: [root@37c88ae6ca23 ~]# cat test.c int main (void) { return 0; } [root@37c88ae6ca23 ~]# gcc -fsanitize=thread test.c -o test [root@37c88ae6ca23 ~]# gdb ./test (gdb) run Starting program: /root/test [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". Program received signal SIGSEGV, Segmentation fault. 0x00007ffff751fbaf in __tsan::TraceAddEvent (addr=0, typ=__tsan::EventTypeMop, fs=..., thr=0x7ffff6f237c0) at ../../../../libsanitizer/tsan/tsan_rtl.h:872 872 *evp = ev; (gdb) bt #0 0x00007ffff751fbaf in __tsan::TraceAddEvent (addr=0, typ=__tsan::EventTypeMop, fs=..., thr=0x7ffff6f237c0) at ../../../../libsanitizer/tsan/tsan_rtl.h:872 #1 __tsan::Release (thr=thr@entry=0x7ffff6f237c0, pc=<optimized out>, addr=addr@entry=140737345483248) at ../../../../libsanitizer/tsan/tsan_rtl_mutex.cpp:453 #2 0x00007ffff74b80f2 in __cxa_guard_release (g=0x7ffff77bf1f0 <guard variable for __sanitizer::GetAltStackSize()::kAltStackSize>) at ../../../../libsanitizer/tsan/tsan_interceptors_posix.cpp:882 #3 0x00007ffff7535915 in __sanitizer::GetAltStackSize () at ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:170 #4 0x00007ffff7535e85 in __sanitizer::SetAlternateSignalStack () at ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:183 #5 __sanitizer::SetAlternateSignalStack () at ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:174 #6 0x00007ffff7536035 in __sanitizer::InstallDeadlySignalHandlers (handler=handler@entry=0x7ffff7511ff0 <__tsan::TsanOnDeadlySignal(int, void*, void*)>) at ../../../../libsanitizer/sanitizer_common/sanitizer_posix_libcdep.cpp:217 #7 0x00007ffff751389d in __tsan::Initialize (thr=0x7ffff6f237c0) at ../../../../libsanitizer/tsan/tsan_rtl.cpp:395 #8 0x00007ffff7fdb86e in _dl_init (main_map=0x7ffff7ffe1e0, argc=1, argv=0x7fffffffe6a8, env=0x7fffffffe6b8) at dl-init.c:102 #9 0x00007ffff7fcc0ca in _dl_start_user () from /lib64/ld-linux-x86-64.so.2 #10 0x0000000000000001 in ?? () #11 0x00007fffffffe8bd in ?? () #12 0x0000000000000000 in ?? () This scenario works fine on Fedora 34. Version-Release number of selected component (if applicable): gcc-11.2.1-1.fc35.x86_64 libtsan-11.2.1-1.fc35.x86_64
*** Bug 2020766 has been marked as a duplicate of this bug. ***
In rhbz#2020766 it was said "There is a fix for RHEL 9 Beta already". But rhbz#1992727 access is restricted. I suspect the fix is https://git.centos.org/rpms/gcc/blob/b9880e4cb7d6d96694b0650fb93e67ea40fcf4f1/f/SOURCES/gcc11-tsan-sigstksz.patch. Looking at https://src.fedoraproject.org/rpms/gcc/commits/f35 surely this has been fixed since 11.2.1-3, from 3 months ago. There is already 11.2.1-6. But for some reason, we still only have 11.2.1-1 in the repositories. I have not tested them, but probably the problem goes away with https://koji.fedoraproject.org/koji/buildinfo?buildID=1846894. In https://bodhi.fedoraproject.org/updates/?packages=gcc there is a "New Update" button, and it seems I could actually try to create the update myself. But not sure how "polite" that would be, surely this is usually something @jakub usually does?
https://bodhi.fedoraproject.org/updates/FEDORA-2021-7de153eeb7 fixes the problem for me.
You are right, the needed fix is the patch you linked to. The original GCC commit with it is https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=91f8a7a34cf29ae7c465603a801326767f1cc7e9. Simply using the newer build (containing patch) fixes the issue. I don't know what is the procedure to initiate package update in Fedora.
Given the delay, I tried to create the update. But when pressing on "Submit" it complained with "Access denied".
(In reply to Michal Nowak from comment #3) > https://bodhi.fedoraproject.org/updates/FEDORA-2021-7de153eeb7 fixes the > problem for me. Of course this is for Fedora 36... Locally I installed packages from https://koji.fedoraproject.org/koji/buildinfo?buildID=1846894.
There have been no updates in https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/vendors/redhat/heads/gcc-11-branch since the 19th, even if Jakub is active in the repository (https://gcc.gnu.org/git/?p=gcc.git;a=search;h=refs/heads/master;s=Jakub+Jelinek;st=author). So I guess it's stable enough to try to create an update. The 4 members listed in https://src.fedoraproject.org/rpms/gcc are in this bug CC list. Without knowing too much about the Fedora structure/workings, it seems to me that something has gone wrong here. AFAICS it only requires 5 minutes of human intervention and then Bodhi will take care of it. Other than keep adding "What's the status?" comments to this bug, I don't know what else to do.
https://bodhi.fedoraproject.org/updates/FEDORA-2021-b5b10d9627
This message is a reminder that Fedora Linux 35 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora Linux 35 on 2022-12-13. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a 'version' of '35'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, change the 'version' to a later Fedora Linux version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora Linux 35 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora Linux, you are encouraged to change the 'version' to a later version prior to this bug being closed.
This has been solved since early Fedora 35 days.