https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67135
Bug ID: 67135 Summary: [thread_local] heap-use-after-free (OS X 10.10.4) Product: gcc Version: 5.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: marian.tri...@haw-hamburg.de Target Milestone: --- Created attachment 36140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36140&action=edit code example #include <thread> #include <memory> thread_local std::unique_ptr<int> uptr; int main() { std::thread t1([]{ if (! uptr) uptr = std::unique_ptr<int>(new int); }); t1.join(); } Compiled with: g++-5 -std=c++11 main.cpp -fsanitize=address -fno-omit-frame-pointer It will trigger a heap-use-after-free, detected from ASAN: ================================================================= ==25568==ERROR: AddressSanitizer: heap-use-after-free on address 0x60200000dfd8 at pc 0x00010e6c5548 bp 0x000111b37e10 sp 0x000111b37e08 READ of size 8 at 0x60200000dfd8 thread T1 #0 0x10e6c5547 (/Users/Hamdor/osx_thread_local/./a.out+0x100002547) #1 0x10f3f48e5 (/usr/local/lib/gcc/5/libstdc++.6.dylib+0x18e5) #2 0x7fff86535450 (/usr/lib/system/libsystem_pthread.dylib+0x4450) #3 0x7fff86534272 (/usr/lib/system/libsystem_pthread.dylib+0x3272) #4 0x7fff865341e4 (/usr/lib/system/libsystem_pthread.dylib+0x31e4) #5 0x7fff8653241c (/usr/lib/system/libsystem_pthread.dylib+0x141c) 0x60200000dfd8 is located 8 bytes inside of 16-byte region [0x60200000dfd0,0x60200000dfe0) freed by thread T1 here: #0 0x10e708419 (/usr/local/lib/gcc/5/libasan.2.dylib+0x32419) #1 0x10f68c682 (/usr/local/lib/gcc/5/libgcc_s.1.dylib+0x11682) previously allocated by thread T1 here: #0 0x10e70826a (/usr/local/lib/gcc/5/libasan.2.dylib+0x3226a) #1 0x10f68c7db (/usr/local/lib/gcc/5/libgcc_s.1.dylib+0x117db) Thread T1 created by T0 here: #0 0x10e6e40f0 (/usr/local/lib/gcc/5/libasan.2.dylib+0xe0f0) #1 0x10f425d6c (/usr/local/lib/gcc/5/libstdc++.6.dylib+0x32d6c) SUMMARY: AddressSanitizer: heap-use-after-free ??:0 ?? Shadow bytes around the buggy address: 0x1c0400001ba0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0400001bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0400001bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0400001bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0400001be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa =>0x1c0400001bf0: fa fa fa fa fa fa 04 fa fa fa fd[fd]fa fa fd fd 0x1c0400001c00: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa 0x1c0400001c10: fa fa fa fa fa fa 00 06 fa fa 00 00 fa fa 00 04 0x1c0400001c20: fa fa 00 06 fa fa 00 06 fa fa 00 fa fa fa 00 00 0x1c0400001c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00 0x1c0400001c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00 Shadow byte legend (one shadow byte represents 8 application bytes): Addressable: 00 Partially addressable: 01 02 03 04 05 06 07 Heap left redzone: fa Heap right redzone: fb Freed heap region: fd Stack left redzone: f1 Stack mid redzone: f2 Stack right redzone: f3 Stack partial redzone: f4 Stack after return: f5 Stack use after scope: f8 Global redzone: f9 Global init order: f6 Poisoned by user: f7 Container overflow: fc Array cookie: ac Intra object redzone: bb ASan internal: fe ==25568==ABORTING This bug was tested with: g++-5 --version g++-5 (Homebrew gcc5 5.2.0) 5.2.0 Older GCC versions are also affected (tested on 4.9.2) Builds on Linux seems to be not affected, ASAN does not detect a heap-use-after-free for the same code. OS X is 10.10.4