terry@calgary.UUCP (Terry Heintz) (02/01/86)
HELP!!
I have a problem with DWB's tbl. There must have been someone out there that has come
across the problem and HOPEFULLY someone has a fix. We do have the source so if you
know what to change, it would be appreciated. The BUG occurs when you define two
tables one right after the other. (Example shown below.) In the second table
you will see a line missing and in its place there will be an arrow and several dots
( ex. <......... ). It seems that you can add,or remove, characters to the first,
or second, table and have this line change position. I seem to think the table
does not get reinitialized somewhere. The tbl that comes with the 4.2BSD source
seems to handle this perfectly but the DWB one does not.
Example input:
.sp
.TS
c s
l l.
Test the first table to make an error
col 1 col 2
.TE
.sp 2
.TS
center;
c s
l l
l l.
BUYERS CURRENT STATUS(JAN 28, 1986)
.sp3
Customer Type Legend: Price Legend:
.sp
CM = Commercial sc = compiler price
ED = Educational up = upgrade price
CL = Collaborator t = tax (where applicable)
GJ = Genuine Junk g = garbage (sometime)
.TE
Example output:
Test the first table to make an error
col 1 col 2
BUYERS CURRENT STATUS(JAN 21, 1986)
Customer Type Legend: Price Legend:
CM = Commercial sc = compiler price
ED = Educational up = upgrade price
CL = Collaborator t = tax (where applicable)
GJ = Genuine Junk g<........................
===========================================================
The DWB package we have is version 1, and it may be fixed already, however
we do not want to buy another version unless the fonts and rastertables
are present for the imagen 8-300 If there are any AT&T DWB people out
there I would sure like to talk to you, or at least post a fix for all of us that
have this problem. If it has alredy been solved please contact me personally.
Thankyou very much in advance
Terry Heintz
System programmer
University of Calgary
ihnp4!alberta!calgary!terry
(403) 220 3517probe@mm730.uq.OZ (Cameron Davidson) (02/05/86)
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 */ Note the second line which seems to be a big hint that the program actually uses one more. I only *think* the problem is fixed because every time tbl is compiled -with and without '-g' the symptom shifts and sometimes the test file then runs OK but another one fails. We originally got around the problem by just running this version as 'big-tbl' for those who needed more than 20 columns and took input always from stdin - When that is done whatever was causing the problems seemed to have no harmful effects. Cameron Davidson probe@mm730.uq.oz UUCP:..seismo!munnari!mm730.oz!probe
probe@mm730.uq.OZ (Cameron Davidson) (02/05/86)
Well, the change I made worked with my first test file but bombed out when I compiled without -g. The real bug is more obvious, however. The offending line was actually the next one: incrementing the pointer returned by calloc and then later trying to call cfree() with the incremented value is guaranteed to not do what you want (erratically). The line in freearr() which reads: cfree(sep); should be: cfree(--sep);
clyde@ut-ngp.UUCP (Head UNIX Hacquer) (02/05/86)
> 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
iau@ukc.ac.uk (I.A.Utting) (02/06/86)
In article <121@mm730.uq.OZ> probe@mm730.UUCP writes: >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 */ > .... Although we don't use DWB tbl, I've fixed this problem in the early-ditroff version we do use, the problem might be the same. Check out the code that frees sep. I guess you'll find that it does just that. It should of course free --sep. This is an EXTREMELY DIRTY FIX. Use your imagination to make it tidier. Ian Utting iau@ukc.uucp