Joseph V Moss wrote:
I've been able to reproduce the segfault that Justin was seeing.
But only under certain circumstances.
* Dallman Ross <dman(_at_)nomotek(_dot_)com> [2004-07-28 15:38]:
My file is simply a procmail rc-file. You grab it, and put a line
in your current rc right below the area you think is causing the
problem:
INCLUDERC=vsnag.self-test.rc
Then you look in your log. That is all. Knowing what all
the possible procmail vars have resolved to is useful to know.
Okay, I put the original file in linebuftest and ran:
procmail -m linebuftest < linebuftest
and got a segfault. I then created a linebuftest2 that looks
like this:
Thanks. Interesting. [Some details of what Joseph did snipped here.]
MAILDIR=./
DEFAULT=$MAILDIR/default_box
LOGFILE=$MAILDIR/procmail.log
Btw, not that it matters much, but you are setting DEFAULT and
LOGFILE so that there will be double-slashes in the path. (Double-
slashes are ignored -- treated as a single slash -- but I
thought I'd point that out. I noticed it from reading the log
excerpts you provided that employed my INCLUDERC.)
On a system running SuSE's SLES9, which has procmail 3.22,
the first time the variables are dumped does show an overflow
has occurred, but the segfault still occurs and the 2nd
INCLUDERC is never reached.
Interestingly, if I rebuild the source RPM for procmail 3.22
from SLES9 on an old RedHat 7.1 system, it doesn't segfault and
shows an overflow both times like it ought to. However, testing
with the original file (i.e. without the INCLUDERC lines) does
segfault as does procmail 3.14 and procmail 3.21 on that
same system (with either rc file). The older procmail
versions do NOT show that an overflow has occurred when they
dump their variables.
Again, interesting.
I did go ahead and look into the C code a bit (procmail 3.22)
and the segfault is happening inside the C library's realloc()
call (called by frealloc() in procmail when it is called by
elog(), which is invoked by the logqnl(buf2) call in
conditions()).
I've attached the various logs.
BTW, the original problem I was seeing with messages with
long To: lines failing was happening on a Solaris mail
server, so the segfaults aren't linux-specific.
Anyway, I've just bumped up my LINEBUF to a much larger value
so I should be okay for now.
Good.
Something else I noticed looking at the output from my rc that
you included: you are running procmail under the C-shell.
I don't think that's such a wunnerful idea. I have no idea
if that is the key to invoking this problem when LINEBUF is
deficient; but humor me and stuff
SHELL=/bin/sh
in up-top and see if you get the same results. If the
shell is related, then I'd ask Justin Gombos the same thing.
I'm also going to make some tiny adjustments to my self-test.rc
pretty soon -- but it won't change all that much.
Regards,
Dallman
____________________________________________________________
procmail mailing list Procmail homepage: http://www.procmail.org/
procmail(_at_)lists(_dot_)RWTH-Aachen(_dot_)DE
http://MailMan.RWTH-Aachen.DE/mailman/listinfo/procmail