bugGNU roff - Bugs: bug #24048, [mm] infinite loop with certain...

 
 

bug #24048: [mm] infinite loop with certain page lengths

Submitter:  Werner LEMBERG <wl>
Submitted:  Tue 12 Aug 2008 05:00:45 PM UTC
   
 
Category:  Macro mm Severity:  4 - Important
Item Group:  Crash/Unresponsive Status:  Fixed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Mon 03 Oct 2022 05:51:09 AM UTC, comment #9: 


commit 6c0f977d59a6d8aaa1d61e8eb709008cb312dfcb
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Oct 2 23:23:18 2022 -0500

    [mm]: Regression-test Savannah #24048.

    * contrib/mm/tests/short-pages-do-not-overflow-stack.sh: Test it.
    * contrib/mm/mm.am (mm_TESTS): Run test.

    Test fails at this commit.

commit 4610c23c0faf22e76965c28321516f35c82fb627
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sun Oct 2 23:35:19 2022 -0500

    [mm]: Fix Savannah #24048.

    * contrib/mm/m.tmac (pg@header): Add page length sufficiency check.

    Fixes <https://savannah.gnu.org/bugs/?24048>.  Thanks to Werner Lemberg
    for the report.

    See commits 2a6b7bb4b0 and f6fcbba95c, both 2 February, for similar work
    on ms(7) and me(7).


G. Branden Robinson <gbranden>
Group administrator
Tue 15 Mar 2022 10:03:14 AM UTC, comment #8: 

I don't find comment #7 helpful to this discussion.

comment #7:

>   I find these page length tests unnecessary


The above is the most useful part of the response.

> 1) The page length is a constant.


Not necessarily.  Some real-world documents change the media size in medias res, if you will.  Probably the most common example is a change of orientation (portrait<->landscape); while one can argue whether this changes the "size" of the output medium, it certainly changes the page length to a *roff formatter.

> 2) The error of a wrong page length is immediately visible.


But it may not be immediately comprehensible.  Our users are sometimes impatient folk.

> 3) The test deprives the users of an experience.


This is one of the worst counterarguments.

Only an immortal being can crave all possible experiences.
 

> 4) The test sabotages experimentation.


Any experimenter worth their salt should be able to disable the check in the macro package source, or they can come to the groff@ mailing list or other forum and ask for expert help doing it.

> 5) The test sabotages evolution from a typewriter situation to a high
> resolution output devices.


How so?  The page length is not forced to a coarse, discretized value (not more coarse than the output device can support, anyway).  All that is happening is a comparison of magnitudes.  Your page length can be 0 basic units larger than the minimum required size, or 1, or 14,596.

> 6) The test is executed every time the macro is run, although errors
> have been corrected.


This is worth consideration if the test proves expensive relative to the rest of processing.  Have you profiled it?

Do you have an argument from complexity analysis?  The check runs once per page header, so once per page, and contains no loop.  It is therefore O(n) in the number of pages.

Linear contributors to time or space consumption are not often the wisest place to start attacking performance problems.

> 7) Not economical.


What does this mean?  Does it say anything you're not already communicating in point 6?

> 8) It cements status quo.


How?  Here's the implementation from groff me(7), in Git HEAD.


