http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55617
Bug #: 55617
Summary: static constructors are not being instrumented
correctly on darwin
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: howa...@nitro.med.uc.edu
CC: do...@gcc.gnu.org, dvyu...@gcc.gnu.org,
ja...@gcc.gnu.org, k...@gcc.gnu.org
A couple hundred failures in the g++ testsuite with -fsanitize=address on
darwin appear to be due to static constructors not being instrumented
correctly. For example...
% g++-fsf-4.8 covariant3.C -fmessage-length=0 -std=c++98 -pedantic-errors
-Wno-long-long -g -multiply_defined suppress -lm -fsanitize=address -o
./covariant3.exe
produces a executable that crashes due to the missing calls to __asan_init
before the module's static constructors...
% gdb ./covariant3.exe
GNU gdb 6.3.50-20050815 (Apple version gdb-1822) (Sun Aug 5 03:00:42 UTC 2012)
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "x86_64-apple-darwin"...Reading symbols for shared
libraries ...... done
(gdb) r
Starting program: /Users/howarth/asan_g++_failures/covariant3.exe
Reading symbols for shared libraries +++++.................................
done
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x000010002000068a
0x0000000100001e60 in c1::c1 (this=0x100003d08, __vtt_parm=0x100003450) at
covariant3.C:10
10 struct c1 : virtual c0 {
(gdb) bt
#0 0x0000000100001e60 in c1::c1 (this=0x100003d08, __vtt_parm=0x100003450) at
covariant3.C:10
#1 0x0000000100001f1c in c18::c18 (this=0x100003d00) at covariant3.C:29
#2 0x0000000100001cdc in __static_initialization_and_destruction_0
(__initialize_p=1, __priority=65535) at covariant3.C:42
#3 0x0000000100001cf1 in _GLOBAL__sub_I_covariant3.C () at covariant3.C:85
#4 0x00007fff5fc13378 in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
#5 0x00007fff5fc13762 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
()
#6 0x00007fff5fc1006e in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
()
#7 0x00007fff5fc0feba in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
()
#8 0x00007fff5fc01fc0 in __dyld__ZN4dyld24initializeMainExecutableEv ()
#9 0x00007fff5fc05b04 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_Pm
()
#10 0x00007fff5fc01397 in
__dyld__ZN13dyldbootstrap5startEPK12macho_headeriPPKclS2_Pm ()
#11 0x00007fff5fc0105e in __dyld__dyld_start ()
(gdb)
The assembly file and a gdb log which stepi's from the 38th breakpoint of
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
is attached.
