Errored: openssl/openssl#31939 (master - 34b1676)
matt at openssl.org
Fri Feb 14 13:00:34 UTC 2020
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.
> 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!
> On Wed, Feb 5, 2020, 10:25 Matt Caswell <matt at openssl.org
> <mailto:matt at openssl.org>> 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?
> -------- Forwarded Message --------
> Subject: Errored: openssl/openssl#31939 (master - 34b1676)
> Date: Wed, 05 Feb 2020 00:02:01 +0000
> From: Travis CI <builds at travis-ci.org <mailto:builds at travis-ci.org>>
> To: openssl-commits at openssl.org <mailto:openssl-commits at openssl.org>
> branch iconmaster <https://github.com/openssl/openssl/tree/master>
> 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
> 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
> Reviewed-by: David von Oheimb <david.von.oheimb at siemens.com
> <mailto:david.von.oheimb at siemens.com>>
> (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 <http://eepurl.com/9OCsP>
> book icon
> Documentation <https://docs.travis-ci.com/> about Travis CI
> Have any questions? We're here to help.
> <mailto:support at travis-ci.com <mailto:support at travis-ci.com>>
> from build emails from the openssl/openssl repository.
> To unsubscribe from *all* build emails, please update your settings
> black and white travis ci logo <https://travis-ci.com>
> Travis CI GmbH, Rigaer Str. 8, 10427 Berlin, Germany | GF/CEO: Randy
> Jacops | Contact: contact at travis-ci.com
> <mailto:contact at travis-ci.com> <mailto:contact at travis-ci.com
> <mailto:contact at travis-ci.com>> |
> Amtsgericht Charlottenburg, Berlin, HRB 140133 B | Umsatzsteuer-ID gemäß
> §27 a Umsatzsteuergesetz: DE282002648
More information about the openssl-project