.de @h                  \" --- header
.if \n@>1 .tm >> @h %=\\n% ?a=\\n(?a ?b=\\n(?b ?w=\\n(?w
.do if (u;\\n(tm+\\n(bm+\\n(.V>\\n(.p) \{\
.       do @err insufficient page length; aborting
.       pl \\n(nlu
.       ab
.\}


You can see that the page length (register `.p`) is being compared not to a fixed value, but to the current vertical spacing `.V` (roughly, "line height"), and to the user-configurable top and bottom margins (`tm` and `bm` respectively).

All of these parameters are configurable in various ways.  The only numeric literal we see is used for emitting debugging output.

In summary, what are on earth are you talking about?

> 9) Is not based on cost analysis.


What cost do you claim to be measuring?  Are you responsible for paying it?  This is a volunteer project.

> 10) Is not based on examination of all consequences.


Outside of solved games[1], what decision is?

This sort of argumentation is not persuasive.  Try a different tack.

Regards,
Branden

[1] https://en.wikipedia.org/wiki/Solved_game

G. Branden Robinson <gbranden>
Group administrator
Thu 17 Feb 2022 01:30:56 AM UTC, comment #7: 

  I find these page length tests unnecessary

1) The page length is a constant.

2) The error of a wrong page length is immediately visible.

3) The test deprives the users of an experience.

4) The test sabotages experimentation.

5) The test sabotages evolution from a typewriter situation to a high
resolution output devices.

6) The test is executed every time the macro is run, although errors
have been corrected.

7) Not economical.

8) It cements status quo.

9) Is not based on cost analysis.

10) Is not based on examination of all consequences.

Bjarni Ingi Gislason <bjarniig>
Tue 15 Feb 2022 07:44:19 AM UTC, comment #6: 

We've made ms and me spit out insufficiently short page lengths.  I propose we do the same for mm to resolve this.

Would someone with a knowledge of the registers mm uses for vertical measurements of the page margins and text area and/or line height/vertical spacing like to draft a patch along the lines of the foregoing?

G. Branden Robinson <gbranden>
Group administrator
Mon 14 Feb 2022 11:42:22 PM UTC, comment #5: 

  The mm-macros use the register 'L' (on the command line) or an
argument to the .PGFORM macro for page length.

  They use internally the register '@pl'.

  Using ".pl ..." in the input file just sets register '.p'
which does not affect register '@pl', as the macro file has already
been read.

  Changing "-r PL=" to "-r L=' runs the the example script error-free
until the page becomes shorter than reasonable.

  When using macro-packages, users should not use low level requests or
registers.

Bjarni Ingi Gislason <bjarniig>
Sat 17 Jul 2021 09:38:45 PM UTC, comment #4: 

I get two distinct backtrace patterns.

For the PL < 1.3i case I'm wondering if we shouldn't just have the macro package give up and refuse to work for such a short length.  At that size you're not formatting a document, you're formatting a business card (or, really, a postage stamp) or something like that, and mm just was not designed for that.

Anyway the problem in that case is a simple recursive trap.


troff: backtrace: '/.../../contrib/mm/m.tmac':1151: string 'pg*header'
troff: backtrace: '/.../../contrib/mm/m.tmac':1279: trap-called macro 'pg@header'
troff: backtrace: '/.../../contrib/mm/m.tmac':1283: trap-called macro 'pg@header'
[many repeats]
troff: backtrace: '/.../../contrib/mm/m.tmac':1283: trap-called macro 'pg@header'
troff: backtrace: 'smaller-test.mm':2
troff: backtrace: file 'smaller-test.mm':2
troff: smaller-test.mm:2: fatal error: input stack limit exceeded (probable infinite loop)


I note the above for completeness.  The 10.3i and 10.4i case is more interesting, with the headers and footers calling into each other.


troff: backtrace: '/.../../contrib/mm/m.tmac':2019: macro 'ds@print-this-page'
troff: backtrace: '/.../../contrib/mm/m.tmac':1952: macro 'df@print-float'
troff: backtrace: '/.../../contrib/mm/m.tmac':1306: trap-called macro 'pg@header'
troff: backtrace: '/.../../contrib/mm/m.tmac':1324: trap-called macro 'pg@footer'
troff: backtrace: '/.../../contrib/mm/m.tmac':1370: macro 'pg@print-footer'
troff: backtrace: '/.../../contrib/mm/m.tmac':1331: trap-called macro 'pg@footer'
[the above 2 lines repeat]
troff: backtrace: '/.../../contrib/mm/m.tmac':1331: trap-called macro 'pg@footer'
troff: backtrace: file 'smaller-test.mm':6
troff: smaller-test.mm:6: fatal error: input stack limit exceeded (probable infinite loop)



