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.sign...@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;
