Dspam wrote:
> Hi,
>
> I am running dspam on a OpenBSD 4.0-stable. It works not very well. I
> have many segmentations fault. It run with Postfix like in
> doc/postfix.txt : postfix delivers to dspam via lmtp socket
> (/tmp/dspam.sock) Some times i have "connection timeout" so i have
> added -o lmtp_data_done_timeout=1200 and it work. But i still have many
> segmentations faults ( ~ 30/day). What can i do ?
>
> My dspam version :
> DSPAM Anti-Spam Suite 3.6.8 (agent/library)
>
> Configuration parameters: --with-storage-driver=mysql_drv
> --with-mysql-libraries=/usr/local/lib/mysql
> --with-mysql-includes=/usr/local/include/mysql --enable-virtual-users
> --enable-preferences-extension --enable-domain-scale
> --with-dspam-owner=_dspam --with-dspam-group=_dspam
> --with-dspam-home=/var/dspam --enable-daemon
>
> Any help would be very appreciated
I have been testing dspam on OpenBSD 3.9 & 4.0.
I am using the Hash driver. I too have been experiencing problems when
using dspam in daemon mode and observing core dumps.
I am using a shared group and have observed that if I have the option
HashConcurrentUser nobody
I don't observe any core dump. Commenting out this line and feeding
messages through yields the core dumps.
I have pulled the following from the core dump of dspam-3.8.0;
bash-3.1# gdb
/usr/ports/mail/dspam-3.8.0/w-dspam-3.8.0p0-hash/build-i386-hash/src/dspam
/var/dspam/dspam.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.0"...
Core was generated by `dspam'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.6.3...done.
Loaded symbols for /usr/lib/libpthread.so.6.3
Reading symbols from /usr/lib/libm.so.2.3...done.
Loaded symbols for /usr/lib/libm.so.2.3
Symbols already loaded for /usr/lib/libpthread.so.6.3
Reading symbols from /usr/lib/libc.so.39.3...done.
Loaded symbols for /usr/lib/libc.so.39.3
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 0x0dcb6b20 in popen (
program=0x82a44798 "/usr/local/bin/maildrop -d some-recipient ",
type=0x3c0001c6 "w") at /usr/src/lib/libc/gen/popen.c:87
87 close(fileno(pcur->fp));
(gdb) bt
#0 0x0dcb6b20 in popen (
program=0x82a44798 "/usr/local/bin/maildrop -d some-recipient ",
type=0x3c0001c6 "w") at /usr/src/lib/libc/gen/popen.c:87
#1 0x1c003ada in deliver_message ()
#2 0x1c005124 in process_users ()
#3 0x1c00b579 in process_connection ()
#4 0x01568f4b in _thread_start ()
at /usr/src/lib/libpthread/uthread/uthread_create.c:244
#5 0x0000001f in ?? ()
#6 0x00000000 in ?? ()
Perusing the OpenBSD man page for popen(3) under BUGS it suggests
calling fflush(3) prior to popen(). I have applied
fflush (file);
directly underneath the line in dspam.c which reads
file = popen (args, "w");
After removing the .css files associated with the global group I now no
longer observe segmentation violations.
I have applied the same to dspam-3.6.8 in the OpenBSD ports tree. I have
progressed from experiencing segmentation violations in popen() but am
now seeing it in pclose(). Not sure what to do here.
Here is the output from gdb.
gdb
/usr/ports/mail/dspam-test/w-dspam-3.6.8p1-hash/build-i386-hash/src/dspam
/root/dspam.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd4.0"...
Core was generated by `dspam'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.6.3...done.
Loaded symbols for /usr/lib/libpthread.so.6.3
Reading symbols from /usr/lib/libm.so.2.3...done.
Loaded symbols for /usr/lib/libm.so.2.3
Symbols already loaded for /usr/lib/libpthread.so.6.3
Reading symbols from /usr/lib/libc.so.39.3...done.
Loaded symbols for /usr/lib/libc.so.39.3
Reading symbols from /usr/libexec/ld.so...done.
Loaded symbols for /usr/libexec/ld.so
#0 pclose (iop=0x253b94e0) at /usr/src/lib/libc/gen/popen.c:147
147 if (cur->fp == iop)
(gdb) bt
#0 pclose (iop=0x253b94e0) at /usr/src/lib/libc/gen/popen.c:147
#1 0x1c003977 in deliver_message ()
#2 0x1c005000 in process_users ()
#3 0x1c00b059 in process_connection ()
#4 0x0c4d2f4b in _thread_start ()
at /usr/src/lib/libpthread/uthread/uthread_create.c:244
#5 0x0000001f in ?? ()
#6 0x00000000 in ?? ()
(gdb)
The issue still remains with 3.6.8 and 3.8.0 whereby the exit code from
the LDA (maildrop in my case) does not propagate back to the postfix
pipe which called "dspam --client" as evidence by setting the sticky bit
on a users home directory - continue to see exit code of -1 from dspam.
Suspect this may be related to pclose() and wait4() on OpenBSD.
Any have any further suggestions?
Cheers,
Larry.
