This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug sanitizer/80027] ASAN breaks DT_RPATH $ORIGIN in dlopen()


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]