Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Dr Paul Dale
An alternative would be to only run a cut down selection of tests with msan.


Pauli
-- 
Dr Paul Dale | Distinguished Architect | Cryptographic Foundations 
Phone +61 7 3031 7217
Oracle Australia




> On 14 Feb 2020, at 11:00 pm, Matt Caswell  wrote:
> 
> 
> 
> On 14/02/2020 12:23, Nicola Tuveri wrote:
>> If ASAN is too slow to run in the CI should we restore the previous
>> homemade checks for memory leaks as an alternative to be run in regular
>> CI runs and leave ASAN builds to run-checker on the master branch only? 
> 
> To be clear the build that is timing out uses *msan* not *asan*.
> 
> As I understand it msan detects unitialised reads. whereas asan detects
> memory corruption, buffer overflows, use-after-free bugs, and memory leaks.
> 
> The previous "home-made" checks only detected memory leaks, so it is not
> comparable with the functionality offered by msan.
> 
> The msan documentation
> (https://urldefense.com/v3/__https://clang.llvm.org/docs/MemorySanitizer.html__;!!GqivPVa7Brio!JwD52xjNRP5yVXTD3K12Mn17HiC2xHM_O6YzFE7G32G1BYh-NID9mIM6xiEvnC0$
>  ) suggests that a slow
> down of 3x is typical.
> 
> It seems reasonable to me to disable msan checks in Travis entirely, and
> have them only in run-checker.
> 
>> 
>> Here is another idea that would be interesting if we restore the
>> previous checks:
>> I don't know what kind of options github offers on this, but would it be
>> possible to run triggered CI on something that is not Travis and does
>> not timeout and still have the results in the PR?
> 
> I am sure there are hooks to do this. Richard has been talking for quite
> a while about setting up a buildbot infrastructure. If that could be
> integrated into github that would be really neat.
> 
> Matt
> 
> 
>> If something like that would be possible we could move the ASAN builds
>> to extended_tests, rely on the previous memleak detection for the
>> regular CI runs, and then trigger with a script or Github Action the
>> extended_tests when the approval:done label is added. 
>> 
>> That way, by the time something is ready to be merged we should have a
>> full picture! 
>> 
>> 
>> Nicola
>> 
>> On Wed, Feb 5, 2020, 10:25 Matt Caswell > > wrote:
>> 
>>Since we fixed the Travis builds 4 out of the 8 builds on master that
>>have taken place have errored due to a timeout.
>> 
>>The msan build is consistently taking a *very* long time to run. If it
>>gets to 50 minutes then Travis cuts it off and the build fails.
>> 
>>Should we disable the msan build?
>> 
>>Matt
>> 
>> 
>> Forwarded Message 
>>Subject:Errored: openssl/openssl#31939 (master - 34b1676)
>>Date:   Wed, 05 Feb 2020 00:02:01 +
>>From:   Travis CI mailto:bui...@travis-ci.org>>
>>To: openssl-comm...@openssl.org 
>> 
>> 
>> 
>>openssl
>> 
>>/
>> 
>>openssl
>> 
>>
>> >  >
>> 
>> 
>>branch iconmaster 
>> >  >
>> 
>>build has errored
>>Build #31939 has errored
>>
>> >  >
>>arrow to build time
>>clock icon50 mins and 3 secs
>> 
>>Pauli avatarPauli
>> 
>>34b1676 CHANGESET →
>>
>> >  >
>> 
>>Make minimum size for secure memory a size_t.
>> 
>>The minimum size argument to CRYPTO_secure_malloc_init() was an int but
>>ought
>>to be a size_t since it is a size.
>> 
>>From an API perspective, this is a change. However, the minimum size is
>>verified as being a positive power of two and it will typically be a
>>small
>>constant.
>> 
>>Reviewed-by: David von Oheimb >>
>>(Merged from #11003)
>> 
>>Want to know about upcoming build environment updates?
>> 
>>Would you like to stay up-to-date with the upcoming Travis CI build
>>environment updates? We set up a mailing list for you!
>> 
>>SIGN UP HERE 
>> >  >
>> 
>>book icon
>> 
>>Documentation 
>> >  > about Travis CI
>> 
>>

Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
On Fri, 14 Feb 2020 at 14:00, Matt Caswell  wrote:

>
> To be clear the build that is timing out uses *msan* not *asan*.


>
As I understand it msan detects unitialised reads. whereas asan detects
> memory corruption, buffer overflows, use-after-free bugs, and memory leaks.
>
> The previous "home-made" checks only detected memory leaks, so it is not
> comparable with the functionality offered by msan.
>
>
Thanks for the clarification! I was indeed confused!



> The msan documentation
> (https://clang.llvm.org/docs/MemorySanitizer.html) suggests that a slow
> down of 3x is typical.
>
> It seems reasonable to me to disable msan checks in Travis entirely, and
> have them only in run-checker.
>
>
I agree with you.


> > Here is another idea that would be interesting if we restore the
> > previous checks:
> > I don't know what kind of options github offers on this, but would it be
> > possible to run triggered CI on something that is not Travis and does
> > not timeout and still have the results in the PR?
>
> I am sure there are hooks to do this. Richard has been talking for quite
> a while about setting up a buildbot infrastructure. If that could be
> integrated into github that would be really neat.
>
>
It would be neat indeed, when I first heard about buildbot I tried to set
aside some time to play with it, but failed in finding the time needed!
But at least from what I read it does indeed seem like a very interesting
and useful tool for our purposes!

I have no doubt sooner or later Richard will be more successful than I was
at finding the time to work on this item as well!

Nicola


Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Matt Caswell



On 14/02/2020 12:23, Nicola Tuveri wrote:
> If ASAN is too slow to run in the CI should we restore the previous
> homemade checks for memory leaks as an alternative to be run in regular
> CI runs and leave ASAN builds to run-checker on the master branch only? 

To be clear the build that is timing out uses *msan* not *asan*.

As I understand it msan detects unitialised reads. whereas asan detects
memory corruption, buffer overflows, use-after-free bugs, and memory leaks.

The previous "home-made" checks only detected memory leaks, so it is not
comparable with the functionality offered by msan.

The msan documentation
(https://clang.llvm.org/docs/MemorySanitizer.html) suggests that a slow
down of 3x is typical.

It seems reasonable to me to disable msan checks in Travis entirely, and
have them only in run-checker.

> 
> Here is another idea that would be interesting if we restore the
> previous checks:
> I don't know what kind of options github offers on this, but would it be
> possible to run triggered CI on something that is not Travis and does
> not timeout and still have the results in the PR?

I am sure there are hooks to do this. Richard has been talking for quite
a while about setting up a buildbot infrastructure. If that could be
integrated into github that would be really neat.

Matt


> If something like that would be possible we could move the ASAN builds
> to extended_tests, rely on the previous memleak detection for the
> regular CI runs, and then trigger with a script or Github Action the
> extended_tests when the approval:done label is added. 
> 
> That way, by the time something is ready to be merged we should have a
> full picture! 
> 
> 
> Nicola
> 
> On Wed, Feb 5, 2020, 10:25 Matt Caswell  > wrote:
> 
> Since we fixed the Travis builds 4 out of the 8 builds on master that
> have taken place have errored due to a timeout.
> 
> The msan build is consistently taking a *very* long time to run. If it
> gets to 50 minutes then Travis cuts it off and the build fails.
> 
> Should we disable the msan build?
> 
> Matt
> 
> 
>  Forwarded Message 
> Subject:        Errored: openssl/openssl#31939 (master - 34b1676)
> Date:   Wed, 05 Feb 2020 00:02:01 +
> From:   Travis CI mailto:bui...@travis-ci.org>>
> To:     openssl-comm...@openssl.org 
> 
> 
> 
> openssl
> 
> /
> 
> openssl
> 
> 
> 
> 
> 
> branch iconmaster 
> 
> build has errored
> Build #31939 has errored
> 
> 
> arrow to build time
> clock icon50 mins and 3 secs
> 
> Pauli avatarPauli
> 
> 34b1676 CHANGESET →
> 
> 
> Make minimum size for secure memory a size_t.
> 
> The minimum size argument to CRYPTO_secure_malloc_init() was an int but
> ought
> to be a size_t since it is a size.
> 
> From an API perspective, this is a change. However, the minimum size is
> verified as being a positive power of two and it will typically be a
> small
> constant.
> 
> Reviewed-by: David von Oheimb  >
> (Merged from #11003)
> 
> Want to know about upcoming build environment updates?
> 
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you!
> 
> SIGN UP HERE 
> 
> book icon
> 
> Documentation  about Travis CI
> 
> Have any questions? We're here to help.
> >
> Unsubscribe
> 
> 
> from build emails from the openssl/openssl repository.
> To unsubscribe from *all* build emails, please update your settings
> 
> .
> 
> black and white travis ci logo 
> 
> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: cont...@travis-ci.com
>   > |
> Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß
> §27 a Umsatzsteuergesetz: DE282002648
> 


Re: Errored: openssl/openssl#31939 (master - 34b1676)

2020-02-14 Thread Nicola Tuveri
If ASAN is too slow to run in the CI should we restore the previous
homemade checks for memory leaks as an alternative to be run in regular CI
runs and leave ASAN builds to run-checker on the master branch only?

Here is another idea that would be interesting if we restore the previous
checks:
I don't know what kind of options github offers on this, but would it be
possible to run triggered CI on something that is not Travis and does not
timeout and still have the results in the PR?
If something like that would be possible we could move the ASAN builds to
extended_tests, rely on the previous memleak detection for the regular CI
runs, and then trigger with a script or Github Action the extended_tests
when the approval:done label is added.

That way, by the time something is ready to be merged we should have a full
picture!


Nicola

On Wed, Feb 5, 2020, 10:25 Matt Caswell  wrote:

> Since we fixed the Travis builds 4 out of the 8 builds on master that
> have taken place have errored due to a timeout.
>
> The msan build is consistently taking a *very* long time to run. If it
> gets to 50 minutes then Travis cuts it off and the build fails.
>
> Should we disable the msan build?
>
> Matt
>
>
>  Forwarded Message 
> Subject:Errored: openssl/openssl#31939 (master - 34b1676)
> Date:   Wed, 05 Feb 2020 00:02:01 +
> From:   Travis CI 
> To: openssl-comm...@openssl.org
>
>
>
> openssl
>
> /
>
> openssl
>
> <
> https://travis-ci.org/openssl/openssl?utm_medium=notification_source=email
> >
>
>
> branch iconmaster 
>
> build has errored
> Build #31939 has errored
> <
> https://travis-ci.org/openssl/openssl/builds/646181069?utm_medium=notification_source=email
> >
> arrow to build time
> clock icon50 mins and 3 secs
>
> Pauli avatarPauli
>
> 34b1676 CHANGESET →
> 
>
> Make minimum size for secure memory a size_t.
>
> The minimum size argument to CRYPTO_secure_malloc_init() was an int but
> ought
> to be a size_t since it is a size.
>
> From an API perspective, this is a change. However, the minimum size is
> verified as being a positive power of two and it will typically be a small
> constant.
>
> Reviewed-by: David von Oheimb 
> (Merged from #11003)
>
> Want to know about upcoming build environment updates?
>
> Would you like to stay up-to-date with the upcoming Travis CI build
> environment updates? We set up a mailing list for you!
>
> SIGN UP HERE 
>
> book icon
>
> Documentation  about Travis CI
>
> Have any questions? We're here to help. 
> Unsubscribe
> <
> https://travis-ci.org/account/preferences/unsubscribe?repository=5849220_medium=notification_source=email
> >
> from build emails from the openssl/openssl repository.
> To unsubscribe from *all* build emails, please update your settings
> <
> https://travis-ci.org/account/preferences/unsubscribe?utm_medium=notification_source=email
> >.
>
> black and white travis ci logo 
>
> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: cont...@travis-ci.com  |
> Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß
> §27 a Umsatzsteuergesetz: DE282002648
>
>