[Top][All Lists]
[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