feedback on my request for [nt]roff help

Chuq Von Rospach chuqui at nsc.UUCP
Fri Mar 16 06:09:45 AEST 1984


First, I want to thank everyone out there for the feedback on my [nt]roof
problems. I also want to thank everyone for the nice job offers (it seems
that anyone who is dumb enough to want to work on this thing is in demand!)

After a number of weeks of beating on the turkey, I finally have MM running
on 4.2. The only significant lack is the \g call. I believe at least one
version of this has been posted, so I won't repeat it. If you want this
modification, drop me a line (or ut-sally!smoot, who has a good version
as well).

Unfortunately, there is still a significant bug in troff, and it frankly has 
me stumped for a fix. Since I was able to get around it, I am dropping it for
now, but I want to publicize it both as a warning and as a plea for a fix. 

I was having a real problem with [nt]roff aborting under -mm with the 
'Bad Storage Allocation' error message, which indicates that the internal
tables are garbaged. From everything I can tell, this simply isn't true. 
This bug seems to be a special case with the following properties:

	The macro is longer than one alloc() block (forcing an indirect
	pointer to be stored in blist[]).

	It is defined as a trap macro (.wh) or is called by a macro defined
	as a trap macro.

	As part of its processing, it deletes itself.

	It helps if there are some undefined macros being called in there
	somewhere (which should nop, of course).

As far as I can tell, something deep inside getch0() (I suspect something in
either rbf0() or the push/pop code) doesn't properly let go of a pointer
to this macro, because after the macro is executed and deleted, when the 
trap returns, the (now deleted) macro is executed again. When it tries to
skip to the second block of the macro, it accesses blist for the pointer, 
which no longer exists, hence the error message and abort. 

That isn't the only way this seems to pop up, but it invariably happens
under control of traps when there are funny or undefined macros hanging
around (my hangup on the mm manual was a missing file that didn't define a
single macro that happened to be called about three levels deep in a trap.
when I found and installed it, it started working again). 

This is a very special case bug, so I don't hold out much hope for it being
fixed any time soon. Getting it to show up is hard enough, but I thought I
should let the world know about it in case it shows up somewhere else. As
far as I can tell, it is in both 4.1 and 4.2. 

chuq



-- 
>From behind the bar at Callahan's:	Chuq Von Rospach
{fortune,menlo70}!nsc!chuqui

Just when you decide you know everything, they go and change reality again.



More information about the Comp.unix.wizards mailing list