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

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

Re: Explanation of error messages.


From: Dan Nelson
Subject: Re: Explanation of error messages.
Date: Thu, 19 Sep 2002 10:59:46 -0500
User-agent: Mutt/1.5.1i

In the last episode (Sep 19), Ron Snyder said:
> Dan Nelson wrote:
> > The libmilter part of sendmail is not very well documented (even by
> > sendmail standards :).  You'll have to dig into the source to find out
> > exactly what those errors mean.  Broken pipe sounds bad, though; it
> > implies the milter closed its connection before sendmail wanted it to,
> > which could mean it's seg-faulting.
> 
> These symbols are defined in include/libmilter/mfdef.h:
> Q == SMFIC_QUIT
> D == SMFIC_MACRO
> L == SMFIC_HEADER
> A == SMFIC_ABORT
> 
> The milter is definitely seg-faulting for me, but I haven't been able to
> figure out why. Here's a stack backtrace:
> 
> Core was generated by `spamass-milter'.
> Program terminated with signal 11, Segmentation fault.
> #0  0xb94d in SpamAssassin::read_pipe (this=0x25280) at
> spamass-milter.cpp:1032
> 1032    
> (gdb) bt
> #0  0xb94d in SpamAssassin::read_pipe (this=0x25280) at 
> spamass-milter.cpp:1032
> #1  0xba21 in SpamAssassin::empty_and_close_pipe (this=0x25280) at 
> spamass-milter.cpp:1043
> #2  0xa4b4 in SpamAssassin::input (this=0x25280) at spamass-milter.cpp:832
> #3  0x6f85 in mlfi_eom (ctx=0x24400) at spamass-milter.cpp:573
> #4  0x1041f in st_bodyend ()
> #5  0xf898 in mi_engine ()
> #6  0xdbd1 in mi_handle_session ()
> #7  0xd321 in mi_thread_handle_wrapper ()
> #8  0x40087518 in _thread_start ()
> 
> In my version of the source, line 1032 is the "return size;" statement of
> read_pipe().

Return should never segfault :)  Try the "disassemble" gdb command and
see what the code at 0xb94d is doing (i.e. see if it's really a ret
instruction).  Maybe gdb is lying.  Actually, since a C++ string was
allocated in read_pipe, it might be segfaulting in the destructor.

> Question-- read_pipe() is declared to return an int, but size is declared as
> a long. I can't see why that would be causing me any problems (sizeof(long)
> == sizeof(int)) on my platform, but maybe it's a problem for others?

No; the value will simply be truncated to MAXINT if it is larger. 
It'll never happen, of course, though :)
 
-- 
        Dan Nelson
        address@hidden




reply via email to

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