When LD_PRELOAD is defined (which can be a consequence of gtk3-nocsd
being installed and the user being in an X11 session), I get:

cventin:~> gcc -fsanitize=address t.c
cventin:~> ./a.out
==22051==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD.

Something should be done. This was very confusing at first, because
the problem first came here when I ran a configure script which was
working a few days ago (after investigation, it is now clear that
the reason was that it wasn't under a X11 session a few days ago),
and just saw:

checking whether we are cross compiling... configure: error: in `/home/vlefevre/tmp/mpfr-old':
configure: error: cannot run C compiled programs.
If you meant to cross compile, use `--host'.
See `config.log' for more details

I could see the error message, but the reason wasn't clear yet
(I initially thought of a regression after a recent upgrade).

So, I think that if possible, having LD_PRELOAD already set shouldn't
affect ASan. Shouldn't -static-libasan be the default, for instance?

If this is not possible, various things should be clarified:

1. The error message should be more informative, e.g. when LD_PRELOAD
is set, say that LD_PRELOAD is set but ASan runtime does not appear
in LD_PRELOAD or does not come first.

2. The gcc(1) man page does not mention LD_PRELOAD at all. Ditto for
the GCC manual.

3. How to find the right ASan runtime *automatically* should also be
documented.

Dear submitter,

as the package gcc-6 has just been removed from the Debian archive
unstable we hereby close the associated bug reports.  We are sorry
that we couldn't deal with your issue properly.

For details on the removal, please see https://bugs.debian.org/920171

The version of this package that was in Debian prior to this removal
can still be found using http://snapshot.debian.org/.

This message was generated automatically; if you believe that there is
a problem with it please contact the archive administrators by mailing
ftpmaster@ftp-master.debian.org.

Debian distribution maintenance software
pp.
Scott Kitterman (the ftpmaster behind the curtain)

FYI, there was already

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=930430

about libasan8.

forcemerge 836848 930430
retitle 836848 libasan*: AddressSanitizer breaks when LD_PRELOAD is defined
thanks

Hi Vincent,

oh, okay. Merging them; 836848 is the one search engines find.
(It’s annoying that bugs in versioned source package names are
routinely lost.)

Do you have found any workaround meanwhile, other than using
-static-asan (plus -static-ubsan, perhaps, but -static-libgcc
seems not to be required), which has many downsides?

This affects cowbuilder, which uses LD_PRELOAD, as well, which
is annoying (e.g. I wanted to run sadt for autopkgtests on a
package in which I just added an ASan/UBSan debug build).

bye,
//mirabilos

No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
	-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Hi Thorsten,

In my case, I just unset LD_PRELOAD, which is not needed when
I'm testing software with AddressSanitizer.

HAve you tried putting libasan* in LD_PRELOAD, hoping that it
will be loaded first (i.e. tools that add shared objects to
LD_PRELOAD should append them).

Vincent Lefevre dixit:

Risky with things like cowbuilder, impossible with fakeroot
or datefudge, etc.

I could just prepend it before the call to the test run in
question, as LD_PRELOAD is set for the entire environment.

But, to what? There’s no unversioned .so, and the version
number of the .so.{3,6,8,…} differs, and it is not easy to
find. (Sure, ldd or objdump -p, but I’d not want to automate
on that.)

bye,
//mirabilos