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

Reply via email to