Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbosgd!gatech!ut-sally!ut-ngp!clyde
From: clyde@ut-ngp.UUCP (Head UNIX Hacquer)
Newsgroups: net.text,net.bugs
Subject: Re: DWB tbl bug!! HELP
Message-ID: <2915@ut-ngp.UUCP>
Date: Wed, 5-Feb-86 10:16:05 EST
Article-I.D.: ut-ngp.2915
Posted: Wed Feb  5 10:16:05 1986
Date-Received: Fri, 7-Feb-86 06:16:40 EST
References: <98@calgary.UUCP> <121@mm730.uq.OZ>
Distribution: net
Organization: UTexas Computation Center, Austin, Texas
Lines: 33
Xref: watmath net.text:926 net.bugs:738

>	The problem arises when something scribbles 4 bytes into the input
>	buffer of (FILE *)tabin.
>	It occurs during the call to frearr() after the first table
>	finishes printing when the alloc'd memory is freed.
>	I think the problem is caused by the allocation at line 291 of t4.c
>	in routine garray() and the problem seems to have gone away by increasing
>	the allocation to 'sep' by one int.:
>		sep = (int *) getcore(qcol+2, sizeof(int));
==>		sep++; /* sep[-1] must be legal */

The actual problem is in freearr() on line 321:

	cfree(sep);
--- should be
	cfree(--sep);

Because of the 'sep++;' (pointed to above).  Malloc stores the size of
the chunk allocated in the previous word and if you don't free()
(which is all that cfree() really is) the SAME memory address that
you are given by malloc()/calloc(), free() does not get the proper
size of the memory chunk being freed.

This ends up corrupting malloc's allocation arena. If you are lucky,
causes buffering problems and if you are not lucky, segmentation faults
or bus errors.
-- 
Shouter-To-Dead-Parrots @ Univ. of Texas Computation Center; Austin, Texas  

"If you can't say something nice, say something surrealistic"
	- Zippy the Pinhead

	clyde@ngp.UTEXAS.EDU, clyde@sally.UTEXAS.EDU
	...!ihnp4!ut-ngp!clyde, ...!allegra!ut-ngp!clyde