Re: Exim4 problems

[Thomas Schwinge]

On Sun, 15 May 2011 11:28:55 +0200, Svante Signell <svante.signell@telia.com> 
wrote:
> I was asked by tschwinge to take a look at the install problems of
> exim4.

Thanks!

> running minimal functionality test for binary
> build-tree/build-exim4-daemon-light/exim in
> directory /home/srs/DEBs/exim/exim4-4.76/test
> Exim version 4.76 #1 built 15-May-2011 00:09:25
> [...]
> 2011-05-15 00:11:35 exim user lost privilege for using -C option
> debian/minimaltest: line 71: 21714 Segmentation fault      $2 -C
> "$top/exim4.conf" -bV

From this, and your later email, I would guess (I have not looked at the
source code) that debian/minimaltest is a shell script (test harness),
and runs its tests against the Exim binary
build-tree/build-exim4-daemon-light/exim, the failing one with options
``-C .../exim4.conf -bV''.  You can put ``set -v; set -x'' statements
into debian/minimaltest to have it print during execution what it's
exactly doing (see ``info bash'', or ``help set'').  Can you reproduce
the segfault by manually running
``build-tree/build-exim4-daemon-light/exim -C .../exim4.conf -bV''?  If
yes, then run that one through GDB.

It's likely an unexpected null pointer dereference (and hopefully not an
arbitrary memory corruption).  So, locate it with GDB, and then continue
with the source code/GDB backtrace to see why this happens.  I would
guess that some Hurd interface returns a value that Exim is not prepared
to receive, which some Exim function then turns into a null return value,
which yet some other Exim function isn't prepared to cope with.  The
backtrace/source code will tell.

Of course, once you have it located, don't forget to check if the problem
has already been fixed upstream.  Or, it may be a Hurd code issue,
instead.

It might also be a tools issue (GCC mis-compilation, for example), but
that is really unlikely.


Grüße,
 Thomas

pgph58KczVXEK.pgp
Description: PGP signature