Re: Exim4 problems

[Svante Signell]

On Mon, 2011-05-16 at 20:28 +0200, Thomas Schwinge wrote:
> Hallo!
> 
> Se GDB decided to give some information at least...  :-)
> 
> On Mon, 16 May 2011 18:17:38 +0200, Svante Signell <svante.signell@telia.com> 
> wrote:
> > gdb
> > ===
> > gdb build-tree/build-exim4-daemon-heavy/exim
> > (gdb) run -C exim4-4.76/test/eximtest/exim4.conf -bV
> > Cannot access memory at address 0x6465766d
> > Cannot access memory at address 0x6465766d
> > Cannot access memory at address 0x6465766d 
> > Cannot access memory at address 0x6465766d 
> > Cannot access memory at address 0x6465766d
> > Cannot access memory at address 0x6465766d
> > [New Thread 1227.10] 0x6465766d
> > Cannot access memory at address 0x6465766d
> > Cannot access memory at address 0x6465766d
> > Cannot access memory at address 0x6465766d
> 
> These are still strange, but let's just ignore them for now.
> 
> > Exim version 4.76 #1 built 16-May-2011 17:11:04
> > ...
> > Exim version 4.76 uid=1000 gid=1000 pid=1285 D=fbb95cfd
> > Exim has no root privilege: uid=1000 gid=1000 euid=1000 egid=1000
> > changed uid/gid: -C, -D, -be or -bf forces real uid
> >   uid=1000 gid=1000 pid=1285
> >   auxiliary group list: <none>
> > seeking password data for user "1000": cache not available
> > configuration file is exim4-4.76/test/eximtest/exim4.conf
> > log selectors = 00000ffc 00212001
> > LOG: MAIN PANIC
> >   exim user lost privilege for using -C option
> > Total 18 lookups
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x000504fa in rda_get_file_contents (rdata=0x1e1e0c0, options=<value
> > optimized out>, include_directory=0x0, sieve_vacation_directory=0x0, 
> >     sieve_enotify_mailto_owner=0xffffffff <Address 0xffffffff out of
> > bounds>, sieve_useraddress=0x12354c "", sieve_subaddress=0x0,
> > generated=0x0, error=0x0, eblockp=0xffffffff, filtertype=0xec9bd) at
> > rda.c:200
> > 200     in rda.c
> > 
> > (gdb) thread apply all bt
> > 
> > Thread 5 (Thread 1285.10):
> > #0  0x018eff4c in ?? ()
> > #1  0x018f0749 in ?? ()
> > #2  0x018f0e79 in ?? ()
> > #3  0x018f0f4b in ?? ()
> > #4  0x0190194f in ?? ()
> > #5  0x017eec3c in ?? ()
> > #6  0x00000000 in ?? ()
> 
> Looks like the debugging information already got stripped off?  The build
> system does use ``gcc -g'', right?  Perhaps a ``strip'' command has been
> run by the build system on the binary you're examining?  (Is the one with
> debugging symbols available under a different name?)  You can use
> ``objdump -h [BINARY]'', and see if there are a number of .debug_*
> sections (.debug_line, .debug_frame) -- if not, the binary doesn't
> contain debugging symbols.

I don't know where this thread comes from. I have debug versions of
libc0.3, gnumach and hurd. And the exim file is not stripped:

 28 .debug_aranges 00000f00  00000000  00000000  000fd016  2**0
                  CONTENTS, READONLY, DEBUGGING
 29 .debug_info   000ecbed  00000000  00000000  000fdf16  2**0
                  CONTENTS, READONLY, DEBUGGING
 30 .debug_abbrev 00013c46  00000000  00000000  001eab03  2**0
                  CONTENTS, READONLY, DEBUGGING
 31 .debug_line   000317ae  00000000  00000000  001fe749  2**0
                  CONTENTS, READONLY, DEBUGGING
 32 .debug_str    00017e54  00000000  00000000  0022fef7  2**0
                  CONTENTS, READONLY, DEBUGGING
 33 .debug_loc    0009b6dd  00000000  00000000  00247d4b  2**0
                  CONTENTS, READONLY, DEBUGGING
 34 .debug_ranges 0000f2c8  00000000  00000000  002e3428  2**0
                  CONTENTS, READONLY, DEBUGGING

> Can you do a ``bt full'', please?  (See ``help bt'' at the GDB prompt.)

Thread 4 (Thread 7010.9):
#0  0x000504fa in rda_get_file_contents (rdata=0x1e1e0c0, options=<value
optimized out>, include_directory=0x0, sieve_vacation_directory=0x0,
sieve_enotify_mailto_owner=0xffffffff <Address 0xffffffff out of
bounds>, sieve_useraddress=0x12354c "", sieve_subaddress=0x0,
generated=0x0, error=0x0, eblockp=0xffffffff, filtertype=0xec9bd) at
rda.c:200
fwd = 0xec940
filebuf = <value optimized out>
statbuf = {st_fstype = 0, st_fsid = 153118985717468972, st_ino = 209234,
st_gen = 3, st_rdev = 974088, st_mode = 952900, st_nlink = 0, st_uid =
1175264, st_gid = 42, st_size = 998164, st_atim = {tv_sec = 0, tv_nsec =
0}, st_mtim = {tv_sec = 0, tv_nsec = 0}, st_ctim = {tv_sec = 0, tv_nsec
= 0}, st_blksize = 18018390, st_blocks = 0, st_author = 0, st_flags = 0,
st_spare = {0, 0, 0, 0, 0, 0, 0, 1}}
filename = 0x0
uid_ok = 0
gid_ok = 0
#1  rda_extract (rdata=0x1e1e0c0, options=<value optimized out>,
include_directory=0x0, sieve_vacation_directory=0x0,
sieve_enotify_mailto_owner=0xffffffff <Address 0xffffffff out of
bounds>, sieve_useraddress=0x12354c "", sieve_subaddress=0x0,
generated=0x0, error=0x0, eblockp=0xffffffff, filtertype=0xec9bd) at
rda.c:358
yield = 0

> What are the values of yield, filename, error (the full backtrace should
> tell, I think).  

See above: yield=0, filename=0x0, error=0x0. Something is definitely
wrong!

> You do agree that a NULL value of yield would certainly
> make this crash?  If that one points to a sane place, what does the
> rda_exists function do (``list rda_exists'' -- but it might also be a
> macro; you may have to manually look it up)?  Does it, by chance, call
> the C library's access function with a NULL pathname?  (That's just wild
> guessing.)

rda_extract, rda_get_file_contents and rda_exists are functions defined
in rda.c:

We also see from the BT that the arguments to rda_extract are completely
wrong: 

sieve_enotify_mailto_owner=0xffffffff <Address 0xffffffff out of bounds>
probably also: eblockp=0xffffffff

Additionally: No breakpoints are possible to set. Looks like they are
not honoured due to the memory address problems above.

static int rda_exists(uschar *filename, uschar **error)

static uschar * rda_get_file_contents(redirect_block *rdata, int
options, uschar **error, int *yield)

static int
rda_extract(redirect_block *rdata, int options, uschar
*include_directory,
  uschar *sieve_vacation_directory, uschar *sieve_enotify_mailto_owner,
  uschar *sieve_useraddress, uschar *sieve_subaddress,
  address_item **generated, uschar **error, error_block **eblockp,
  int *filtertype)
{
uschar *data;

if (rdata->isfile)
  {
  int yield = 0;
data = rda_get_file_contents(rdata, options, error, &yield); <-rda.c:358
  if (data == NULL) return yield;
  }
else data = rdata->string;