Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!sol.ctr.columbia.edu!ira.uka.de!fauern!opal!fub!geminix.in-berlin.de!gemini
From: gemini@geminix.in-berlin.de (Uwe Doering)
Newsgroups: comp.mail.elm
Subject: Re: Fatal bus error condition under elm 2.3 pl9
Message-ID: <2X6LL4K@geminix.in-berlin.de>
Date: 11 Dec 90 15:00:07 GMT
References: <1990Dec10.204010.7183@wubios.wustl.edu> <1990Dec10.225957.4587@macc.wisc.edu>
Organization: Private UNIX Site
Lines: 36

anderson@udder.macc.wisc.edu (Jess Anderson) writes:

>In article <1990Dec10.204010.7183@wubios.wustl.edu>
>jeff@wubios.wustl.edu (Jeff Gabel) writes:
>
>>Configuration: Running elm 2.3 pl9 on Sun 3/260 under SunOS 4.1
>>Elm was configured without debugging enabled for this installation,
>>so the error message we get is minimal.
>
>>Bug: When using s)ave or C)opy for particular messages getting a 
>>fatal error (as follows):
>
>>Bus error signal!
>
>That's where I get Segment violation signal.

On a 386 system running ISC 2.0.2 UNIX I've got the same error. Not
with the save function but rather when I wanted to reply to a mail. The
problem was a `Received:' line that was longer than the 256 bytes of
the Elm input buffer used to read in those lines.

Now I wonder why there is no protection against buffer overflow at this
point. And I don't understand why Elm uses static rather than dynamically
allocated buffers to store header lines. I really don't feel comfortable
knowing that other people (who create the header lines) can decide whether
my mailer breaks or not. One simply can't rely on a miximum header line
length.

I circumvented the problem by doubling the buffer size, but this is only
a hack and by no means a proper fix.

     Uwe
-- 
Uwe Doering  |  INET : gemini@geminix.in-berlin.de
Berlin       |----------------------------------------------------------------
Germany      |  UUCP : ...!unido!fub!geminix.in-berlin.de!gemini