Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10 5/3/83; site umcp-cs.UUCP
Path: utzoo!linus!philabs!seismo!rlgvax!cvl!umcp-cs!chris
From: chris@umcp-cs.UUCP
Newsgroups: net.unix-wizards
Subject: Re: Cron dies, why ?
Message-ID: <4834@umcp-cs.UUCP>
Date: Fri, 20-Jan-84 22:37:32 EST
Article-I.D.: umcp-cs.4834
Posted: Fri Jan 20 22:37:32 1984
Date-Received: Sat, 21-Jan-84 22:49:57 EST
References: <35@chalmers.UUCP>
Organization: Univ. of Maryland, Computer Science Dept.
Lines: 15

cron has a bug in dealing with long lines in /usr/lib/crontab.
The source has a magic constant in the table reader.  On standard
4.1BSD systems this is 100.  This constant says when to allocate
more table space.  If you're down to 110 characters it won't allocate
more space; if you then read in a long (>110 char) line the table
will overflow and the *next* call to malloc (realloc) will fail
with a segmentation fault or equivalent.

The quick fix, of course, is to increase the magic constant.  If it's
1024 then you can't make a long enough line in vi to overflow the table,
so that's a pretty good value.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci
UUCP:	{seismo,allegra,brl-bmd}!umcp-cs!chris
CSNet:	chris@umcp-cs		ARPA:	chris.umcp-cs@CSNet-Relay