I saw the crash after patching mux_h1.c only but it was perhaps because I reloaded the service.
On 29/06/2026 16:34, Yaacov Akiba Slama wrote: > On 29/06/2026 16:23, Christopher Faulet wrote: >> Le 28/06/2026 à 5:28 PM, Yaacov Akiba Slama a écrit : >>> Hi, >>> >>> Sending again because the patch was scrambled. >>> >>> >>> After upgrading to 3.4.1 we hit repeated BUG_ON crashes in __b_putblk() >>> triggered by the FCGI drain fix (84b952515). The drain fix is correct, >>> but it exposed missing b_room() checks in four b_xfer() zero-copy call >>> sites. Patch in attachment fixes all four. >> >> Could you share your backtrace please ? > 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... >> >> Your patch should not fix anything. In appctx_htx_rcv_buf(), h2_rcv_buf() >> and qcs_http_rcv_buf(), b_xfer() is called when the destination buffer is >> empty. So there is always enough space, the buffers are swapped.__b_putblk() >> is never called. >> >> Remains the fix for h1_nego_ff(). In that case, relying on b_contig_space() >> is safe, especially because the buffer is realigned if the free space wraps. >> In fact b_room() and b_contig_space() should be equivalent. >> >> Your backtrace should help me to better understand your issue. >> >> Regards, >
