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

[Ingo Klöcker]

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:

At work I saw people use a library name, i.e. libxslt.so as .


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.

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

[Scarlett Clark]

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.
Scarlett

-- Forwarded message --
From: Scarlett Clark <scarlett.gately.cl...@gmail.com>
Date: Tue, Dec 1, 2015 at 10:55 AM
Subject: Re: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins
To: Albert Astals Cid <aa...@kde.org>


OK, I am going to have to disagree here.

Proof in case:
https://build-sandbox.kde.org/job/kdoctools%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/2/console

libxml2 and libxslt are the problem which *is* external.
I tried removing the ecm flag for kdoctools but we still have asan errors
now.

Someone needs to step up and help me out here as I do not have time to try
and figure out how to fix this mess.
It is a blocker for CI to move to docker (more builders yay!) which I think
everyone would like to see happen.

Thanks,
Scarlett



On Thu, Sep 10, 2015 at 2:34 PM, Albert Astals Cid <aa...@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).
>
> Cheers,
>   Albert
>
> > I had this problem when I used it
> > with a program I develop at my work. Enabling it for all programs at once
> > and fixing all those upstream bugs can be overwhelming. Maybe we should
> do
> > it for a limited number of programs first and add more programs as we fix
> > the errors.
> >
> > Lamarque V. Souza
> >
> > http://planetkde.org/pt-br
> >
> > On Thu, Sep 10, 2015 at 5:36 PM, Albert Astals Cid <aa...@kde.org>
> wrote:
> > > We have this nice ECM module that gives us the option to compile with
> > > ASAN.
> > >
> > > I'd like to propose that we enable it by default in jenkins.
> > >
> > > This way we get all the autotests run with ASAN and potentially catch
> more
> > > bugs/regressions.
> > >
> > > Comments?
> > >
> > > Cheers,
> > >
> > >   Albert
>
>

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

[Ingo Klöcker]

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-external-libraries):

* 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=


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 
> > 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


signature.asc
Description: This is a digitally signed message part.

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

[Luigi Toscano]

Scarlett Clark ha scritto:
> Resent - meant for list.
> Help please folks, I need someone with more knowledge with gcc and compiler
> flags / settings.

In the meantime, could you please reenable ASAN? I fixed few leaks in
kdoctools itself (my fault, right), so I'd like to see if there are real leaks
in libxml2/libxslt.
But right now the build fails because ASAN is disabled.

Ciao
-- 
Luigi

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

[Albert Astals Cid]

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-exte
> rnal-libraries):

This are not AddressSanitizer warnings, they are LeakSanitizer warnings.

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=
> 
> 
> 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 
> > > 
> > > 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


signature.asc
Description: This is a digitally signed message part.

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

[Albert Astals Cid]

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=
> > 
> > 
> > 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 
> > > > 
> > > > 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


signature.asc
Description: This is a digitally signed message part.

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

[Milian Wolff]

