On 2024/12/21 11:23, Kirill A. Korinsky wrote: > On Sat, 21 Dec 2024 11:15:52 +0100, > Florian Obser <flor...@openbsd.org> wrote: > > > > On 2024-12-21 09:35 UTC, Stuart Henderson <s...@spacehopper.org> wrote: > > > On 2024/12/21 09:40, Florian Obser wrote: > > >> This happened on my production MXs after upgrading to -current this > > >> morning, but is easily reproducible with just installing rspamd on a > > >> test vm. Unfortunately the debug-rspamd package is not helping? Maybe > > >> I'm just holding it wrong... I've pkg_add -r to rspamd-3.10.2 for now. > > > > > > Hrmm. I'm running (self built) rspamd-3.11.0-hyperscan here and that's > > > working ok. > > > > > > The systems I can test on at the moment are frankensteined for a python > > > update, I can't use the current set of snapshot packages on them. It's > > > currently at 3k Ms in the tree so I need to get rid of that as soon as > > > I can :) > > > > > >> $ doas pkg_add debug-rspamd > > >> quirks-7.78 signed on 2024-12-20T20:34:07Z > > >> Ambiguous: choose package for debug-rspamd > > >> a 0: <None> > > >> 1: debug-rspamd-3.11.0 > > >> 2: debug-rspamd-3.11.0-hyperscan > > >> Your choice: 1 > > >> debug-rspamd-3.11.0: ok > > >> $ doas cp /root/rspamd.core . > > >> $ doas chown florian:florian rspamd.core > > >> $ egdb /usr/local/bin/.debug/rspamd.dbg rspamd.core > > > > > > I've never tried it that way, don't know if that's meant to work > > > or not. Normal use with debug packages is to give gdb the main binary > > > and let it find the detached symbols from elf headers. > > > > oooh, there is magic invovled. > > > > > > > >> Core was generated by `rspamd'. > > >> Program terminated with signal SIGSEGV, Segmentation fault. > > >> #0 0x00000dd48a396470 in ?? () > > >> (gdb) bt > > >> #0 0x00000dd48a396470 in ?? () > > >> #1 0x00000dd501c9617e in ?? () > > >> #2 0xabf9727ba290690b in ?? () > > >> #3 0x0000000000000018 in ?? () > > >> #4 0x0000729b675d82f0 in ?? () > > >> #5 0x00000dd501c96f70 in ?? () > > > [..] > > > > > > Those addresses look extremely dubious. Could you try "doas egdb > > > rspamd" / "set args -u _rspamd -g _rspamd -f -d" / "run" and see > > > if you get anything different please? > > > > > > > now we are cooking.... > > > > Starting program: /usr/local/bin/rspamd -u _rspamd -g _rspamd -f -d > > 2024-12-21 11:12:16 #49696(main) <166463>; main; main: rspamd 3.11.0 is > > loading configuration, build id: release > > > > Program received signal SIGSEGV, Segmentation fault. > > strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:125 > > 125 movq (%rax),%rdx /* get bytes to check */ > > (gdb) bt > > #0 strlen () at /usr/src/lib/libc/arch/amd64/string/strlen.S:125 > > #1 0x0000050e176ac17e in rspamd_vprintf_common ( > > func=0x50e176acf70 <rspamd_printf_append_char>, apd=0x76e440eaae40, > > fmt=0x50b6147a944 "s", args=0x76e440eaaec0) > > at /usr/obj/ports/rspamd-3.11.0/rspamd-3.11.0/src/libutil/printf.c:907 > > #2 0x0000050e1777f4cb in rspamd_vsnprintf (buf=<optimized out>, max=8192, > > fmt=0x50b6147a92b "simdutf implementation: %s", args=0x76e440eaaec0) > > at /usr/obj/ports/rspamd-3.11.0/rspamd-3.11.0/src/libutil/printf.c:561 > > #3 rspamd_common_logv (rspamd_log=0x50d8ec0d168, level_flags=64, > > module=0x50d8ec0d008 "main", id=0x50d8ec0d018 "166463530d9b64\333", > > function=0x50b6147b077 "main", > > fmt=0x50b6147a92b "simdutf implementation: %s", args=0x76e440eaaec0) > > at > > /usr/obj/ports/rspamd-3.11.0/rspamd-3.11.0/src/libserver/logger/logger.c:457 > > #4 0x0000050e17780292 in rspamd_default_logv (level_flags=48, > > module=0x50e175bd77a "(NULL)", id=0x0, > > function=0x101010101010101 <error: Cannot access memory at address > > 0x101010101010101>, fmt=0x73 <error: Cannot access memory at address 0x73>, > > args=<optimized out>) > > at > > /usr/obj/ports/rspamd-3.11.0/rspamd-3.11.0/src/libserver/logger/logger.c:542 > > #5 rspamd_default_log_function (level_flags=48, > > module=0x50e175bd77a "(NULL)", id=0x0, > > function=0x101010101010101 <error: Cannot access memory at address > > 0x1010101--Type <RET> for more, q to quit, c to continue without paging-- > > 01010101>, fmt=0x73 <error: Cannot access memory at address 0x73>) > > at > > /usr/obj/ports/rspamd-3.11.0/rspamd-3.11.0/src/libserver/logger/logger.c:553 > > #6 0x0000050b6148f4ec in main (argc=<optimized out>, argv=<optimized out>, > > env=<optimized out>) > > at /usr/obj/ports/rspamd-3.11.0/rspamd-3.11.0/src/rspamd.c:1555 > > > > > > fmt=0x73 makes me feel all warm and fuzzy. lalalala, I don't want to > > know. I'll back away slowly... > > > > I see that upstream had fixed some crash on FreeBSD without hyperscan: > https://github.com/rspamd/rspamd/commit/ccb45df90df60fae36b9438cfb2b0088e590306b > > Maybe try it? > > -- > wbr, Kirill >
Oh yes good catch Index: patches/patch-src_rspamd_c =================================================================== RCS file: patches/patch-src_rspamd_c diff -N patches/patch-src_rspamd_c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ patches/patch-src_rspamd_c 21 Dec 2024 10:30:59 -0000 @@ -0,0 +1,20 @@ +From ccb45df90df60fae36b9438cfb2b0088e590306b Mon Sep 17 00:00:00 2001 +From: Vsevolod Stakhov <vsevo...@rspamd.com> +Date: Tue, 17 Dec 2024 13:37:54 +0000 +Subject: [PATCH] [Fix] Fix crash on FreeBSD when Rspamd is built without + hyperscan + +Index: src/rspamd.c +--- src/rspamd.c.orig ++++ src/rspamd.c +@@ -56,8 +56,9 @@ + + #ifdef WITH_HYPERSCAN + #include "libserver/hyperscan_tools.h" +-#include "rspamd_simdutf.h" + #endif ++ ++#include "rspamd_simdutf.h" + + /* 2 seconds to fork new process in place of dead one */ + #define SOFT_FORK_TIME 2
