Le 29/06/2026 à 3:49 PM, Yaacov Akiba Slama a écrit :
Here is the backtrace. I think that hlua_process_task` and `cli_io_handler` are
misresolved (huge offsets), so the only reliable symbol in the chain is
`sc_conn_io_cb`.
Jun 28 05:33:56 server1 haproxy[3703705]: FATAL: bug condition "b_data(b) + len >
b_size(b)" matched at src/buf.c:318
Jun 28 05:33:56 server1 haproxy[3703705]: 65.52.160.255:26171 [28/Jun/2026:05:33:56.755]
http-in http-in/<NOSRV> 0/-1/-1/-1/+0 302 +0 - - LR-- 219/79/0/0/0 0/0 "GET
/edit-tags.php HTTP/1.1"
Jun 28 05:33:56 server1 haproxy[3703705]: call trace(13):
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc396e630 <b5 ee ff e8 50 8c ee
ff]: __b_putblk+0xd0/0xe8 > ha_backtrace_to_stderr
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc396e7a8 <89 4d f8 e8 b8 fd ff
ff]: b_xfer+0x158/0x194 > __b_putblk
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc36f5914 <89 4d c8 e8 3c 8d 27
00]: hlua_process_task+0x291c4 > b_xfer
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc3846908 <08 0f 29 45 90 ff
50 10]: cli_io_handler+0x3a318
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc384a917 <89 75 e8 e8 29 bb ff
ff]: sc_conn_io_cb+0x97/0xf2 > cli_io_handler+0x39e50
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc39319a7 <c2 0f 29 45 a0 41
ff d2]: run_tasks_from_lists+0x2c7/0xaa7
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc39325bd <89 75 ac e8 23 f1 ff
ff]: process_runnable_tasks+0x42d/0xad9 > run_tasks_from_lists
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc386fa08 <01 00 00 e8 88 27 0c
00]: run_poll_loop+0xb8/0x55f > process_runnable_tasks
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x55dfc387012d <00 00 00 e8 23 f8 ff
ff]: run_thread_poll_loop+0x27d/0x523 > run_poll_loop
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x7f5e79c9dda9 <10 e9 9b fd ff ff
ff d0]: libc:+0x95da9
Jun 28 05:33:56 server1 haproxy[3703705]: | 0x7f5e79d1ce08 <c3 31 ed 4c 89 c7
ff d2]: libc:+0x114e08
Jun 28 05:33:56 server1 haproxy[3703705]: Hint: when reporting this bug to
developers, please check if a core file was
Jun 28 05:33:56 server1 haproxy[3703705]: produced, open it with 'gdb',
issue 'bt' to produce a backtrace for the
Jun 28 05:33:56 server1 haproxy[3703705]: current thread only, then join
it with the bug report.
Jun 28 05:33:56 server1 haproxy[3703703]: [ALERT] (3703703) : Current worker
(3703705) exited with code 132 (Illegal instruction)
Jun 28 05:33:56 server1 haproxy[3703703]: [WARNING] (3703703) : A worker
process unexpectedly died and this can only be explained by a bug in haproxy or
its dependencies.
Jun 28 05:33:56 server1 haproxy[3703703]: Please check that you are running an
up to date and maintained version of haproxy and open a bug report.
Jun 28 05:33:56 server1 haproxy[3703703]: HAProxy version 3.4.1-1+0awslc
2026/06/27 - https://haproxy.org/
Jun 28 05:33:56 server1 haproxy[3703703]: Status: long-term supported branch -
will stop receiving fixes around Q2 2031.
Jun 28 05:33:56 server1 haproxy[3703703]: Known bugs:
http://www.haproxy.org/bugs/bugs-3.4.1.html
Jun 28 05:33:56 server1 haproxy[3703703]: Running on: Linux 7.0.10+deb14-amd64
#1 SMP PREEMPT_DYNAMIC Debian 7.0.10-1 (2026-05-27) x86_64
Jun 28 05:33:56 server1 haproxy[3703703]: [ALERT] (3703703) :
exit-on-failure: killing every processes with SIGTERM
Jun 28 05:33:56 server1 haproxy[3703703]: [WARNING] (3703703) : All workers
exited. Exiting... (132)
Jun 28 05:33:56 server1 systemd[1]: haproxy.service: Main process exited,
code=exited, status=132/n/a
Jun 28 05:33:56 server1 systemd[1]: haproxy.service: Failed with result
'exit-code'.
Jun 28 05:33:56 server1 systemd[1]: haproxy.service: Consumed 6min 18.613s CPU
time over 1h 8min 43.559s wall clock time, 295.7M memory peak.
Jun 28 05:33:57 server1 systemd[1]: haproxy.service: Scheduled restart job,
restart counter is at 61.
Jun 28 05:33:57 server1 systemd[1]: Starting haproxy.service - HAProxy Load
Balancer...
I'm now able to reproduce the issue. It happens with the FCGI only and when an
error is triggered during the request processing. I'm on a fix.
--
Christopher Faulet