On Montag, 28. September 2015 23:10:33 CEST Albert Astals Cid wrote:
> El Dilluns, 28 de setembre de 2015, a les 16:41:58, Milian Wolff va 
escriure:
> > On Friday, September 25, 2015 11:35:35 PM CEST Albert Astals Cid wrote:
> > > El Divendres, 25 de setembre de 2015, a les 05:15:35, Milian Wolff va
> > > 
> > > escriure:
> > > > On Montag, 21. September 2015 20:29:32 CEST Albert Astals Cid wrote:
> > > > > El Dijous, 10 de setembre de 2015, a les 22:36:10, Albert Astals Cid
> > > > > va
> > > > 
> > > > escriure:
> > > > > > We have this nice ECM module that gives us the option to compile
> > > > > > with
> > > > > > ASAN.
> > > > > > 
> > > > > > I'd like to propose that we enable it by default in jenkins.
> > > > > > 
> > > > > > This way we get all the autotests run with ASAN and potentially
> > > > > > catch
> > > > > > more
> > > > > > bugs/regressions.
> > > > > > 
> > > > > > Comments?
> > > > > 
> > > > > This has now been commited.
> > > > > 
> > > > > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=commit
> > > > > 
> > > > > =5
> > > > > e4
> > > > > f2 e673c902e9d3b09aeffe56c20838918c681
> > > > > 
> > > > > Watch out for tests failing, let's hope it doesn't find anything bad
> > > > > 
> > > > > :D
> > > > 
> > > > \o/
> > > > 
> > > > Thanks for taking the initiative here, Albert! Much appreciated!
> > > > 
> > > > Also, did you think of additionally enabling UBSan where available? It
> > > > can
> > > > be combined with ASan and should thus find even more issues in our
> > > > codebase!
> > > 
> > > I've never tried the undefined sanitizer so can't comment on how
> > > "correct"
> > > or "pedantic" its checks are.
> > > 
> > > Have you? What's your opinion on it?
> > 
> > Yes, it works nicely for the simple examples I've tried, see also:
> > 
> > http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitize
> > r-> ubsan/> 
> > > Also it seems it doesn't really crash(stop the app like asan does, so it
> > > would not be of much use unless someone spends lots of time parsing the
> > > tests logs, no?
> > 
> > It could either be scripted, or we can try to pass -fno-sanitize-recover,
> > which should make it crash instantly on the first error (indeed, it does
> > in
> > my test).
> 
> Have you compiled some frameworks with those flags on? Are we confident it
> won't blow up in a red-festival?

No.

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.

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

[Milian Wolff]

On Friday, September 25, 2015 11:35:35 PM CEST Albert Astals Cid wrote:
> El Divendres, 25 de setembre de 2015, a les 05:15:35, Milian Wolff va
> 
> escriure:
> > On Montag, 21. September 2015 20:29:32 CEST Albert Astals Cid wrote:
> > > El Dijous, 10 de setembre de 2015, a les 22:36:10, Albert Astals Cid va
> > 
> > escriure:
> > > > We have this nice ECM module that gives us the option to compile with
> > > > ASAN.
> > > > 
> > > > I'd like to propose that we enable it by default in jenkins.
> > > > 
> > > > This way we get all the autotests run with ASAN and potentially catch
> > > > more
> > > > bugs/regressions.
> > > > 
> > > > Comments?
> > > 
> > > This has now been commited.
> > > 
> > > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=commit=5
> > > e4
> > > f2 e673c902e9d3b09aeffe56c20838918c681
> > > 
> > > Watch out for tests failing, let's hope it doesn't find anything bad :D
> > 
> > \o/
> > 
> > Thanks for taking the initiative here, Albert! Much appreciated!
> > 
> > Also, did you think of additionally enabling UBSan where available? It can
> > be combined with ASan and should thus find even more issues in our
> > codebase!
> 
> I've never tried the undefined sanitizer so can't comment on how "correct"
> or "pedantic" its checks are.
> 
> Have you? What's your opinion on it?

Yes, it works nicely for the simple examples I've tried, see also:

http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-ubsan/

> Also it seems it doesn't really crash(stop the app like asan does, so it
> would not be of much use unless someone spends lots of time parsing the
> tests logs, no?

It could either be scripted, or we can try to pass -fno-sanitize-recover, 
which should make it crash instantly on the first error (indeed, it does in my 
test).

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

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

[Albert Astals Cid]

