Hi William, On Wed, Apr 10, 2019 at 06:00:28PM +0000, William Dauchy wrote: > Hello, > > We are seeing a quite regular segfault when haproxy v1.9 joins our cluster > and almost immediately crash with: > > #0 0x000055b66f75c825 in do_unbind_listener > (listener=listener@entry=0x55b67206dcb0, do_close=do_close@entry=1) at > src/listener.c:328 > 328 LIST_DEL(&listener->wait_queue); > #1 0x000055b66f75cf02 in unbind_listener > (listener=listener@entry=0x55b67206dcb0) at src/listener.c:351 > #2 0x000055b66f75cfb8 in unbind_all_listeners (proto=0x55b66fa16300 > <proto_tcpv6>) at src/listener.c:374 > #3 0x000055b66f7a2e7e in protocol_unbind_all () at src/protocol.c:76 > #4 0x000055b66f6ff5d0 in deinit () at src/haproxy.c:2548 > #5 0x000055b66f67732d in main (argc=<optimized out>, argv=0x7ffe16c546b8) at > src/haproxy.c:3366 > > The code in mainline has changed since commit > http://git.haproxy.org/?p=haproxy.git;a=commit;h=01abd025084b4fe50e84189d1a83499cbf4825ed > which stated "This patch must carefully be backported to 1.9" > > Do you have any status about it?
Unfortunately this one looks different. It dies when it is stopping (see deinit, unbind*, ...), are you sure it's not the previous process when you're performing a reload ? Note that it *could* possibly still be the same, but I find it strange that it only dies on exit and that surprisingly the process quits with saturated listeners. With this said, we've got no negative feedback on the patch above after one month and a half, which likely is a good indication that we should now backport it (carefully as mentionned in the commit message). Thanks, Willy
