[EXTERNAL] - Re: Seeing intermittent crash for TLSv1.3

[Hubert Kario]

On Tuesday, 23 April 2024 15:51:34 CEST, Michael Wojcik via openssl-users 
wrote:
>> From: openssl-users <openssl-users-bounces at openssl.org> On Behalf Of
>> Hubert Kario
>> Sent: Tuesday, 23 April, 2024 02:05
>> 
>> Try using --malloc-fill=af --free-fill=fa ?
>> (or some other non-zero values)
>
> Or on a glibc platform (which I'm assuming Rahul's original 
> message referred to, as that looked like a gdb backtrace), 
> enabling libc_malloc_debug with LD_PRELOAD and setting 
> MALLOC_CHECK_ or the equivalent glibc tunable. In my experience 
> it can be a bit of work getting glibc malloc debugging working, 
> and Valgrind is usually a better option; but if, as Rahul 
> reported, valgrind is not diagnosing the issue, glibc malloc 
> debugging is another possible route.
>
> That said, it's not entirely clear to me whether Rahul 
> exhausted the valgrind option, since in the previous message he 
> wrote that "we are not able to see this crash when we are 
> running our debug modules with Purify or Valgrind". I'd suggest 
> running the precise problem scenario — same build, same 
> reproduction sequence — under valgrind (memcheck), and then go 
> through the valgrind output, starting with the post-termination 
> report. If valgrind doesn't identify a problem with the debug 
> build, try it with the release build.

I proposed use of those two options because I personally had exact same
situation (not with OpenSSL, but with a C application still):
valgrind was content and application was running fine, but when running
without valgrind the application would segfault.
To make it segfault in valgrind those two options were necessary, then
it was crashing reliably under valgrind too.
-- 
Regards,
Hubert Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic