Hi, Willy! If it could be interesting, I got a new core with exactly the same backtrace: Program terminated with signal SIGSEGV, Segmentation fault. #0 0x0000563f5373bf21 in __pendconn_free (p=0x563f560db0c8) at src/queue.c:296 296 HA_ATOMIC_SUB(&p->strm->be->nbpend, 1); (gdb) bt #0 0x0000563f5373bf21 in __pendconn_free (p=0x563f560db0c8) at src/queue.c:296 #1 0x0000563f5373c1de in pendconn_get_next_strm (px=0x563f560da290, srv=0x563f560df380) at src/queue.c:122 #2 process_srv_queue (s=0x563f560df380) at src/queue.c:153 #3 0x0000563f536bf192 in sess_update_st_cer (s=s@entry=0x7f42841d2f60) at src/stream.c:742 #4 0x0000563f536c356d in process_stream (t=0x7f42841d32c0) at src/stream.c:1783 #5 0x0000563f5373baa8 in process_runnable_tasks () at src/task.c:311 #6 0x0000563f536f0c84 in run_poll_loop () at src/haproxy.c:2398 #7 run_thread_poll_loop (data=<optimized out>) at src/haproxy.c:2460 #8 0x00007f42af227184 in start_thread () from /lib/x86_64-linux-gnu/libpthread.so.0 #9 0x00007f42ae4a503d in clone () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) print p $9 = (struct pendconn *) 0x563f560db0c8 (gdb) print p->strm $10 = (struct stream *) 0x7f4385291f91 (gdb) print p->strm->uniq_id Cannot access memory at address 0x7f4385291f95
-- Best regards, Maksim Kupriianov 2018-03-05 19:35 GMT+03:00 Willy Tarreau <w...@1wt.eu>: > On Mon, Mar 05, 2018 at 09:19:16PM +0500, ?????? ????????? wrote: > > Hi Willy! > > > > I have 2 more haproxy-servers with exactly the same configuration and > load. > > Both has threads compiled in but not enabled in config (no nbthreads). > And > > there're no segfaults at all. So I'm sure everything is fine without > > threads. > > Haproxy's config file itself is way too large to find out exact > > proxy-section where the fault occurred to tell you about configuration :( > > But if it could help: we have few heavy loaded proxy-sections with > hundred > > of servers inside, round-roubin algo and maxconn=2. Stick tables are > > enabled but only to calculate average characteristics of traffic and use > it > > in ACL so no real stickness on backends. > > I still have the core file available, so I can extract some more detailed > > traces if you need'em. > > OK thanks for these details, these are already quite valuable information. > Please don't lose the executable file that produced the core, in case we'd > need to dig deeper into it. > > Cheers, > Willy >
