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
