Open noloader opened 5 years ago
I guess this is happening with gcc, where the default for asan is to use shared library. With clang, the default is to use static library and this problem should not exist. Please try clang, or ask someone in the gcc land to help.
Please provide an accurate message during failures.
What is inaccurate about the message exactly? Please try to provide an MVCE.
Based on your log, standalone run LD_DEBUG=libs tests/tst_stringprep
is ok (interceptions are initialized after ...ASan runtime does not come first in initial library list ...
check, runtime library list order is correct here), so you have a problem with testsuite runner environment.
@noloader so, LD_PRELOAD'ing ASan shared library didn't help you?
And regarding second problem (with missed symbols): actually, these __isoc99_vfprintf
symbols were always undefined and honestly I don't know why ASan tries to intercept them. This error message is confusing, but these missing symbols are not a problem at all.
I've been trying to test GnuTLS and several other GNU packages under Asan. I dutifully build all dependent libraries with Asan, too. Everything gets built with
LDFLAGS
of-L<path> -Wl,-R,<path> -Wl,--enable-new-dtags
, so everything will find the proper libraries and allowRUNPATH
overrides viaLD_LIBRARY_PATH
.One of the dependent libraries is GNU's IDN, which handles internationalized domain names. IDN passes its tests in non-instrumented builds. IDN is failing its tests under Asan.
IDN has three test runners. The first two test runners test libidn.so functionality, and they test OK. The third test runner tests Gnulib, which IDN uses. The Gnulib testing fails with the error shown below. I can duplicate the failure on both Debian 9 and Fedora 29.
I spent the better part of two days attempting to straighten out
LD_LIBRARY_PATHs
and potentialLD_PRELOAD
problems (I could not find use ofLD_PRELOAD
in this instance).FIRST PROBLEM: It appears the message "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" is incorrect.
The bs message really pisses me off because it took me down a rabbit hole and wasted two days of my time, wasted the time of folks on the IDN mailing list, and wasted the time of folks on the Gnulib mailing list.
Please provide an accurate message during failures.
SECOND PROBLEM: It took me a while to get to this point because I was chasing Unicorns... It appears Asan is missing some symbols needed to properly intercept Gnulib.
libasan.so.3
is from Debian 9.9. On Fedora 28 and 29 the culprit islibasan.so.5
.I see a similar report at Issue 957, Initialization failure with long object paths, but I am not clear how to work around it. Also, the 957 issue seems to indicate 32-bit platforms, but I can reproduce on 64-bit platforms.