On 27/10/2023 04:12, Julian Waters via Exim-users wrote:
I haven’t raised a debian bug, I’m assuming it’s just my incompetence.
That a segv can happen at all constitutes a bug, however it was triggered.
Can you run with debug?
This would have helped, but
Can you get a coredump (note: Exim is usually run suid)?
This turns out to be essential, as the segv is hitting in a library: (libgnutls.so.30 + 0x15e06e)#012#2 0x00007f451526b354 gnutls_certificate_set_dh_params (libgnutls.so.30 + 0x6b354)#012#3 0x000056095cf86da5 n/a (exim4 + 0xbfda5)#012#4 0x000056095cf871c6 n/a (exim4 + 0xc01c6)#012#5 0x000056095cf88280 n/a (exim4 + 0xc1280)#012#6 0x000056095cf74622 n/a (exim4 + 0xad622)#012#7 0x000056095cf06eef n/a (exim4 + 0x3feef)#012#8 0x000056095cef89d8 n/a (exim4 + 0x319d8)#012#9 0x00007f45154461ca __libc_start_call_main (libc.so.6 + 0x271ca)#012#10 0x00007f4515446285 __libc_start_main_impl What we can glean so far is: - the crash is in the GnuTLS library - (inference) possibly exim handed it some parameter it can't handle and, you might actually have a core dump: systemd-coredump[1400341]: Process 1400339 (exim4) of user 113 dumped core.#012#012S However, this will probably have been a fully optimised binary for exim, and might not include debug information. It it doesn't, there might be an adjunct "debuginfo" package you can install - or it may be that it requires special compilation. You need to discuss this with Debian-knowledgeable people. Once debug info is present, the next step is to investigate a coredump using gdb, and get a stackdump (use the "bt" command) complete with function call arguments. I still think you should open a Debian bug for this. -- Cheers, Jeremy -- ## subscription configuration (requires account): ## https://lists.exim.org/mailman3/postorius/lists/exim-users.lists.exim.org/ ## unsubscribe (doesn't require an account): ## exim-users-unsubscr...@lists.exim.org ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
