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.
