[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

Alex  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #22 from Alex  ---
Hello Jeremy,

I believe it's fixed now. 

Thanks and regards,
Alex.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

Git Commit  changed:

   What|Removed |Added

 CC||g...@exim.org

--- Comment #21 from Git Commit  ---
Git commit:
https://git.exim.org/exim.git/commitdiff/675ae646c0506f6740bb8afa28c8c4892dabbdaf

commit 675ae646c0506f6740bb8afa28c8c4892dabbdaf
Author: Jeremy Harris 
AuthorDate: Wed Jun 6 10:41:51 2018 +0100
Commit: Jeremy Harris 
CommitDate: Wed Jun 6 10:43:18 2018 +0100

Fix logging of cmdline args when starting in an unlinked cwd.  Bug 2274
---
 src/src/exim.c | 17 +++--
 1 file changed, 11 insertions(+), 6 deletions(-)

diff --git a/src/src/exim.c b/src/src/exim.c
index 810550d..9f6efaf 100644
--- a/src/src/exim.c
+++ b/src/src/exim.c
@@ -4083,18 +4083,23 @@ a debugging feature for finding out what arguments
certain MUAs actually use.
 Don't attempt it if logging is disabled, or if listing variables or if
 verifying/testing addresses or expansions. */

-if (((debug_selector & D_any) != 0 || LOGGING(arguments))
+if (  (debug_selector & D_any  ||  LOGGING(arguments))
   && really_exim && !list_options && !checking)
   {
   int i;
   uschar *p = big_buffer;
   Ustrcpy(p, "cwd= (failed)");

-  Ustrncpy(p + 4, initial_cwd, big_buffer_size-5);
-  p += 4 + Ustrlen(initial_cwd);
-  /* in case p is near the end and we don't provide enough space for
-   * string_format to be willing to write. */
-  *p = '\0';
+  if (!initial_cwd)
+p += 13;
+  else
+{
+Ustrncpy(p + 4, initial_cwd, big_buffer_size-5);
+p += 4 + Ustrlen(initial_cwd);
+/* in case p is near the end and we don't provide enough space for
+ * string_format to be willing to write. */
+*p = '\0';
+}

   (void)string_format(p, big_buffer_size - (p - big_buffer), " %d args:",
argc);
   while (*p) p++;

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #20 from Jeremy Harris  ---
(In reply to Alex from comment #15)
> > Perhaps if os_getcwd() fails?  Could it be that the spam-checker has 
> > chdir()'d to a directory which it unlinks, but calls Exim from inside, 
> > so that Exim's os_getcwd() fails?

I'd say that's a good bet.  Try prefixing that Ustrncpy() at src/exim.c line
4093
with "if (initial_cwd) ".

Actually, that's so obviously needed I'll commit it right away.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #19 from Alex  ---
Sorry to say that, the patch did not help. Another crash happened recently on 

- 2018-06-04 12:00:10 at 14:27 


Seems to be all the same:


[root@server ccpp-2018-06-04-12:00:10-14027]# gdb /usr/sbin/exim coredump
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-110.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/exim...done.
[New LWP 14027]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/exim -oMr spam-scanned -bS'.
Program terminated with signal 11, Segmentation fault.
#0  __strncpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
296 movdqu  (%rsi), %xmm1


(gdb) bt
#0  __strncpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x004269f6 in main (argc=4, cargv=) at exim.c:4093

(gdb) frame 0
#0  __strncpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
296 movdqu  (%rsi), %xmm1

(gdb) frame 1
#1  0x004269f6 in main (argc=4, cargv=) at exim.c:4093
4093  Ustrncpy(p + 4, initial_cwd, big_buffer_size-5);
(gdb)

And I'm sure the exim was patched:

[root@server directadmin]# ls -la `which exim`
-rwsr-xr-x 1 root root 3981672 May 29 08:36 /sbin/exim

[root@server directadmin]# ls -la
/usr/local/directadmin/custombuild/exim-4.91-patched/src/exim.c
-rw-r--r-- 1 root root 179138 May 29 08:32
/usr/local/directadmin/custombuild/exim-4.91-patched/src/exim.c


Please advice.

Regards,
Alex.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #18 from Alex  ---
Hello Phil,

Thanks for the patch, it's applied now. I will let you know results. It might
take a while.

Regards,
Alex.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #17 from Phil Pennock  ---
https://git.exim.org/exim.git/commitdiff/805fd869d551c36d1d77ab2b292a7008d643ca79

Alex, does applying this as a patch solve your problem?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

Phil Pennock  changed:

   What|Removed |Added

   Assignee|t...@duncanthrax.net |p...@exim.org
 Status|NEW |ASSIGNED

--- Comment #16 from Phil Pennock  ---
I can't speak to the unknown signal issue, but as regards the stack trace:
okay, I think I see a problem in the code.

I think that if there's a path to a config entry in your trusted configs file
[TRUSTED_CONFIG_LIST in Local/Makefile] which is longer than cwd+4, then we'll
hit this bug.  The logic assumes that the memory store is zeroed out and that a
strncpy() will thus leave the copied string with NULs after it until the end of
the buffer.

There's nothing here which would have us write to bad memory; the problem is
going to be that immediately after the bad copy, we walk off it and keep
walking, looking for a place to write to.  _If_ there's a NUL after the
big-buffer, before an unallocated memory region, then we might have issues, but
this early in the process lifecycle, that seems unlikely.

Alex, I think that you're triggering this because your log_selector includes
"arguments", either through "log_selector = +arguments" or "log_selector =
+all".  As a work-around, you can remove arguments from the list of enabled log
features, and you'll no longer trigger this bug.  Also, can you confirm that
there's a very long path-name in the file which your Local/Makefile's
TRUSTED_CONFIG_LIST points to?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #15 from Alex  ---
> Perhaps if os_getcwd() fails?  Could it be that the spam-checker has 
> chdir()'d to a directory which it unlinks, but calls Exim from inside, 
> so that Exim's os_getcwd() fails?

It seems:

cwd=/var/spool/exim


from mainlog:

[root@good exim]# exigrep 1fJpyl-hb-Ee /var/log/exim/mainlog-20180519
2018-05-19 02:44:11 cwd=/var/spool/exim 3 args: /usr/sbin/exim -Mc
1fJpyl-hb-Ee

2018-05-19 02:44:12 cwd=/var/spool/exim 7 args: /usr/sbin/exim -t -oem -oi -f
<> -E1fJpyl-hb-Ee

2018-05-19 02:44:11 1fJpyl-hb-Ee <= ad...@example.at
H=84-xxx-xxx-38.cable.dynamic.surfer.at (4439K486L14439K) [84.xxx.xxx.38]
P=esmtpa A=login:ad...@example.at S=3815
id=92C491B2CD22456BA9141CA195AA60DD@4439K486L14439K T="subject is here" from
 for ad...@domain.at
2018-05-19 02:44:12 1fJpyl-hb-Ee ** ad...@domain.at F=
R=spamcheck_director T=spamcheck: Child process of spamcheck transport (running
command "/usr/sbin/exim -oMr spam-scanned -bS") was terminated by signal 139
(Unknown signal 139)
2018-05-19 02:44:12 1fJpyl-hb-Ee Completed

2018-05-19 02:44:12 1fJpym-iI-BS <= <> R=1fJpyl-hb-Ee U=mail P=local
S=1907 T="Mail delivery failed: returning message to sender" from <> for
ad...@example.at
2018-05-19 02:44:12 1fJpym-iI-BS => admin  F=<>
R=virtual_user T=dovecot_lmtp_udp S=2066 C="250 2.0.0 
QCZgFlxz/1qcMwAASZDFoQ Saved"
2018-05-19 02:44:12 1fJpym-iI-BS Completed


[root@good exim]#



and SpamAssassin is running as root:

[root@server exim]# ps aux | grep spam
root 27529  0.0  0.0   9088   664 pts/1S+   09:57   0:00 grep
--color=auto spam
root 28379  0.0  0.1 298372 69388 ?Ss   03:24   0:04 /usr/bin/spamd
--pidfile /var/run/spamd.pid -d -c -m 15 --ipv4
root 28386  0.0  0.1 313860 84960 ?S03:24   0:06 spamd child
root 28387  0.0  0.1 298372 66472 ?S03:24   0:00 spamd child
[root@server exim]#



p.s. and it's now Unknown signal 139

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #14 from Alex  ---
Will the following help?




[root@server ccpp-2018-05-15-15:38:54-18615]# gdb /usr/sbin/exim coredump
GNU gdb (GDB) Red Hat Enterprise Linux 7.6.1-110.el7
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /usr/sbin/exim...done.

warning: exec file is newer than core file.
[New LWP 18615]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `/usr/sbin/exim -oMr spam-scanned -bS'.
Program terminated with signal 11, Segmentation fault.
#0  __strncpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
296 movdqu  (%rsi), %xmm1
(gdb) break 296
Breakpoint 1 at 0x7f1fe9e1c617:
/usr/src/debug/glibc-2.17-c758a686/sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296.
(6 locations)
(gdb) frame 0
#0  __strncpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
296 movdqu  (%rsi), %xmm1
(gdb) bt
#0  __strncpy_sse2_unaligned () at
../sysdeps/x86_64/multiarch/strcpy-sse2-unaligned.S:296
#1  0x00426a10 in main (argc=4, cargv=) at exim.c:4095
(gdb) frame 1
#1  0x00426a10 in main (argc=4, cargv=) at exim.c:4095
4095  while (*p) p++;
(gdb)


Regards,
Alex.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #13 from Alex  ---
Hello Phil,

Directadmin manages Exim the following way:

1. at a moment of installation of a new server a pre-compiled package is
installed from DA's repository, it's called da_exim for CentOS.

2. then all updates and upgrades are done with a help of custombuild script,
which compiles Exim from sources.

Here what we have:

[root@server ccpp-2018-05-15-15:38:54-18615]# exim -bV
Exim version 4.91 #8 built 12-May-2018 09:25:36
Copyright (c) University of Cambridge, 1995 - 2018
(c) The Exim Maintainers and contributors in ACKNOWLEDGMENTS file, 2007 - 2018
Berkeley DB: Berkeley DB 5.3.21: (May 11, 2012)
Support for: crypteq IPv6 Perl OpenSSL move_frozen_messages Content_Scanning
DKIM DNSSEC Event OCSP PRDR SPF TCP_Fast_Open Experimental_SRS
Lookups (built-in): lsearch wildlsearch nwildlsearch iplsearch cdb dbm dbmjz
dbmnz dnsdb
Authenticators: cram_md5 dovecot plaintext spa
Routers: accept dnslookup ipliteral manualroute queryprogram redirect
Transports: appendfile/maildir/mailstore/mbx autoreply lmtp pipe smtp
Malware: f-protd f-prot6d drweb aveserver fsecure kavdaemon sophie clamd mksd
avast sock cmdline
Fixed never_users: 0
Configure owner: 0:0
Size of off_t: 8
2018-05-19 07:00:14 cwd=/var/spool/abrt/ccpp-2018-05-15-15:38:54-18615 2 args:
exim -bV
Configuration file is /etc/exim.conf


[root@server ccpp-2018-05-15-15:38:54-18615]# rpm -q da_exim
da_exim-4.89.1-1.x86_64
[root@server ccpp-2018-05-15-15:38:54-18615]#


The recent segfault:

May 19 02:44:11 server kernel: exim[2707]: segfault at 0 ip 7f6213f31cbf sp
7fff70c274e8 error 4 in libc-2.17.so[7f6213e97000+1c3000];


I will check what else I can provide you with.

Regards,
Alex.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

Phil Pennock  changed:

   What|Removed |Added

 CC||p...@exim.org

--- Comment #12 from Phil Pennock  ---
The abort server referenced in the crash details has nothing at the claimed
URL, and it's three days later, so I would really expect
https://retrace.fedoraproject.org/faf/reports/bthash/8fe5b7ec11a15288157804580a2f41dd3fe868d9
to have something if it were ever going to work.  So there's nothing there to
trace.

As far as I can tell, Direct Admin is mostly restricted to those with license
keys, which makes it hard to tell what's going on.  I've tried seeing how far I
could get in a Docker image, but (1) you're running Centos 7.5.1804, which is
newer than the latest Centos available on Docker Hub; and (2) the DirectAdmin
files mirror I'm looking at does not have packages for "7.5".  Meanwhile the
crash report doesn't say which version of the package, installed for what
architecture, is in use.

So at this point we've got a third-party build of Exim, built for unknown OS
release, being run on a different OS release, and we have crashes telling us
that the death is inside libc, but no stack traces and no way to sanely figure
out which version of Exim it was.

The bug-report claims that it's Exim 4.91 segfaulting, but the crash report
says that it's Exim from the package "da_exim-4.89.1-1".

What sort of system is this, where things are failing?  Is this running in
production somewhere, in this state?

We have from the dump a rather poor backtrace which can't tell us much without
the binary:

:,   "frames":
:  [ {   "address": 139775044603071
:,   "build_id": "cb4b7554d1adbef2f001142dd6f0a5139fc9aa69"
:,   "build_id_offset": 634047
:,   "function_name": "__strncpy_sse2_unaligned"
:,   "file_name": "/usr/lib64/libc-2.17.so"
:}
:  , {   "address": 4352528
:,   "build_id": "bae74c686ca4940655bfcf0c4667e94956fa977b"
:,   "build_id_offset": 158224
:,   "function_name": "main"
:,   "file_name": "/usr/sbin/exim"
:} ]

Okay.  So somewhere directly in main() there's a call to strncpy; there's no
indication of if Exim was compiled such as to optimize away intermediate
frames, for example.  The only _direct_ call to strncp (via Ustrncpy macro) is
when debug-logging, and the initial_cwd is copied into the big-buffer.

Perhaps if os_getcwd() fails?  Could it be that the spam-checker has chdir()'d
to a directory which it unlinks, but calls Exim from inside, so that Exim's
os_getcwd() fails?

Other than that wild shot in the dark, there's really too little here to chase
this any further.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #11 from Alex  ---
So in this case I need to start a gdb session and feed the process of
`/usr/sbin/exim -oMr spam-scanned -bS` with an email which caused the crash. If
this is the case... we don't have the email unfortunately.

As mentioned earlier we have never managed to repeat a crash manually.

Or do I miss anything?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #10 from Jeremy Harris  ---
Something else; that doesn't include a stack trace

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #9 from Alex  ---
Do you mean the one that attached as an attachment 1086? Or something else
different?

Regards,
Alex.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #8 from Jeremy Harris  ---
Unhelpful.  We need the stack trace.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #5 from Alex  ---
Hello Heiko,

Thanks for your reply.

(In reply to Heiko Schlittermann from comment #1)
> So, the next time the same message is delivered via the same transport, it
> does not segfault?

Yes, as soon as we restart exim and spamd all the new emails flow fine, the
same senders and recipients as well.

Coredumps were configured, but the fact exim is a suid binary slipped out of my
mind, so a coredump was never generated.

re-configured with the setting:

fs.suid_dumpable = 1

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #6 from Alex  ---
Hello Jeremy,

Thanks for your reply.

(In reply to Jeremy Harris from comment #4)
> To get more info, configure your system to take corefiles (see "man core",
> including the setuid specifics), and install the debuginfo package for glibc.
> Once you have a coredump, run (as root) gdb with the Exim binary and the
> corefile, and run the "bt" command to get a stack trace.
> 
> Then turn suid coredumps off again; they're a security problem.

It's now re-configured with

fs.suid_dumpable = 1 

so need to wait for a next crash.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

Heiko Schlittermann  changed:

   What|Removed |Added

 CC||h...@schlittermann.de

--- Comment #1 from Heiko Schlittermann  ---
So, the next time the same message is delivered via the same transport, it does
not segfault?

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #4 from Jeremy Harris  ---
To get more info, configure your system to take corefiles (see "man core",
including the setuid specifics), and install the debuginfo package for glibc.
Once you have a coredump, run (as root) gdb with the Exim binary and the
corefile, and run the "bt" command to get a stack trace.

Then turn suid coredumps off again; they're a security problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##

[exim-dev] [Bug 2274] exim 4.91: segfault ... error 4 in libc-2.17.so

[admin--- via Exim-dev]

https://bugs.exim.org/show_bug.cgi?id=2274

--- Comment #2 from Heiko Schlittermann  ---
Do you know how to enable core dumps on set-uid binaries? This could help for
further tracing.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-- 
## List details at https://lists.exim.org/mailman/listinfo/exim-dev Exim 
details at http://www.exim.org/ ##