On 22.03.22 17:25, Jeremy Harris via Exim-users wrote: > Try pulling in commit d2f99aad04, which was made
> following similar issues (since 4.95). Still experiencing segfaults, but this time a core file is generated
when running the debug build and the stack trace is different:
#0 strlen (str=0x0) at /usr/src/lib/libc/string/strlen.c:101
#1 0x0000000000340a7c in string_cat (string=0x8013dbed8, s=0x0) at string.c:1189
#2 0x000000000029f873 in string_get_localpart (addr=0x8013db240, yield=0x8013dbed8) at deliver.c:976
#3 0x000000000028eb0e in string_log_address (g=0x8013dbed8, addr=0x8013db240, all_parents=0, success=0) at deliver.c:1052
#4 0x000000000029fb78 in deferral_log (addr=0x8013db240, now=0x3d7cb0 <timebuf> "2022-03-24 16:13:54", logflags=1,
driver_name=0x801a27e98 "remote_smtp_dane", driver_kind=0x222b7c " transport") at deliver.c:1311
#5 0x000000000029a6e9 in post_process_one (addr=0x8013db240, result=1, logflags=1, driver_type=2, logchar=0) at deliver.c:1680
#6 0x00000000002a0a1b in remote_post_process (addr=0x8013db240, logflags=1, msg=0x0, fallback=0) at deliver.c:3806
#7 0x00000000002a0d5d in par_reduce (max=0, fallback=0) at deliver.c:4116
#8 0x000000000029e98e in do_remote_deliveries (fallback=0) at deliver.c:5070
#9 0x00000000002960b7 in deliver_message (id=0x7fffffffe424 "1nV99f-00044u-Le", forced=0, give_up=0) at deliver.c:7257
#10 0x00000000002b0e65 in main (argc=4, cargv=0x7fffffffe0a0) at exim.c:4765
