Re: Exim4 problems

[Thomas Schwinge]

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.


> 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

pgpkveIyAGhLn.pgp
Description: PGP signature