Hi,
Am 04.07.2017 um 22:35 schrieb Willy Tarreau: > > This one should theorically not be caused by an issue in the task scheduler, > unless we're reusing something already freed. We could retry it with -dM > and/or -DDEBUG_MEMORY to force earlier corruption to pop up. The call trace doesn't really look different when I used -dM or -DDEBUG_MEMORY. I was able to get a different trace by actually connecting to a backend however, (instead of showing an haproxy internal 403 error): (gdb) bt #0 0x00007ffff7179428 in __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:54 #1 0x00007ffff717b02a in __GI_abort () at abort.c:89 #2 0x00007ffff71bb7ea in __libc_message (do_abort=2, fmt=fmt@entry=0x7ffff72d4e98 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x00007ffff71c2913 in malloc_printerr (ar_ptr=0x7ffff7508b20 <main_arena>, ptr=0xa83220, str=0x7ffff72d1c35 "corrupted size vs. prev_size", action=<optimized out>) at malloc.c:5006 #4 malloc_consolidate (av=av@entry=0x7ffff7508b20 <main_arena>) at malloc.c:4175 #5 0x00007ffff71c5cde in _int_malloc (av=av@entry=0x7ffff7508b20 <main_arena>, bytes=bytes@entry=4448) at malloc.c:3450 #6 0x00007ffff71c8184 in __GI___libc_malloc (bytes=4448) at malloc.c:2913 #7 0x00000000005d658e in CRYPTO_zalloc () #8 0x0000000000536172 in SSL_new () #9 0x000000000041143a in ssl_sock_init (conn=0xa3f9a0) at src/ssl_sock.c:4515 #10 0x00000000004fcc58 in conn_xprt_init (conn=0xa3f9a0) at include/proto/connection.h:79 #11 0x00000000004fde02 in session_accept_fd (l=0xa432f0, cfd=5, addr=0x7fffffffe320) at src/session.c:152 #12 0x00000000004e44c6 in listener_accept (fd=4) at src/listener.c:493 #13 0x00000000005116a2 in fd_process_cached_events () at src/fd.c:240 #14 0x00000000004d4a75 in run_poll_loop () at src/haproxy.c:2186 #15 0x00000000004d5d67 in main (argc=7, argv=0x7fffffffe638) at src/haproxy.c:2701 (gdb)
