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.
> Thread 4 (Thread 1285.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
> #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
> #2 0x00000000 in ?? ()
Can you do a ``bt full'', please? (See ``help bt'' at the GDB prompt.)
> (gdb) dir src
> (gdb) list
> 195 DEBUG(D_route) debug_printf("%s does not exist\n%schecking
> parent directory\n",
> 196 filename,
> 197 ((options & RDO_ENOTDIR) != 0)? "ignore_enotdir set =>
> skip " : "");
> 198 *yield = (((options & RDO_ENOTDIR) != 0) ||
> 199 rda_exists(filename, error) == FILE_NOT_EXIST)?
> 200 FF_NONEXIST : FF_ERROR;
What are the values of yield, filename, error (the full backtrace should
tell, I think). 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.)
If this doesn't help, I'll try to find some time to have a look at the
source code myself, but only later this week.
By the way: thanks for posting the rpctrace logs. Unfortunately (or
luckily?), I don't see anything fishy in them: the SEGFAULT happens after
printing the ``lost privilege for using -C option'' message, and there
isn't much in the logs after these lines, but that's entirely OK -- and
in fact it does support my access(NULL, ...) theory. ;-)
Grüße,
Thomas
pgpMfeuqC8WKj.pgp
Description: PGP signature
