Re: spamass-milter terminated with signal 6

[Valentin Chopov]

Thanks Dan,

This server is fresh built so everything is compiled with the same version
of gcc (2.95.4) . I'll try to compile spamass-milter with gcc3.xx ...

Val


On Mon, 2 Jun 2003, Dan Nelson wrote:

> 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
>
>

==
Valentin S. Chopov, CC[ND]P
Sys/Net Admin
SEI Data Inc.
E-Mail: address@hidden
==