spamass-milt-list
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: spamass-milter terminated with signal 6


From: Dan Nelson
Subject: Re: spamass-milter terminated with signal 6
Date: Mon, 2 Jun 2003 16:28:07 -0500
User-agent: Mutt/1.5.4i

In the last episode (Jun 02), Valentin Chopov said:
> Hi all,
> 
> I have a small problem with spamass-milter.
> I'm running it on FreeBSD 4.8.
> It core dumps about every 30-60min
> Here is the gdb info:
> 
> bash-2.05b# gdb -c spamass-milter.core  /usr/local/sbin/spamass-milter
> GNU gdb 4.18 (FreeBSD)
> Core was generated by `spamass-milter'.
> Program terminated with signal 6, Abort trap.
> (gdb) bt
> #0  0x2811bba0 in kill () from /usr/lib/libc_r.so.4
> #1  0x28169dfe in abort () from /usr/lib/libc_r.so.4
> #2  0x280bc25f in __default_terminate () from /usr/lib/libstdc++.so.3
> #3  0x280bc26d in __terminate () from /usr/lib/libstdc++.so.3
> #4  0x280bc54b in __sjthrow () from /usr/lib/libstdc++.so.3
> #5  0x804e2f1 in mlfi_eom (ctx=0x807c380) at spamass-milter.cpp:629
> #6  0x28077c0f in mi_clr_macros () from /usr/lib/libmilter.so.2
> #7  0x28077100 in mi_engine () from /usr/lib/libmilter.so.2
> #8  0x28076d79 in mi_handle_session () from /usr/lib/libmilter.so.2
> #9  0x2807659e in mi_thread_handle_wrapper () from /usr/lib/libmilter.so.2
> #10 0x280f6128 in _thread_start () from /usr/lib/libc_r.so.4
> #11 0xbfadcffc in ?? ()
> (gdb)
> 
> I couldn't find nothing suspicious at spamass-milter.cpp:629
> 
>   } catch (string& problem)
>     {
>       throw_error(problem);
>       smfi_setpriv(ctx, static_cast<void*>(0));
>       delete assassin;
>       debug(1, "mlfi_eom: exit");
>       return SMFIS_TEMPFAIL;    <---line 629
>     };
> 
> BTW, if I include a line after this line (e.g. debug(0,...)) the gdb/bt
> shows spamass-milter.cpp:630.
> 
> Any ideas with this?

This has been reported a few times by others.  It's crashing in the
destructor for some C++ object; unfortunately I don't know how to debug
C++ destructors to determine which object is having problems.  It
_may_ be a gcc 2.95 bug where exceptions cannot be thrown from one
shared object and caught in another.  I did a search, and there were
lot of complaints about gcc 2.95, shared libraries, and exceptions
causing aborts() on the gcc mailinglist.  If this is an upgraded
system, try recompiling sendmail, libc_r, and spamass-milter to ensure
that they are all built with the same version of gcc.  Another thing to
try is build the gcc33 port, and build spamass-milter with that
(build with CC=gcc33 CXX=g++33).
 
-- 
        Dan Nelson
        address@hidden




reply via email to

[Prev in Thread] Current Thread [Next in Thread]