[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug #61294] [ms]: Stuck in recursive page trap loop at short page lengt

From: Keith Marshall
Subject: [bug #61294] [ms]: Stuck in recursive page trap loop at short page length
Date: Tue, 5 Oct 2021 17:46:29 -0400 (EDT)
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:92.0) Gecko/20100101 Firefox/92.0


                 Summary: [ms]: Stuck in recursive page trap loop at short
page length
                 Project: GNU troff
            Submitted by: keithmarshall
            Submitted on: Tue 05 Oct 2021 09:46:27 PM UTC
                Category: Macro - ms
                Severity: 3 - Normal
              Item Group: Incorrect behaviour
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None



Consider the following:

$ cat foo.ms
.XH 0 Introduction

which I used to test a tentative implementation of XH, as proposed for
inclusion in s.tmac, in [bug #58946 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

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


File Attachments:

Date: Tue 05 Oct 2021 09:46:27 PM UTC  Name: ms-recursive-page-trap.patch 
Size: 828B   By: keithmarshall
Patch to defend against uncontrolled page trap recursion


Reply to this item at:


  Message sent via Savannah

reply via email to

[Prev in Thread] Current Thread [Next in Thread]