El Dilluns, 28 de setembre de 2015, a les 16:41:58, Milian Wolff va escriure:
> On Friday, September 25, 2015 11:35:35 PM CEST Albert Astals Cid wrote:
> > El Divendres, 25 de setembre de 2015, a les 05:15:35, Milian Wolff va
> > 
> > escriure:
> > > On Montag, 21. September 2015 20:29:32 CEST Albert Astals Cid wrote:
> > > > El Dijous, 10 de setembre de 2015, a les 22:36:10, Albert Astals Cid
> > > > va
> > > 
> > > escriure:
> > > > > We have this nice ECM module that gives us the option to compile
> > > > > with
> > > > > ASAN.
> > > > > 
> > > > > I'd like to propose that we enable it by default in jenkins.
> > > > > 
> > > > > This way we get all the autotests run with ASAN and potentially
> > > > > catch
> > > > > more
> > > > > bugs/regressions.
> > > > > 
> > > > > Comments?
> > > > 
> > > > This has now been commited.
> > > > 
> > > > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=commit
> > > > =5
> > > > e4
> > > > f2 e673c902e9d3b09aeffe56c20838918c681
> > > > 
> > > > Watch out for tests failing, let's hope it doesn't find anything bad
> > > > :D
> > > 
> > > \o/
> > > 
> > > Thanks for taking the initiative here, Albert! Much appreciated!
> > > 
> > > Also, did you think of additionally enabling UBSan where available? It
> > > can
> > > be combined with ASan and should thus find even more issues in our
> > > codebase!
> > 
> > I've never tried the undefined sanitizer so can't comment on how "correct"
> > or "pedantic" its checks are.
> > 
> > Have you? What's your opinion on it?
> 
> Yes, it works nicely for the simple examples I've tried, see also:
> 
> http://developerblog.redhat.com/2014/10/16/gcc-undefined-behavior-sanitizer-> 
> ubsan/
> > Also it seems it doesn't really crash(stop the app like asan does, so it
> > would not be of much use unless someone spends lots of time parsing the
> > tests logs, no?
> 
> It could either be scripted, or we can try to pass -fno-sanitize-recover,
> which should make it crash instantly on the first error (indeed, it does in
> my test).

Have you compiled some frameworks with those flags on? Are we confident it 
won't blow up in a red-festival?

Cheers,
  Albert

> 
> Bye

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

[Albert Astals Cid]

El Divendres, 25 de setembre de 2015, a les 05:15:35, Milian Wolff va 
escriure:
> On Montag, 21. September 2015 20:29:32 CEST Albert Astals Cid wrote:
> > El Dijous, 10 de setembre de 2015, a les 22:36:10, Albert Astals Cid va
> 
> escriure:
> > > We have this nice ECM module that gives us the option to compile with
> > > ASAN.
> > > 
> > > I'd like to propose that we enable it by default in jenkins.
> > > 
> > > This way we get all the autotests run with ASAN and potentially catch
> > > more
> > > bugs/regressions.
> > > 
> > > Comments?
> > 
> > This has now been commited.
> > 
> > https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=commit=5e4
> > f2 e673c902e9d3b09aeffe56c20838918c681
> > 
> > Watch out for tests failing, let's hope it doesn't find anything bad :D
> 
> \o/
> 
> Thanks for taking the initiative here, Albert! Much appreciated!
> 
> Also, did you think of additionally enabling UBSan where available? It can
> be combined with ASan and should thus find even more issues in our
> codebase!

I've never tried the undefined sanitizer so can't comment on how "correct" or 
"pedantic" its checks are.

Have you? What's your opinion on it?

Also it seems it doesn't really crash(stop the app like asan does, so it would 
not be of much use unless someone spends lots of time parsing the tests logs, 
no?

Cheers,
  Albert

> 
> Bye


signature.asc
Description: This is a digitally signed message part.

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

[Milian Wolff]

On Montag, 21. September 2015 20:29:32 CEST Albert Astals Cid wrote:
> El Dijous, 10 de setembre de 2015, a les 22:36:10, Albert Astals Cid va 
escriure:
> > We have this nice ECM module that gives us the option to compile with
> > ASAN.
> > 
> > I'd like to propose that we enable it by default in jenkins.
> > 
> > This way we get all the autotests run with ASAN and potentially catch more
> > bugs/regressions.
> > 
> > Comments?
> 
> This has now been commited.
> 
> https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=commit=5e4f2
> e673c902e9d3b09aeffe56c20838918c681
> 
> Watch out for tests failing, let's hope it doesn't find anything bad :D

\o/

Thanks for taking the initiative here, Albert! Much appreciated!

Also, did you think of additionally enabling UBSan where available? It can be 
combined with ASan and should thus find even more issues in our codebase!

Bye
-- 
Milian Wolff
m...@milianw.de
http://milianw.de

signature.asc
Description: This is a digitally signed message part.

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

[Albert Astals Cid]

