Fwd: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins

Albert Astals Cid aacid at kde.org
Tue Dec 1 23:53:34 GMT 2015


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-reports-in-ex
> > te
> > rnal-libraries):
> This are not AddressSanitizer warnings, they are LeakSanitizer warnings.

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.

Cheers,
  Albert

P.S: FWIW i actually fixed (I think) the libxslt bug 
https://bugzilla.gnome.org/show_bug.cgi?id=758931

> 
> Cheers,
>   Albert
> 
> > * Put a file, e.g. named kde-asan.supp, with the following content
> > somewhere where the build system can find it (e.g. add it to the build
> > system repository?)
> > =====
> > interceptor_via_lib:libxslt
> > interceptor_via_lib:libxml2
> > =====
> > (The documentation reads
> > interceptor_via_lib:NameOfTheLibraryToSuppress
> > I'm not sure if using "libxml2" as "NameOfTheLibraryToSuppress" is
> > correct. Maybe it needs to be "libxml2.so". DuckDuckGo did not find a
> > single example of the usage of interceptor_via_lib in the entire
> > Internet. Weird.)
> > 
> > * Define the following environment variable, e.g. as global environment
> > variable, in Jenkins
> > ASAN_OPTIONS=suppressions=<path to kde-asan.supp>
> > 
> > 
> > I don't know how our Jenkins is set up, so there might be better ways to
> > get the file with the suppressions into Jenkins.
> > 
> > > On Tue, Dec 1, 2015 at 10:55 AM, Scarlett Clark wrote to
> > > Albert Astals Cid
> > > 
> > > > On Thu, Sep 10, 2015 at 2:34 PM, Albert Astals Cid <aacid at kde.org>
> > > > 
> > > > wrote:
> > > > > El Dijous, 10 de setembre de 2015, a les 18:20:19, Lamarque Souza
> > > > > 
> > > > > va escriure:
> > > > > > I agree but there is a problem: it can catch a lot of errors in
> > > > > > our dependency libraries (upstream bugs).
> > > > > 
> > > > > No, it can not, asan works only on code you have compiled with
> > > > > asan enabled (which for most of our dependencies we do not compile
> > > > > or they don't use ECM).
> > > > 
> > > > OK, I am going to have to disagree here.
> > 
> > And rightfully so. The ASan documentation clearly states
> > "Runtime interposition allows AddressSanitizer to find bugs in code that
> > is not being recompiled."
> > 
> > 
> > Regards,
> > Ingo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 181 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20151202/780a8b87/attachment.sig>


More information about the kde-core-devel mailing list