Thu 03 Mar 2005 01:34:31 AM UTC, comment #13:
Your suggested change did have an effect - it now segfaults in a different location:
#0 0x1c00d375 in basic_string<char, string_char_traits<char>, __default_alloc_template<false, 0> > operator+<char, string_char_traits<char>, __default_alloc_template<false, 0> > (lhs=@0x3c08bd8c, rhs=0x3c00099c "\r\n")
at /usr/include/g++/std/bastring.h:501
#1 0x1c007970 in mlfi_header (ctx=0x3c00d200, headerf=0x3c00c200 "Received",
headerv=0x3c00c209 "from hytronix-gw1.hytronix.com (IDENT:ycvfm3h9j79oxyvnzqtu@localhost.hytronix.com [127.0.0.1])\n\tby hytronix-gw1.hytronix.com (8.13.1/8.13.1) with ESMTP id j231T2cq013762\n\t(version=TLSv1/SSLv3 cipher=D"...)
at spamass-milter.cpp:1035
#2 0x1c01048e in st_header ()
#3 0x1c00fda2 in mi_engine ()
#4 0x1c00e889 in mi_handle_session ()
#5 0x1c00e079 in mi_thread_handle_wrapper ()
#6 0x0e0d4e1d in _thread_start () from /usr/lib/libpthread.so.6.0
|
Thu 03 Mar 2005 01:31:40 AM UTC, comment #12:
Crashed again. I'll hack on this for a while tonight.
|
Thu 03 Mar 2005 12:56:35 AM UTC, comment #11:
OK, done. I'll report back on the results.
Thanks!
|
Wed 02 Mar 2005 11:26:20 PM UTC, comment #10:
The read() return type shouldn't make any difference; C++ will simply cast the ssize_t value into a long, and since the only possible values are between -1 and 1024, even casting to a short would work.
As for the assembly, I think the assembly calls at 0x1c00b4ef and 0x1c00b501 match the debug() calls at spamass-milter.c:1807 and 1809, which means that the call at
0x1c00b523 is the destructor for something. I can only assume it's trying to build the arguments to destruct 'reason' and failing. Try changing the declaration at line 1761 to read
string reason = "";
It shouldn't make a bit of difference, since I'm pretty sure the default string constructor creates a 0-byte string anyhow.
|
Wed 02 Mar 2005 10:32:17 PM UTC, comment #9:
OK scratch that - it died again :)
|
Wed 02 Mar 2005 09:19:59 PM UTC, comment #8:
OK. Attached. BTW - not sure if it matters or not, but on OpenBSD, read() returns ssize_t instead of long. Of course, they're both 4 byte integers, but since changing this, it hasn't crashed in 20 minutes or so... Not that that means anything. I'll keep watching.
|
Wed 02 Mar 2005 09:07:44 PM UTC, comment #7:
How about this output:
disassemble 0x1c00b512-64 0x1c00b512+64
That will hopefully return the 25 or so assembly lines before and after the segfault, which may help me pinpoint exactly what crashed. All I can think of is the destructor for 'reason' might be dying, but I don't know why.
|
Wed 02 Mar 2005 08:25:26 PM UTC, comment #6:
Sorry - forgot to log in before posting. That file is from me.
|
Wed 02 Mar 2005 07:26:29 PM UTC, comment #5:
You bet. Attached below.
|
Wed 02 Mar 2005 07:21:22 PM UTC, comment #4:
Arg.
#0 0x1c00b512 in SpamAssassin::read_pipe (this=0x3c00d380)
at spamass-milter.cpp:1810
1810 return size;
how can a "return" segfault. The only thing I can think of is a stack overflow, but the only things that could overflow are iobuff (which can't because the read call only asks for 1024 bytes) and reason (which is a C++ string type and shouldn't be able to overflow), and the stack trace itself looks okay. Can you load gdb up again, and run
print size
print status
print iobuff
print reason
|
Wed 02 Mar 2005 06:46:08 PM UTC, comment #3:
I am getting the same error on OpenBSD 3.6. I'll attach the "where" output from the core file...
|
Thu 17 Feb 2005 08:24:30 PM UTC, comment #2:
Arg typo. The limit command should read
ulimit -c unlimited
|
Thu 17 Feb 2005 08:23:24 PM UTC, comment #1:
My guess is that the process has already exited; the "connection refused" message sent by sendmail is saying that there's no longer a process at the other end of the /var/spamass/spamass.sock file. If it crashed, hopefully we can get a useful coredump out of it. Edit /etc/rc.d/spamass-milter and put this at the top:
limit -c unlimit
sysctl kern.corefile=/tmp/%N.%P.core
and restart the milter. Now the next time it crashes it will put a corefile into /tmp. Then run gdb spamass-milter /tmp/6666.spamass-milter.core, and send the output of the "where" command. Note that the sysctl will redirect all cores to /tmp instead of leaving them in the current directory, so remember to remove that sysctl line when you're done debugging.
|
Thu 17 Feb 2005 08:11:10 PM UTC, original submission:
i appreciate the effort you guys have given to this project;
my problem is this:
things run fine for about an hour, then these will show up and spamass-milter will not be shutdown/restarted or killed.
Feb 16 12:39:53 mail-host sm-mta[17564]: j1GIYIQK017564: Milter (spamassassin): write(Q) returned -1, expected 5: Broken pipe
Feb 16 12:39:53 mail-host sm-mta[17564]: j1GIYIQK017564: Milter (spamassassin): to error state
Feb 16 12:39:53 mail-host sm-mta[24951]: j1GIdrlK024951: Milter (spamassassin): error connecting to filter: Connection refused by /var/spamass/spamass.sock
Feb 16 12:39:53 mail-host sm-mta[24951]: j1GIdrlK024951: Milter (spamassassin): to error state
tried
/etc/rc.d/spamass-milter stop
#kill -0 `cat /var/run/spamass-milter.pid`
#kill -9 `cat /var/run/spamass-milter.pid`
nothing worked. reboot hangs. ppid is (1) init.
FreeBSD 5.3-RELEASE FreeBSD
#sendmail -d0.1
Version 8.13.1
Compiled with: DNSMAP LOG MAP_REGEX MATCHGECOS MILTER MIME7TO8 MIME8TO7 NAMED_BIND NETINET NETINET6 NETUNIX NEWDB NIS PIPELINING SCANF STARTTLS TCPWRAPPERS USERDB XDEBUG
spamass-milter: illegal option -- V
spamass-milter - Version 0.3.0
# spamassassin -V
SpamAssassin version 3.0.2
running on Perl version 5.8.5
|