[Cc on replies is appreciated]
Howdy,
I've had exim SEGV'ing here and there for a while and was able to narrow it
down to the callout database now that tidydb got the bug too and I can
reproduce:
I took the debian source and rebuilt with -g.
magic:/var/tmp/exim4-4.77# gdb debian/exim4-base/usr/sbin/exim_tidydb
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-linux"...(no debugging symbols found)
Using host libthread_db library "/lib/i386-linux-gnu/i686/cmov/libthread_db.so.1".
(gdb) run /var/spool/exim4 callout
Starting program: /var/tmp/exim4-4.77/debian/exim4-base/usr/sbin/exim_tidydb /var/spool/exim4 callout
(no debugging symbols found)
Tidying Exim hints database /var/spool/exim4/db/callout
deleted bathsavings.com (too old)
deleted returns.sales.overstock.com (too old)
(...)
deleted newsletters.sourceforge.net (too old)
deleted goriacqua.com (too old)
Program received signal SIGSEGV, Segmentation fault.
0xb750eddd in ?? ()
(gdb) bt
#0 0xb750eddd in ?? ()
#1 0x0000005a in ?? ()
#2 0xb7652a91 in ?? ()
#3 0xb8159504 in ?? ()
#4 0xb81594dc in ?? ()
(...)
#397 0x00000003 in ?? ()
#398 0xb7789ea4 in ?? ()
#399 0xbf9c7e88 in ?? ()
#400 0xb7826bb0 in ?? ()
#401 0x00001000 in ?? ()
Previous frame inner to this frame (corrupt stack?)
(gdb)
Exim was built like this:
gcc -o exim acl.o child.o crypt16.o daemon.o dbfn.o debug.o deliver.o directory.o dns.o drtables.o enq.o exim.o expand.o filter.o filtertest.o globals.o dkim.o header.o host.o ip
.o log.o lss.o match.o moan.o os.o parse.o queue.o rda.o readconf.o receive.o retry.o rewrite.o rfc2047.o route.o search.o sieve.o smtp_in.o smtp_out.o spool_in.o spool_out.o stor
e.o string.o tls.o tod.o transport.o tree.o verify.o lookups/lf_quote.o lookups/lf_check_file.o lookups/lf_sqlperform.o local_scan.o perl.o malware.o mime.o regex.o spam.o spool_m
box.o demime.o bmi_spam.o spf.o srs.o dcc.o version.o \
routers/routers.a transports/transports.a lookups/lookups.a \
auths/auths.a pdkim/pdkim.a \
-lresolv -lnsl -lcrypt -lm -lpam -export-dynamic \
-ldb -lldap -llber -lmysqlclient -lpq -lsqlite3 -lsasl2 \
-Wl,-E -fstack-protector -L/usr/local/lib -L/usr/lib/perl/5.12/CORE -lperl -ldl -lm -lpthread -lc -lcrypt -lgnutls -lpcre -rdynamic
magic:/var/tmp/exim4-4.77# ldd debian/exim4-base/usr/sbin/exim_tidydb
linux-gate.so.1 => (0xffffe000)
libnsl.so.1 => /lib/i386-linux-gnu/i686/cmov/libnsl.so.1 (0xb7783000)
libcrypt.so.1 => /lib/i386-linux-gnu/i686/cmov/libcrypt.so.1 (0xb7751000)
libm.so.6 => /lib/i386-linux-gnu/i686/cmov/libm.so.6 (0xb772b000)
libdl.so.2 => /lib/i386-linux-gnu/i686/cmov/libdl.so.2 (0xb7727000)
libdb-5.1.so => /usr/lib/i386-linux-gnu/libdb-5.1.so (0xb7596000)
libc.so.6 => /lib/i386-linux-gnu/i686/cmov/libc.so.6 (0xb743b000)
/lib/ld-linux.so.2 (0xb77af000)
libpthread.so.0 => /lib/i386-linux-gnu/i686/cmov/libpthread.so.0 (0xb7422000)
magic:/var/tmp/exim4-4.77#
gdb is not being very helpful here, any clue how to debug further?
Obviously I can fix my own problem by deleting the callout DB and starting over, but that
will not fix the bug and it'll randomly come back later.
Thanks,
Marc
--
"A mouse is a device used to point at the xterm you want to type in" - A.S.R.
Microsoft is to operating systems ....
.... what McDonalds is to gourmet cooking
Home page: http://marc.merlins.org/
