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. > 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?
