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-unsubscribe@???
## Exim details at
http://www.exim.org/
## Please use the Wiki with this list -
http://wiki.exim.org/
