http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56393
Kostya Serebryany <kcc at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2013-02-19
Ever Confirmed|0 |1
--- Comment #6 from Kostya Serebryany <kcc at gcc dot gnu.org> 2013-02-19
18:33:32 UTC ---
The problem also shows up with clang.
Funny. C++ global init has greater priority than C global init.
This is the usual place from where __asan_init is called:
gcc:
#0 __asan_init_v1 () at ../../../../gcc/libsanitizer/asan/asan_rtl.cc:315
#1 0x0000000000417819 in _GLOBAL__sub_I_00099_1_g ()
#2 0x000000000041788d in __libc_csu_init ()
#3 0x00007ffff761b700 in __libc_start_main
#4 0x0000000000401ec9 in _start ()
clang:
#0 __asan_init_v1 ()
#1 0x0000000000419dcd in asan.module_ctor ()
#2 0x0000000000419e8d in __libc_csu_init ()
#3 0x00007ffff761b700 in __libc_start_main
#4 0x0000000000419b15 in _start ()
This is where your test case crashes:
#0 0x000000000041a864 in boost::exception_ptr
boost::get_static_exception_object<boost::bad_alloc_>() ()
#1 0x00007ffff7ff62c9 in __cxx_global_var_init () from ./libhoge.so
#2 0x00007ffff7ff62f9 in global constructors keyed to a () from ./libhoge.so
#3 0x00007ffff7de9306 in call_init
#4 0x00007ffff7de93df in call_init
#5 _dl_init
#6 0x00007ffff7ddb6ea in _dl_start_user
Apparently, _dl_start_user starts before _start.
In fact, I think that we saw something like this before and this is why
in one of our settings we run __asan_init from the preinit array. I.e. from
here:
#0 __asan_init_v1 () at
#1 0x00007ffff7de943e in _dl_init
#2 0x00007ffff7ddb6ea in _dl_start_user () from /lib64/ld-linux-x86-64.so.2
Looks like it's time to enable the preinit hack by default on linux, it's
pretty stable now.
Thoughts?
You may temporary change "defined(ASAN_USE_PREINIT_ARRAY)" to '1' in
asan_rtl.cc,
or add something like this into your code:
__attribute__((section(".preinit_array")))
typeof(__asan_init) *__asan_preinit =__asan_init;
