Re: Build failures on master?!

[Benjamin Kaduk]

On Mon, Nov 18, 2019 at 10:12:52PM +, Matt Caswell wrote:
> 
> 
> On 18/11/2019 21:48, Dr. Matthias St. Pierre wrote:
> > The last 19 commits on https://github.com/openssl/openssl/commits/master,
> > starting from Nov 14 have a red cross from the CIs. What's going on again?
> > My personal impression is that builds on master are failing 50% of the time.
> 
> The builds on master have been failing for *much* longer than that. They
> should be succeeded on the PRs, but its the extended tests that fail.
> 
> > 
> > It is really tedious to check pull requests for build errors just to find 
> > that those errors
> > are well known failures from master. In particular, the krb5 an pyca tests 
> > are notoriously
> > failing. Are there any plans to fix them or disable them?
> 
> The build failures mostly come from the external tests (or that was the
> case I haven't checked recently). The problem with these is that, on
> occasion we need the maintainers of these packages to help us track down
> a problem. Or in some cases we actually need them to make a change (for
> example because something changed on master which revealed that they
> were relying on some behaviour in master which they really shouldn't be
> relying on).
> 
> Once one of them is failing then multiple errors can build up and they
> get masked by the earlier failure.
> 
> I'll try and find some time to take another pass at the current
> failures. I suspect the answer might be to disable some of the external
> tests.

Please let me know if you want me to look at the krb5 tests (or pester
folks at upstream there to do so).  I'm in Singapore for the IETF this week
and have been behind on, well, everything.

-Ben

Re: Malloc failures check

[Dmitry Belyavsky]

Unfortunately, it is not a compile-time check...

I mean smth like
https://github.com/openssl/openssl/blob/ab5c77b4766e0992751d86560193ca42b49cf316/include/openssl/e_os2.h#L198-L202
but not sure it is applicable to external functions...

On Thu, Nov 21, 2019 at 1:42 PM Salz, Rich  wrote:

>
>- It would be possible to implement a malloc failure feature in the
>test suite that systematically runs a test many times, failing successive
>malloc calls.
>
>
>
> It’s there; look crypto/mem.c, shouldfail() and FAILTEST.
>
>
>
> More detail, from off-list discusson:
>
>
>
> i=0
>
> while : ; do
>
>((i++))
>
>export MALLOC_FAILURE_CHECKS=${i}@100 openssl foo etc…
>
>test -f core && echo crashed && exit 1
>
>  done
>
>
>
>
>


-- 
SY, Dmitry Belyavsky

Re: Malloc failures check

[Salz, Rich]

  *   It would be possible to implement a malloc failure feature in the test 
suite that systematically runs a test many times, failing successive malloc 
calls.

It’s there; look crypto/mem.c, shouldfail() and FAILTEST.

More detail, from off-list discusson:

i=0
while : ; do
   ((i++))
   export MALLOC_FAILURE_CHECKS=${i}@100 openssl foo etc…
   test -f core && echo crashed && exit 1
 done

Re: Malloc failures check

[Salz, Rich]

  *   It would be possible to implement a malloc failure feature in the test 
suite that systematically runs a test many times, failing successive malloc 
calls.

It’s there; look crypto/mem.c, shouldfail() and FAILTEST.