From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.3) Gecko/20010801

Description of problem:

run  file at the bottom through tex, and do 

	xdvi -debug 64 xbug

Notice the lines saying

	current scale 25.000000,25.000000:  gsave 5 5 scale grestore 
	drawbegin at 76,76:  sending ` gsave 5 5 scale grestore '
	end ps: 
	current scale 125.000000,125.000000:  gsave 5 5 scale grestore 
	drawbegin at 76,76:  sending ` gsave 5 5 scale grestore '
	end ps: 

Notice that the scale is going up for each ps special, but is not restored 
(grestore ends the scale).

After this, xdvi decides that glyph bitmaps should be scaled by 125x
(or more depending on the number of \specials), leading to an apparent
hang in bbox_scale_bitmap(g), when it tries to do a nested

  for (i =xmin ; i < xmax /* enormous number */; i ++)

loop in bbox_scale_bitmap(g).  In this process, xdvi consumes ungodly
amounts of CPU and memory.

This is caused by the redhat specific patch xdvik-22.15-j1.03.patch.gz,
which is responsible for both the code extracting scale from ps specials,
and bbox_scale_bitmap.

I suggest that this patch (or parts thereof) be retracted.


<rant>

WHAT THE HECK IS THIS MANURE DOING IN A WELL ENGINEERED PRODUCT?

For crying out loud, it is trying to deduce information by keyword
spotting in a turing complete language, and it is also is
undocumented. Maybe you guys can actually listen to the people
producing tetex and tex-k ?

See also http://www.tug.org/pipermail/tex-k/2001-April/004195.html
 
</rant>

<xbug.tex>

	\special{ps:  gsave 5 5 scale  grestore }
	\special{ps:  gsave 5 5 scale  grestore }
	\special{ps:  gsave 5 5 scale  grestore }
	\special{ps:  gsave 5 5 scale  grestore }
	\special{ps:  gsave 5 5 scale  grestore }
	\special{ps:  gsave 5 5 scale  grestore }
	\special{ps:  gsave 5 5 scale  grestore }
	foobar
	\bye

</xbug.tex>