[bug #65930] [me] large values of register `tv` cause infinite trap recursion

[Dave]

Follow-up Comment #11, bug #65930 (group groff):

Using the bug-65930b.me test file from comment #8, I can reproduce the problem
in groff 1.22.4; using tv-stack-limit.me from comment #2, I cannot.

$ groff --version | head -n 1
GNU groff version 1.22.4
$ cat bug-65930b.me
.\"mso e.tmac
.br
.nr $v 421
.fo 'foo'bar'baz'
.lp
You get the diplomatic treatment
.br
You get the force-fed future
.br
You get the funk after death
.br
You get the weisenheimer brainstorm
$ groff -z -me ./bug-65930b.me
troff: fatal error: input stack limit exceeded (probable infinite loop)
$ groff -z -me ./tv-stack-limit.me
$ diff tv-stack-limit.me bug-65930b.me
1c1,3
< .nr $v 1640u
---
> .\"mso e.tmac
> .br
> .nr $v 421

As I noted in the [comment #0 original submission], for me "the bug only
happens with the .br request present" (_before_ the .nr, I should have
clarified).  So the diff above, showing the absence of the triggering .br,
makes me not surprised to see the respective results above.

But I _am_ surprised that you're seeing the bug triggered in 1.22.4 with both
files (with and without the initial .br).

With my recent inability to reproduce a different bug using seemingly the same
input file and command invocation as the submitter (bug #65936), I have to
wonder if I've Bjarnied my system somehow.  I checked the obvious things, like
making sure I hadn't hacked on my 1.22.4 e.tmac file.  I do have various
modifications to local font files, but I can't see how those matter, and
indeed I get the same results even if I remove them.

So if you can confirm the bug shows up for you regardless of the
presence/absence of the .br before the .nr, then we need to dig into what
separates our 1.22.4s.  (Looking at an older release might seem like a wild
goose chase, but since I'm also seeing different results from you using the
patched -me on bleeding-edge groff, I think finding the difference between our
systems in an official release might be easier than finding what could be
different in independent new builds.)


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65930>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/

signature.asc
Description: PGP signature