bugGNU roff - Bugs: bug #58447, [me] footnote overflow can create...

 
 

bug #58447: [me] footnote overflow can create infinite trap recursion

Submitter:  Dave <barx>
Submitted:  Tue 26 May 2020 05:39:13 PM UTC
   
 
Category:  Macro me Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Need Info
Privacy:  Public Assigned to:  None
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 26 Jul 2023 09:38:05 PM UTC, comment #10: 

Minor clarifications and updates:

original submission:

> Groff 1.22.3 fails immediately with this error.  The latest
> groff code from git eventually fails with this error after
> emitting a few thousand lines of backtrace messages.


Groff 1.23 fails in the same way as reported for 1.22.3 above.  The backtrace lines I observed were likely not any difference in groff, but in the test-groff script, where such messages were turned on by default before 1.22.4 (commit 655e5020, reverted in 2021's commit 5aaf04cd).

> Triggering the bug seems to require specific combinations of
> values in the -me registers tp, tm, and $v,


While commit 47600ca4 renamed -me's $v register, the old name is currently supported for back compatibility, so the attached test still demonstrates the bug without modification.

comment #2:

> With the fixes in bug report #55081 and bug report #58736
> I do not get any errors.


Bug #55081 and bug #58736 both have fixes that made it into groff 1.23, but the current bug remains.  Part of what #58736 reported endues as bug #63176 (to which Branden has been patiently awaiting my response for nearly a year).

Dave <barx>
Group Member
Fri 07 Oct 2022 07:41:42 AM UTC, comment #9: 

comment #6:

> there is different breakage when rendering the same document
> with nroff--there's no infinite trap recursion, but the text
> of the footnote is truncated and the document ends prematurely.


Filed as bug #63163.

Dave <barx>
Group Member
Thu 23 Dec 2021 04:47:37 AM UTC, comment #8: 

comment #1:

> [to trigger the bug in Heirloom] $v need not be set at all.


This stands to reason in light of Branden unearthing (in bug #61683) that $v and $V are groffisms.  (Had I looked, I could have deduced the same thing from seeing that neither register name appears in Heirloom's e.in.)

Dave <barx>
Group Member
Thu 23 Dec 2021 04:27:21 AM UTC, comment #7: 

comment #6:

> Probably, there should be a limit as to how far up the page the
> footnote is allowed to retreat.  What that limit should be is
> another question; the first text baseline (\n(tm) is probably
> an absolute limit, but it might make sense to halt footnote
> retreat "earlier" (farther down the page) than that, so that
> progress can be made rendering the body text on any given page.


How to handle unusual layouts like this is probably highly situationally dependent, so giving the user a knob to control that height makes sense.

But the knob still needs a default setting, and for that, my inclination would be to give the footnote as much of the page as it can gobble up: a footnote that voluminous is probably more legible spread across fewer pages, otherwise there are two separate threads (running text and footnote) going on at once, and spreading this out over more pages seems less legible--maybe even more so in electronic texts, which typically display one page at a time, than in printed matter that shows two.  But that's an off-the-cuff analysis; I have no knowledge of how epic footnotes were historically typeset.

Dave <barx>
Group Member
Sun 19 Dec 2021 10:54:40 AM UTC, comment #6: 

Possibly related, or possibly not, there is different breakage when rendering the same document with nroff--there's no infinite trap recursion, but the text of the footnote is truncated and the document ends prematurely.

Same output on groff 1.22.4 and Git HEAD.


$ groff -Tascii -me ./EXPERIMENTS/exceed-stack-limit-49178.me | cat -s | tail -n 20
           x

____________________
tensive footnote text.
Alternately,      this
filler text is filling
in  as  the  extensive
footnote text.  Alter-
nately,  this   filler
text  is filling in as
the extensive footnote
text.     Alternately,
this  filler  text  is
filling  in as the ex-
tensive footnote text.
Alternately,      this
filler text is filling
in  as  the  extensive
footnote text.  Alter-


My wild-ass guess is that at least the originally reported problem is due to a missing bounds check when the `(f` macro sets up a trap for an overflow footnote.  Probably, there should be a limit as to how far up the page the footnote is allowed to retreat.  What that limit should be is another question; the first text baseline (\n(tm) is probably an absolute limit, but it might make sense to halt footnote retreat "earlier" (farther down the page) than that, so that progress can be made rendering the body text on any given page.

I've seen some prodigiously long footnotes in my time, but I've also read books that were typeset a century ago or more.  I'm not sure what style guidance still exists for management of overflowing footnotes; since the Linotype era, which our friend at Heraclitean River characterized as ushering an age of loss of craft and cheap labor in typesetting, footnotes have been progressively eschewed by publishers.  As I've noted in earlier vituperations against Russell Harper, there is no reason we can't recover from the nadir of artful typography brought on in the late pre-digital era.  So I'm open to suggestions regarding how we might parameterize the magnitude of footnote overflow areas.

G. Branden Robinson <gbranden>
Group administrator
Sat 21 Aug 2021 10:50:01 PM UTC, comment #5: 

  My statement in comment #2 must have been for "nroff" as I confirmed
the bug with test-groff.

  The reason for this bug is a lack of space for the title header,
the title hits the next trap (footer) before the output line is reached.

  A possible fix is to add a test for the needed space before the title
is output, in macro $h, before "'tl \\*(|z":

.if \\n(.tu<1v .ab \n[.F]:\n(.c:\\$0: not enough space for the header title


Bjarni Ingi Gislason <bjarniig>
Fri 20 Aug 2021 07:51:54 PM UTC, comment #4: 

And, likewise, further testing has shown that the fix offered in bug #58736 is also not valid.

Dave <barx>
Group Member
Fri 20 Aug 2021 10:42:34 AM UTC, comment #3: 

comment #2:

> With the fixes in bug report #55081 and bug report #58736
> I do not get any errors.


Further testing has shown that the fix offered in bug #55081 is not valid.  But perhaps whatever fix is ultimately made there will also solve this bug as a side effect.

Dave <barx>
Group Member
Tue 10 Aug 2021 02:05:58 AM UTC, comment #2: 

  With the fixes in bug report #55081 and bug report #58736 I do not get any errors.

Bjarni Ingi Gislason <bjarniig>
Fri 02 Apr 2021 08:08:11 AM UTC, comment #1: 

A variant of this bug (triggered by slightly different limits of some of the parameters*) exists in Heirloom troff's -me macros.  Since Heirloom and groff share no code base, but both projects' -me macro set are forks of Eric Allman's original set, this strongly suggests the bug is in common -me code.

According to the header blocks of the respective files, groff's -me macros are forked from version 2.31 (http://svnweb.freebsd.org/csrg/share/me/tmac.orig_me?revision=34394&view=markup) of Eric Allman's, and Heirloom's from version 2.14 (http://svnweb.freebsd.org/csrg/share/me/tmac.orig_me?revision=5313&view=markup).

* Specifically, tp must be 15 or greater, and $v need not be set at all.  The footnote text must also be extended by a couple more lines.

Dave <barx>
Group Member
Tue 26 May 2020 05:39:13 PM UTC, original submission:  

The attached input file, which uses the -me macro set, results in


stack_limit_bug:41: fatal error: input stack limit exceeded (probable infinite loop)


Groff 1.22.3 fails immediately with this error.  The latest groff code from git eventually fails with this error after emitting a few thousand lines of backtrace messages.

The file itself is linear, with one diversion (in the form of the macro pair ".(f" and ".)f") but no loops, so the error must come from the -me macro set.

groff fails with this error for the default output device (-Tps) and for -Tpdf, but not for -Tascii or other TTY output formats.

I've been unable to make the example any simpler.  Triggering the bug seems to require specific combinations of values in the -me registers tp, tm, and $v, as documented in the comments within the attached file, along with a header defined by the .he macro (its contents don't seem to matter, but it must be present to trigger the bug) and a footnote long enough to span a page break.

Dave <barx>
Group Member

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #49178:  stack_limit_bug added by barx (2KiB - application/octet-stream - sample groff input file to demonstrate the stack limit violation)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by gbranden (Updated the item)
  • -email is unavailable- added by barx (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only logged-in users can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2021-12-24 gbranden Summary[me] valid input with specific parameters causes a fatal error [me] footnote overflow can create infinite trap recursion
    2021-12-19 gbranden StatusNone Need Info
    2021-06-04 barx Summaryme macros: valid input with specific parameters causes a fatal error [me] valid input with specific parameters causes a fatal error
    2020-07-25 gbranden CategoryMacro - others/general Macro me
    2020-05-26 barx Attached File- Added stack_limit_bug, #49178

    Back to the top

    Powered by Savane 3.13-f8d8.
    Corresponding source code