Re: This tiny script causes a segmentation fault..

> On Wed, Jul 28, 2004 at 08:34:50PM -0600, Justin Gombos wrote:
>
> > * Dallman Ross <dman(_at_)nomotek(_dot_)com> [2004-07-28 15:38]:
> > > I am unable to reproduce your results.  In fact, the above 
> > > recipe in my test harness (from your LINEBUF assignment on)
> > > does not overrun for me.
I noticed a few days ago that I didn't get some email messages which had
extremely long lists of recipients in the To: line.  My verbose procmail logs
said nothing about the messages after putting the long list into a variable
(no indication of delivery, no error messages, just nothing after that).
After a little investigation I found that procmail was segfaulting at that
point.

I've been able to reproduce the segfault that Justin was seeing.
But only under certain circumstances.

[...]

> > > If you feel like it, you could download my diagnostics plug-in rc
> > > and run it via an INCLUDERC after the buffer overrun.  You will get
> > > something like this:
> > I'm not sure yet if I want to start looking at the code to debug it.
> > I'll keep that in mind.
> I have no desire to look at C-code.  That's not what I was suggesting.
> 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:

MAILDIR=./
DEFAULT=$MAILDIR/default_box
LOGFILE=$MAILDIR/procmail.log
VERBOSE=1

DUMMY=`:>$LOGFILE`

LINEBUF=128

SOME_BYTES=(\
0000000000|\
00000000000000000000|\
11111111111111111111|\
11111111111111111111|\
11111111111111111111|\
22222222222222222222)

INCLUDERC=vsnag.self-test.rc

:0 :
*$ !^TO_$SOME_BYTES
{
        INCLUDERC=vsnag.self-test.rc
        
        :0
        mailbox
}

i.e. I added the code to dump the vars both before and after the condition line
that causes the segfault.

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.

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.

procmail.log.314
Description: procmail.log.314

procmail.log.321
Description: procmail.log.321

procmail.log.322
Description: procmail.log.322

procmail.log.322suse
Description: procmail.log.322suse

____________________________________________________________
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