Hi Olivier, On Thu, May 14, 2020 at 04:24:53PM +0200, Olivier D wrote: > Hello, > > I'm spamming a lot these days :) > > I found a strange coredump on HAProxy 2.0.14 that started a few days ago > for no reason. It's not a coredump but a raise().
Note that if your cores are enabled you ought to get one on raise(). > Stacktrace : > > #0 0x00007fde8c9f8495 in raise () from /lib64/libc.so.6 > #1 0x00007fde8c9f9c75 in abort () from /lib64/libc.so.6 > #2 0x00007fde8ca363a7 in __libc_message () from /lib64/libc.so.6 > #3 0x00007fde8ca3bdee in malloc_printerr () from /lib64/libc.so.6 > #4 0x00007fde8ca3ec3d in _int_free () from /lib64/libc.so.6 > #5 0x000000000047a885 in ssl_sock_free_ssl_conf () at src/ssl_sock.c:3740 > #6 0x000000000047bdd2 in ssl_sock_free_all_ctx () at src/ssl_sock.c:5063 > #7 0x000000000047c301 in ssl_sock_destroy_bind_conf () at > src/ssl_sock.c:5095 > #8 0x000000000050c8fb in deinit () at src/haproxy.c:2533 > #9 0x000000000050dc3f in main () at src/haproxy.c:3449 This seriously looks like a double free or a free of an invalid pointer. > This seems to happen when issuing the following command : > 'set ssl ocsp-response xxx' |socat stdio /var/run/haproxy.sock Is it 100% reproducible and if so can you please share a minimal config and reproducer so that we can quickly focus on it ? > This is the first time I see such a behaviour :/ > > I can provide a "bt full" output privately if needed. It could help if not reproduced, but let's first see if there's a way to reproduce it. The SSL setup/release code is extremely complex due to non-atomic setup that requires to be released on error, and it's very possible that we have a double free there, possibly caused by a missing assignment of a pointer to NULL after freeing it. Thanks, Willy
