Re: [groff] 1.18 mm: infinite loop with large vs

[Bill Brelsford]

On Thu Feb 02 2006 at 11:29 AM +0100, Werner LEMBERG wrote:
> > The following bug still exists in 1.19.2.  I've identified the
> > problem -- see below.
> 
> Sorry, but your analysis is wrong.
> 
> > >   .S 27 29
> > >   .SP
> > >   foo
> > >   .SK
> > > 
> > >    foo.tr:4: fatal error: input stack limit exceeded (probable
> > >                         infinite loop)
> > > 
> > >  Happens whenever vertical spacing is "too big".  With ".S 27 60"
> > >  ".SP" can be omitted -- only the "foo" line is needed to cause
> > >  looping.
> > 
> > In earlier versions, register pg*footer-size was set to 5 and
> > referenced as \\n[pg*footer-size]v.  In 1.18 it is set to 5v and
> > referenced as \\n[pg*footer-size]u.
> 
> Using `u' is correct!
> 
> > This doesn't work because the vertical spacing (v) can change by the
> > time the register is referenced.
> 
> It *does* work.  If you say `5v', groff automatically converts this to
> `u' units.  Please read section `Measurements' in the groff info
> manual for details.

It looks to me that the lines

  .nr pg*footer-size 5v\"                       1v+footer+even/odd footer+2v
  .nr pg*header-size 7v\"                       3v+header+even/odd header+2v

are executed when m.tmac is loaded, so 5v is converted to u units
based on the vertical spacing at that time.  ".S 27 29" later
changes the vertical spacing, but, when the address@hidden macro
is invoked, \n[pg*footer-size]u does not reflect that change.

At any rate, inserting the above two lines at the beginning of
address@hidden macro makes the problem go away.

But I'm too rusty/limited to understand all that's going
on here, so appreciate your looking into it..

> The very problem is that the footer trap is called within footer trap
> again.  You can verify this by yourself -- just say
> 
>   groff -rD9 -mtrace -mm foo.tr > foo.ps 2> foo.trace
> 
> to get a detailed trace of macro calls together with extensive mm
> debugging information.
> 
> J?rgen, can you help?
> 
> I poked around in the code a bit, but my knowledge of mm is too
> limited, and I wasn't able to fix it.  Disabling a second call of
> itself within the address@hidden macro doesn't work as expected (you now
> get three pages instead of two with the above input) -- maybe the trap
> should be executed within a different environment to protect against
> big vertical spacing values...

-- 
Bill Brelsford
address@hidden