+glider
The compiler hardly matters here, I would expect the same failures with
clang.
Alex, could you please take a look?
--kcc
Kostya,
The problem is that clang uses a very different and older libstdc++ than FSF gcc so
that the code exection path is very different. For example...
% /sw/opt/llvm-3.2/bin/clang++ -fsanitize=address -std=c++98 cond1.C -g -O0 -o cond1_asan_clang.exe
% gdb ./cond1_asan_clang.exe
...
(gdb) break main
Breakpoint 1 at 0x100001bc4: file cond1.C, line 21.
(gdb) r
...
Breakpoint 1, main (argc=<value temporarily unavailable, due to optimizations>, argv=0x7fff5fbfe5a0) at cond1.C:21
21 (argc+1 ? has_destructor() : throw 0);
(gdb) s
has_destructor::~has_destructor (this=<value temporarily unavailable, due to optimizations>) at cond1.C:10
10 ~has_destructor() { }
(gdb)
has_destructor::~has_destructor (this=<value temporarily unavailable, due to optimizations>) at cond1.C:10
10 ~has_destructor() { }
(gdb)
0x00000001000084e8 in has_destructor::~has_destructor (this=<value temporarily unavailable, due to optimizations>) at cond1.C:10
10 ~has_destructor() { }
(gdb)
main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at cond1.C:22
22 CI((argc+1 ? throw 0 : has_destructor()));
(gdb)
Program exited normally.
whereas for FSF gcc...
% g++-fsf-4.8 -static-libasan -fsanitize=address -std=c++98 cond1.C -g -O0 -o cond1_asan.exe
% gdb ./cond1_asan.exe
...
(gdb) break main
Breakpoint 1 at 0x100001b35: file cond1.C, line 21.
(gdb) r
Starting program: /Users/howarth/asan_eh_bug/cond1_asan.exe
Reading symbols for shared libraries ++++................................. done
Breakpoint 1, main (argc=1, argv=0x7fff5fbff898) at cond1.C:21
21 (argc+1 ? has_destructor() : throw 0);
(gdb) s
has_destructor::~has_destructor (this=0x7fff5fbff7cf) at cond1.C:10
10 ~has_destructor() { }
(gdb)
main (argc=1, argv=0x7fff5fbff898) at cond1.C:22
22 CI((argc+1 ? throw 0 : has_destructor()));
(gdb)
__cxa_allocate_exception (thrown_size=132) at ../../../../gcc-4.8-20121127/libstdc++-v3/libsupc++/eh_alloc.cc:102
102 ret = malloc (thrown_size);
(gdb)
0x00000001022b60da in dyld_stub_malloc () at ../../../../gcc-4.8-20121127/libstdc++-v3/libsupc++/eh_alloc.cc:204
204 __cxxabiv1::__cxa_free_dependent_exception
(gdb)
0x00007fff8bd80878 in dyld_stub_binder ()
(gdb)
Single stepping until exit from function dyld_stub_binder,
which has no line number information.
0x00007fff8bd808a5 in misaligned_stack_error_entering_dyld_stub_binder ()
(gdb)
Single stepping until exit from function misaligned_stack_error_entering_dyld_stub_binder,
which has no line number information.
0x00007fff8bd808e1 in dyld_stub_binder_ ()
(gdb)
Single stepping until exit from function dyld_stub_binder_,
which has no line number information.
0x00007fff8bd81f61 in _dyld_fast_stub_entry ()
(gdb)
Single stepping until exit from function _Z21_dyld_fast_stub_entryPvl,
which has no line number information.
0x00007fff5fc03fbd in __dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm ()
(gdb)
Single stepping until exit from function __dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm,
which has no line number information.
0x00007fff8bd808ee in dyld_stub_binder_ ()
(gdb)
Single stepping until exit from function dyld_stub_binder_,
which has no line number information.
0x00007fff94c3bb7e in malloc ()
(gdb)
Single stepping until exit from function malloc,
which has no line number information.
__cxa_allocate_exception (thrown_size=132) at ../../../../gcc-4.8-20121127/libstdc++-v3/libsupc++/eh_alloc.cc:104
104 if (! ret)
(gdb)
102 ret = malloc (thrown_size);
(gdb)
104 if (! ret)
(gdb)
132 __cxa_eh_globals *globals = __cxa_get_globals ();
(gdb)
__cxa_get_globals () at ../../../../gcc-4.8-20121127/libstdc++-v3/libsupc++/eh_globals.cc:63
63 { return get_global(); }
(gdb)
0x00000001022b6254 in dyld_stub___emutls_get_address () at ../../../../gcc-4.8-20121127/libstdc++-v3/libsupc++/eh_alloc.cc:204
204 __cxxabiv1::__cxa_free_dependent_exception
(gdb)
0x00007fff8bd80878 in dyld_stub_binder ()
(gdb)
Single stepping until exit from function dyld_stub_binder,
which has no line number information.
0x00007fff8bd808a5 in misaligned_stack_error_entering_dyld_stub_binder ()
(gdb)
Single stepping until exit from function misaligned_stack_error_entering_dyld_stub_binder,
which has no line number information.
0x00007fff8bd808e1 in dyld_stub_binder_ ()
(gdb)
Single stepping until exit from function dyld_stub_binder_,
which has no line number information.
0x00007fff8bd81f61 in _dyld_fast_stub_entry ()
(gdb)
Single stepping until exit from function _Z21_dyld_fast_stub_entryPvl,
which has no line number information.
0x00007fff5fc03fbd in __dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm ()
(gdb)
Single stepping until exit from function __dyld__ZN4dyld18fastBindLazySymbolEPP11ImageLoaderm,
which has no line number information.
0x00007fff8bd808ee in dyld_stub_binder_ ()
(gdb)
Single stepping until exit from function dyld_stub_binder_,
which has no line number information.
__emutls_get_address (obj=0x1022f9520) at ../../../gcc-4.8-20121127/libgcc/emutls.c:128
128 {
(gdb)
Current language: auto; currently c
139 pointer offset = obj->loc.offset;
(gdb)
141 if (__builtin_expect (offset == 0, 0))
(gdb)
700 return __gthrw_(pthread_once) (__once, __func);
(gdb)
0x00000001023f842a in dyld_stub_pthread_once ()
(gdb)
Single stepping until exit from function dyld_stub_pthread_once,
which has no line number information.
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000000ffd27000
0x00000000ffd27000 in ?? ()
(gdb)
I did try....
% /sw/opt/llvm-3.2/bin/clang++ -fsanitize=address -std=c++98 cond1.C -g -O0 -stdlib=libc++ -o cond1_asan_clang.exe
using the libc++ from Mountain Lion. It doesn't trigger the bug either and executes without calling pthread...
% ./cond1_asan_clang.exe
% gdb ./cond1_asan_clang.exe
...
(gdb) break main
Breakpoint 1 at 0x100001bc4: file cond1.C, line 21.
(gdb) r
Starting program: /Users/howarth/asan_eh_bug/cond1_asan_clang.exe
Reading symbols for shared libraries +++................................ done
Breakpoint 1, main (argc=<value temporarily unavailable, due to optimizations>, argv=0x7fff5fbfe5a0) at cond1.C:21
21 (argc+1 ? has_destructor() : throw 0);
(gdb) s
has_destructor::~has_destructor (this=<value temporarily unavailable, due to optimizations>) at cond1.C:10
10 ~has_destructor() { }
(gdb)
has_destructor::~has_destructor (this=<value temporarily unavailable, due to optimizations>) at cond1.C:10
10 ~has_destructor() { }
(gdb)
0x00000001000084e8 in has_destructor::~has_destructor (this=<value temporarily unavailable, due to optimizations>) at cond1.C:10
10 ~has_destructor() { }
(gdb)
main (argc=<value temporarily unavailable, due to optimizations>, argv=<value temporarily unavailable, due to optimizations>) at cond1.C:22
22 CI((argc+1 ? throw 0 : has_destructor()));
(gdb)
Program exited normally.
Note that we have run into pthread bugs in the past which Apple has slowly fixed. Also, IMHO anything
that uses the unwinder is always suspect on FSF gcc because we are the only target that uses a system
which has subsumed the unwinder and libgcc calls out of libgcc (ie we don't run the unwinder and the
libgcc calls present in the libgcc_s.10.5 stub from the FSF gcc files but rather those from libSystem).
Jack