bugGNU roff - Bugs: bug #61294, [ms] stuck in recursive page trap...

 
 

bug #61294: [ms] stuck in recursive page trap loop at short page length

Submitter:  Keith Marshall <keithmarshall>
Submitted:  Tue 05 Oct 2021 09:46:27 PM UTC
   
 
Category:  Macro ms Severity:  3 - Normal
Item Group:  Incorrect behaviour Status:  Fixed
Privacy:  Public Assigned to:  keithmarshall
Open/Closed:  Closed Planned Release:  1.23.0
* Mandatory Fields

Add a New Comment Rich Markup
   

Sat 01 Apr 2023 03:09:11 PM UTC, comment #3: 


commit 8830820a9a85ad52a8452017d52e67378a76c4c4
Author: Keith Marshall <keith.d.marshall@ntlworld.com>
Date:   Sat Oct 23 21:56:31 2021 +0100

    [ms]: Defend against uncontrolled page trap recursion.

    * tmac/s.tmac (pg@top) [HM+FM+.V>.p]: Diagnose insufficient page
    length, and abort; cf. <https://savannah.gnu.org/bugs/?61294>


G. Branden Robinson <gbranden>
Group administrator
Sat 23 Oct 2021 09:31:13 PM UTC, comment #2: 

Fixed by commit #8830820

Keith Marshall <keithmarshall>
Group Member
Wed 06 Oct 2021 03:42:04 PM UTC, comment #1: 

original submission:

> Given that the sum of default header and footer margins, in ms, is equivalent to 12v, in nroff, it's hardly surprising that there is a problem with this example; at a page length of only 12v, there simply isn't any space to accommodate page content!  There's even a relevant comment, in s.tmac itself:


> .de cov*first-page-init
> .\" Invoked by '.wh 0' trap on first page.
> .\" We should not come here again, but at short page length,
> .\" recursion may occur; remove trap and macro to avoid it.
> .ch cov*first-page-init
> .rm cov*first-page-init


> This correctly identifies that a '.wh 0' page trap may induce a recursive loop, at short page length; the problem is that the workaround, here, only prevents recursion of the first-page trap — it completely neglects that similar recursion is just as likely to occur when a '.wh 0 pg@top' trap is assigned, and sprung on every subsequent page, with no defensive measures to prevent it.
>
> To mitigate this, we need to ensure that the specified page length, when the 'pg@top' trap is sprung, is no less than (u;'\n[HM]+\n[FM]+\n[.V])'; the attached patch addresses this


This is a good idea and I think all macro packages that plant default page location traps (which I think is all of the full-service ones) should do something like it.

I added something similar to me(7) a few months ago (bug #61034), but I computed the minimum permissible page length by trial and error.  Your approach is better (once the appropriate register names are identified).

G. Branden Robinson <gbranden>
Group administrator
Tue 05 Oct 2021 09:46:27 PM UTC, original submission:  

Consider the following:

$ cat foo.ms
.SH
.XH 0 Introduction
.TC

which I used to test a tentative implementation of XH, as proposed for inclusion in s.tmac, in ticket #58946.  If I run this thus, (as I — perhaps carelessly — initially did):

$ echo .pl 12v | nroff -ms - foo.ms

nroff gets stuck in a recursive page trap loop, until the macro call stack overflows.

Given that the sum of default header and footer margins, in ms, is equivalent to 12v, in nroff, it's hardly surprising that there is a problem with this example; at a page length of only 12v, there simply isn't any space to accommodate page content!  There's even a relevant comment, in s.tmac itself:

.de cov*first-page-init
.\" Invoked by '.wh 0' trap on first page.
.\" We should not come here again, but at short page length,
.\" recursion may occur; remove trap and macro to avoid it.
.ch cov*first-page-init
.rm cov*first-page-init

This correctly identifies that a '.wh 0' page trap may induce a recursive loop, at short page length; the problem is that the workaround, here, only prevents recursion of the first-page trap — it completely neglects that similar recursion is just as likely to occur when a '.wh 0 pg@top' trap is assigned, and sprung on every subsequent page, with no defensive measures to prevent it.

To mitigate this, we need to ensure that the specified page length, when the 'pg@top' trap is sprung, is no less than (u;'\n[HM]+\n[FM]+\n[.V])'; the attached patch addresses this

Keith Marshall <keithmarshall>
Group Member

 

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

Attach Files:
   
   
Comment:
   

Attached Files
file #52043:  ms-recursive-page-trap.patch added by keithmarshall (828B - text/x-patch - Patch to defend against uncontrolled page trap recursion)

 

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 keithmarshall (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 6 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-04-01 gbranden Planned ReleaseNone 1.23.0
        Summary[ms]: Stuck in recursive page trap loop at short page length [ms] stuck in recursive page trap loop at short page length
    2021-10-23 keithmarshall StatusNone Fixed
        Assigned toNone keithmarshall
        Open/ClosedOpen Closed
    2021-10-05 keithmarshall Attached File- Added ms-recursive-page-trap.patch, #52043

    Back to the top

    Powered by Savane 3.13-02a9.
    Corresponding source code