On Wednesday 02 December 2015 00:53:34 Albert Astals Cid wrote: > El Wednesday 02 December 2015, a les 00:11:33, Albert Astals Cid va escriure: > > El Tuesday 01 December 2015, a les 23:44:23, Ingo Klöcker va escriure: > > > On Tuesday 01 December 2015 12:45:13 Scarlett Clark wrote: > > > > Resent - meant for list. > > > > Help please folks, I need someone with more knowledge with gcc > > > > and > > > > compiler flags / settings. > > > > I *think* what needs to be done is blacklists or some such. I > > > > don't > > > > think this should be *my* responsibility to fix. > > > > If it is.. then docker builds is back burnered for the > > > > unforeseeable > > > > future. I simply do not have time right now to try and figure > > > > this out. I accidentally overloaded myself with commitments. And > > > > holidays are arriving soon to top things off. > > > > It may very well be simple to fix... > > > > Sorry, but I need help here. > > > > > > I think the following should work (for details see > > > http://clang.llvm.org/docs/AddressSanitizer.html#suppressing-repor > > > ts-in-external-libraries): > > > > This are not AddressSanitizer warnings, they are LeakSanitizer > > warnings.
Ahh. Sorry for the confusion. > I told Scarlett to use the ASAN_OPTIONS=detect_leaks=0 env var to go > back to the behaviour we wanted, i.e. run ASAN but not LSAN since we > were stuck in a real leak inside libxslt and we can't expect us to > fix those bugs and get them in the CI so that it's green. > > Maybe in the future when the libxslt release is fixed we can try > enabling detect_leaks again and seeing where it does get stuck. AFAICS it's also possible to suppress leaks. LSAN_OPTIONS=suppressions=/path/to/suppressions.txt where suppressions.txt contains leak:<wildcard> At work I saw people use a library name, i.e. libxslt.so as <wildcard>. See https://www.chromium.org/developers/testing/leaksanitizer or https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions > P.S: FWIW i actually fixed (I think) the libxslt bug > https://bugzilla.gnome.org/show_bug.cgi?id=758931 Excellent! That's even better than suppressing it. Regards, Ingo
signature.asc
Description: This is a digitally signed message part.
