Hi Maciej! On Mon, Mar 24, 2025 at 02:11:12PM +0100, Maciej Zdeb wrote: > Hi, > > I've noticed a segfault of HAProxy 2.8.9. I believe it happens when a map > is updated frequently and at the same time a "clear map" command is > triggered from CLI. I know the version I use is pretty old but I didn't > find any fix that might be related to the latest versions. I would be very > grateful for help. (...) > #4 0x00007f01400aa7f3 in __GI_abort () at ./stdlib/abort.c:79 > #5 0x000055ca8f571965 in ha_panic () at src/debug.c:439 > #6 ha_panic () at src/debug.c:413 > #7 <signal handler called> > #8 0x00007f01401a0b7b in madvise () at > ../sysdeps/unix/syscall-template.S:117 > #9 0x00007f0140128995 in mtrim (pad=0, av=0x7f007c000030) at > ./malloc/malloc.c:5078 > #10 __malloc_trim (s=0) at ./malloc/malloc.c:5107 > #11 0x000055ca8f71f3c0 in trim_all_pools () at src/pool.c:126 > #12 0x000055ca8f717d65 in cli_io_handler_clear_map (appctx=0x55cb3f02a250)
OK actually it's not a segfault, it's a watchdog during malloc_trim(). We've seen a few over time, as some libc can become extremely slow during this operation and may even never complete if there are sufficient threads trying to allocate memory while this one is purging its entries. Unfortunately we can't ask it to only purge a little bit of them. We've added a global option "no-memory-trimming" explicitly to disable this mechanism. We don't want to remove it for everyone because for some users on small systems it can be vital. But with high loads, the allocator can be put under quite some stress and then it's better to disable trimming. I suggest that you just add this option and you won't see that issue anymore. The only thing is that you might notice that the total amount of memory fades away slower after a map clearing. But if you're on high loads you probably don't care. Hoping this helps, Willy
