Re: Milter (spamassassin): to error state : spamassassin milter seems to randomly fail

[Dan Nelson]

In the last episode (Aug 19), Joost van Baal said:
> At that time, processes
> 
>  spamd    11134  0.0  0.6 17896 13848 ?       S    Aug14   1:17 
> /usr/sbin/spamd -m 10 --nouser-config -u spamd -d --pidfile=/var/run/spamd.pid
>  root      7495  0.0  0.0 269200 1096 ?       S    Aug18   0:00 
> /usr/sbin/spamass-milter -p /var/run/sendmail/spamass.sock
> 
> where running.  (Just _one_ spamass-milter.)  There were no resource
> problems:

Yeah, one process means that there was a seg fault or other fatal
signal, and there's a bug in LinuxThreads where the helper process
doesn't realize it.

> Luckily, I have a 262M spamass-milter core file, from Aug 18 22:27, named 
> /core.2487 .  At 22:00, we had:

Yow!  292m is quite big. 
 
> Running gdb on this core file gives:
> 
> address@hidden:~% gdb /usr/sbin/spamass-milter /core.2487
> GNU gdb 2002-04-01-cvs
> Copyright 2002 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)...
> Core was generated by `/usr/sbin/spamass-milter -p 
> /var/run/sendmail/spamass.sock'.
> Program terminated with signal 11, Segmentation fault.
> Reading symbols from /usr/lib/libstdc++-libc6.2-2.so.3...(no debugging 
> symbols found)...done.
> Loaded symbols for /usr/lib/libstdc++-libc6.2-2.so.3
> Reading symbols from /lib/libm.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libm.so.6
> Reading symbols from /lib/libpthread.so.0...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/libpthread.so.0
> Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.6
> Reading symbols from /lib/ld-linux.so.2...(no debugging symbols found)...done.
> Loaded symbols for /lib/ld-linux.so.2
> #0  0x4010b1b7 in memcpy () from /lib/libc.so.6
> 
> (gdb) info threads
> * 1 process 2487  0x4010b1b7 in memcpy () from /lib/libc.so.6
> 
> (gdb) bt
> #0  0x4010b1b7 in memcpy () from /lib/libc.so.6
> #1  0x40032130 in string_char_traits<char>::copy () from 
> /usr/lib/libstdc++-libc6.2-2.so.3
> #2  0x08052987 in basic_string<char, string_char_traits<char>, 
> __default_alloc_template<true, 0> >::Rep::copy ()
> #3  0x08052e2c in basic_string<char, string_char_traits<char>, 
> __default_alloc_template<true, 0> >::replace ()
> #4  0x0805367c in basic_string<char, string_char_traits<char>, 
> __default_alloc_template<true, 0> >::append ()
> #5  0x08050330 in SpamAssassin::output ()
> #6  0x08050765 in SpamAssassin::output ()
> #7  0x0804d970 in mlfi_envrcpt ()
> #8  0x080567c7 in st_rcpt ()
> #9  0x08056072 in mi_engine ()
> #10 0x08054e79 in mi_handle_session ()
> #11 0x0805468d in mi_thread_handle_wrapper ()
> #12 0x400880ba in pthread_start_thread () from /lib/libpthread.so.0
> 
> What more information do you need, and how can I get that from my core
> file?

Ooh.  Get me line number info for frame 5.  It looks like you ran gdb
on a stripped binary; otherwise you would see the line numbers in the
backtrace.  The only output()s in envrcpt are the three that generate
fake Sendmail headers, so it should be easy to track down which one
caused the segfault.

-- 
        Dan Nelson
        address@hidden