This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()
- From: "m.ostapenko at samsung dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Wed, 15 Mar 2017 07:25:28 +0000
- Subject: [Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()
- Auto-submitted: auto-generated
- References: <bug-80027-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80027
--- Comment #4 from Maxim Ostapenko <m.ostapenko at samsung dot com> ---
(In reply to Michael Thayer from comment #3)
> Seems my mistake. I think the ASAN library was still getting loaded
> dynamically. Now I have the following problem, which I think means that
> code (constructors?) getting called before ASAN is initialised is getting
> hold of memory map areas which ASAN is hard-coded to use. So probably no
> static ASAN for me.
>
> ==10420==Shadow memory range interleaves with an existing memory mapping.
> ASan cannot proceed correctly. ABORTING.
> ==10420==ASan shadow was supposed to be located in the
> [0x00007fff7000-0x10007fff7fff] range.
> ==10420==Process memory map follows:
> 0x00007fff7000-0x00008fff7000
> 0x00008fff7000-0x02008fff7000
> 0x02008fff7000-0x10007fff8000
> [...]
This usually happens when your executable isn't linked with libasan but some
shared library is. Check that your test binary is properly linked with libasan.