Haproxy segfault - core dump analysis needed


#1

our haproxy 1.5.19 is crashing, usually when we’re having a large number of requests coming in. We’ve exhausted all our options to fix, so it’s time to dig in a bit deeper. So I’d like to attach gdb to our currently running process - but there’s three of them -

root 18700 1 0 10:07 ? 00:00:00 /usr/sbin/haproxy-systemd-wrapper -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid
root 29141 18700 0 11:42 ? 00:00:00 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 28244
root 29142 29141 15 11:42 ? 00:59:56 /usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg -p /run/haproxy.pid -Ds -sf 28244

So, not sure which one to attach, I’m guessing the last one, PID 29142, but would like to know for certain. Thanks!


#2

I suggest you let haproxy take a coredump instead of attaching gdb to a live process, so that you can analyze the coredump offline.

I’d stop haproxy completely via systemd, and then manually start it (don’t forget ulimit):

ulimit -c unlimited
/usr/sbin/haproxy -f /etc/haproxy/haproxy.cfg

Also it is probably useful to disable compiler optimizations, so that the stack traces makes sense. To do that, compile with CFLAGS="-O0 -g -fno-strict-aliasing", for example:

make clean; make TARGET=linux2628 CPU=generic USE_GETADDRINFO=1 \ USE_OPENSSL=1 USE_ZLIB=1 CFLAGS="-O0 -g -fno-strict-aliasing"