El Dijous, 10 de setembre de 2015, a les 22:36:10, Albert Astals Cid va 
escriure:
> We have this nice ECM module that gives us the option to compile with ASAN.
> 
> I'd like to propose that we enable it by default in jenkins.
> 
> This way we get all the autotests run with ASAN and potentially catch more
> bugs/regressions.
> 
> Comments?

This has now been commited.

https://quickgit.kde.org/?p=sysadmin%2Fci-builder-tools.git=commit=5e4f2e673c902e9d3b09aeffe56c20838918c681

Watch out for tests failing, let's hope it doesn't find anything bad :D

Cheers,
  Albert

> 
> Cheers,
>   Albert

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

[André Wöbbeking]

On Thursday 10 September 2015 22:36:10 Albert Astals Cid wrote:
> We have this nice ECM module that gives us the option to compile with ASAN.
> 
> I'd like to propose that we enable it by default in jenkins.
> 
> This way we get all the autotests run with ASAN and potentially catch more
> bugs/regressions.
> 
> Comments?

+1

For code using STL the define _GLIBCXX_DEBUG for GCC is helpful too (but it 
slows down run time so it's maybe for something like nightly builds).


Cheers,
André

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

[Kevin Funk]

On Thursday, September 10, 2015 10:36:10 PM Albert Astals Cid wrote:
> We have this nice ECM module that gives us the option to compile with ASAN.
> 
> I'd like to propose that we enable it by default in jenkins.
> 
> This way we get all the autotests run with ASAN and potentially catch more
> bugs/regressions.
> 
> Comments?
> 
> Cheers,
>   Albert

Sounds good to me. We should try it out.

Worth the slowdown of the ASAN-enabled programs on the CI.

Cheers

-- 
Kevin Funk | kf...@kde.org | http://kfunk.org

signature.asc
Description: This is a digitally signed message part.

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

[Volker Krause]

On Thursday 10 September 2015 22:36:10 Albert Astals Cid wrote:
> We have this nice ECM module that gives us the option to compile with ASAN.
> 
> I'd like to propose that we enable it by default in jenkins.
> 
> This way we get all the autotests run with ASAN and potentially catch more
> bugs/regressions.
> 
> Comments?

Good idea, definitely worth trying IMHO. There were a few test issues in pim 
code recently where this would have been useful.

regards,
Volker

signature.asc
Description: This is a digitally signed message part.

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

[Albert Astals Cid]

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).

Cheers,
  Albert

> I had this problem when I used it
> with a program I develop at my work. Enabling it for all programs at once
> and fixing all those upstream bugs can be overwhelming. Maybe we should do
> it for a limited number of programs first and add more programs as we fix
> the errors.
> 
> Lamarque V. Souza
> 
> http://planetkde.org/pt-br
> 
> On Thu, Sep 10, 2015 at 5:36 PM, Albert Astals Cid  wrote:
> > We have this nice ECM module that gives us the option to compile with
> > ASAN.
> > 
> > I'd like to propose that we enable it by default in jenkins.
> > 
> > This way we get all the autotests run with ASAN and potentially catch more
> > bugs/regressions.
> > 
> > Comments?
> > 
> > Cheers,
> > 
> >   Albert

RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins

[Albert Astals Cid]

We have this nice ECM module that gives us the option to compile with ASAN.

I'd like to propose that we enable it by default in jenkins.

This way we get all the autotests run with ASAN and potentially catch more 
bugs/regressions.

Comments?

Cheers,
  Albert

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

[Lamarque Souza]

I agree but there is a problem: it can catch a lot of errors in our
dependency libraries (upstream bugs). I had this problem when I used it
with a program I develop at my work. Enabling it for all programs at once
and fixing all those upstream bugs can be overwhelming. Maybe we should do
it for a limited number of programs first and add more programs as we fix
the errors.

Lamarque V. Souza

http://planetkde.org/pt-br

On Thu, Sep 10, 2015 at 5:36 PM, Albert Astals Cid  wrote:

> We have this nice ECM module that gives us the option to compile with ASAN.
>
> I'd like to propose that we enable it by default in jenkins.
>
> This way we get all the autotests run with ASAN and potentially catch more
> bugs/regressions.
>
> Comments?
>
> Cheers,
>   Albert
>