1

Currently I'm running into a known problem with asan (See report)

==5097==Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly. ABORTING.
==5097==ASan shadow was supposed to be located in the [0x00007fff7000-0x10007fff7fff] range.

Is it possible to use an environment variable to stop asan being used to prevent this error?

Or at least stop this error from being fatal.

The reason I want to do this is the failing command happens when generating code, but I'd like to use asan for the resulting binary. Having different CFLAGS for generated binaries and the final binary is possible but it would be hard to do without hard-coding it in for everyone else. So I'd like a way to disable asan during the build step, but use afterwards.

Edit: in case it's useful, this occurs with an extremely simple program: Error, Code.

ideasman42
  • 42,413
  • 44
  • 197
  • 320
  • Have you tried checking which library occupied this memory region required by Asan? – yugr Jul 24 '17 at 09:15
  • What is strange about the error is that executable is mapped to 0x00ab8a216000 instead of [usual 0x400000](https://stackoverflow.com/questions/14314021/why-linux-gnu-linker-chose-address-0x400000). Is there anything special about the way you link datatoc? Maybe special `LDFLAGS`? – yugr Jul 24 '17 at 11:55
  • Nothing strange regarding LDFLAGS, besides using ASAN. – ideasman42 Jul 24 '17 at 13:40
  • There must be reason why your executable is loaded at non-standard address. Perhaps it's a PIE? – yugr Jul 24 '17 at 14:36
  • 1
    This bug report is probably more relevant than the one linked from your question: https://github.com/google/sanitizers/issues/837 If [this report](https://bugzilla.kernel.org/show_bug.cgi?id=196537) is right, downgrading your kernel to < 4.12.3 will avoid the issue until the bug has been resolved. – Rob W Aug 18 '17 at 12:43

2 Answers2

2

No, this is a fundamental error which prevents all later instrumentation by Asan from working correctly. E.g. stack poisoning in function prologues would end up causing segfaults or corrupting random memory.

yugr
  • 19,769
  • 3
  • 51
  • 96
1

The error you reported is not an addressabilty error found by address sanitizer but an issue with the address sanitizer itself. Read the FAQ here. Reporting here the part that is relevant to your case:

Q: I'm using dynamic ASan runtime and my program crashes at start with "Shadow memory range interleaves with an existing memory mapping. ASan cannot proceed correctly.".

A1: If you are using shared ASan DSO, try LD_PRELOAD'ing Asan runtime into your program.

Perennialista
  • 1,083
  • 2
  • 12
  • 22