On Tuesday, 23 April 2024 15:51:34 CEST, Michael Wojcik via openssl-users
wrote:
From: openssl-users <openssl-users-bounces@xxxxxxxxxxx> 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