G. Branden Robinson <gbranden>
Group administrator
Sat 17 Jul 2021 09:28:55 PM UTC, comment #3: 

I can reproduce this bug, but not with the original problematic page lengths.

Input document:

.if r PL .pl \n[PL]u
\&
.sp 2i
test 1
.br
.bp
\&
.sp 2i
test 2
.br


Reproducer:

$ for W in $(seq 10 -1 1); do for F in $(seq 9 -1 0); do ./build/test-groff -Tutf8 -mm -rPL=$W.${F}i smaller-test.mm >/dev/null || echo $W.${F}i is bad; done; done
troff: smaller-test.mm:6: fatal error: input stack limit exceeded (probable infinite loop)
10.4i is bad
troff: smaller-test.mm:6: fatal error: input stack limit exceeded (probable infinite loop)
10.3i is bad
troff: smaller-test.mm:2: fatal error: input stack limit exceeded (probable infinite loop)
1.2i is bad
troff: smaller-test.mm:2: fatal error: input stack limit exceeded (probable infinite loop)
1.1i is bad
troff: smaller-test.mm:2: fatal error: input stack limit exceeded (probable infinite loop)
1.0i is bad


The above is groff Git HEAD, but groff 1.22.4 fails for exactly the same page lengths (and no others from the input set).

G. Branden Robinson <gbranden>
Group administrator
Wed 14 Apr 2021 07:36:19 AM UTC, comment #2: 

[Mike Bianchi asked (http://lists.gnu.org/archive/html/groff/2021-02/msg00077.html) who maintains the mm macros, implying it's not him (although he didn't respond to a direct query about this (http://lists.gnu.org/archive/html/groff/2021-04/msg00019.html)).  Thus I'm unassigning this mm bug.]

Dave <barx>
Group Member
Fri 27 Nov 2020 09:23:05 PM UTC, comment #1: 

Subject: #24048

  The testfile produces expected output, without any warning.

Can anybody reproduce this "bug"?

  I know, wenn there is not enough space for a footer (for example short
page), the stack gets overfilled.

Bjarni Ingi Gislason <bjarniig>
Tue 12 Aug 2008 05:00:45 PM UTC, original submission:  

.\" $Id: m.tmac,v 2.24 2004/03/10 06:11:26 wlemb Exp $

With mm default setup, get "input stack limit exceeded" upon page break for range of page lengths:
.pl 10.2i to .pl 10.6i

[.pl 10.5i is for executive paper, which I use].

If format same text without mm macros (straight troff), there is no problem.

The description of the VM command in the groff_mm man page suggests you have met this problem already -- shrinking of the page footer size gives "input stack limit exceeded" behavior for the default page length, .pl 11.0i.

The attached file shows the above behaviour when run through the troff formatter.

Werner LEMBERG <wl>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #16284:  test-bp-inf-loop.mm added by wl (1KiB - text/x-troff-mm)

 

Depends on the following items: None found

Items that depend on this one: None found

 

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

    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 15 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2022-10-03 gbranden Severity3 - Normal 4 - Important
    2022-10-03 gbranden StatusIn Progress Fixed
        Open/ClosedOpen Closed
        Planned ReleaseNone 1.23.0
    2022-10-03 gbranden StatusConfirmed In Progress
        Assigned toNone gbranden
    2021-06-04 barx Carbon-CopyRemoved 93119 -
    2021-06-04 barx Summarymm macros -- infinite loop with certain page lengths [mm] infinite loop with certain page lengths
    2021-04-14 barx Carbon-CopyRemoved 93119 -
    2021-04-14 barx Assigned tombianchi None
    2018-02-16 schwarze CategoryNone Macro mm
        Item GroupNone Crash/Unresponsive
        StatusNone Confirmed
    2008-08-12 wl Attached File- Added test-bp-inf-loop.mm, #16284
        Carbon-Copy- Added john rupley <rupley@u.arizona.edu>

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code