bugGNU roff - Bugs: bug #61100, [troff] do_request(): assertion...

 
 

bug #61100: [troff] do_request(): assertion failed: 'do_old_compatible_flag == -1'

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Wed 01 Sep 2021 08:59:57 AM UTC
   
 
Category:  Core Severity:  4 - Important
Item Group:  Crash/Unresponsive Status:  None
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Thu 28 Oct 2021 05:41:15 AM UTC, comment #7: 

I'm not actively working on this (unfortunately).

G. Branden Robinson <gbranden>
Group administrator
Sat 04 Sep 2021 06:13:36 PM UTC, comment #6: 

comment #5:

> comment #4:


> > @code{de} defines a macro that inherits the compatibility mode
> > enablement status of its context (@pxref{Implementation Differences}).


>
> The above seems to say that the defined macro runs in the compatibility state in which it is invoked, while...
>


> > compatibility mode needs to be switched off while such a macro is
> > interpreted---without disturbing that state when it is finished.


>
> ...this seems to say the defined macro runs in a fixed compatibility state regardless of that of its invoker.
>
> The problem may be the overloading of the word "context"?


I think the problem may be that I left out too much...context!


@code{de} defines a macro that inherits the compatibility mode
enablement status of its context (@pxref{Implementation Differences}).
Often it is desirable to make a macro that uses @code{groff} features
callable from contexts where compatibility mode is on; for instance,
when writing extensions to a historical macro package.  To achieve this,
compatibility mode needs to be switched off while such a macro is
interpreted---without disturbing that state when it is finished.


The foregoing paragraph follows the lengthy presentation of `de` in detail, and is present not just to articulate the foregoing points but to motivate the very next thing presented...`de1`, which creates a macro that switches off compatibility mode as described.

> Its second appearance specifically says "callable from contexts where...," so it's clear this is talking about the invoker's context.  The first instance may be talking instead about the context in which the macro is defined rather than that in which it is invoked.  That at least lets me mentally reconcile the above two quoted passages, but I'm not sure if it's the correct reading.  (I have little real-world experience with using compatibility mode, so much about it remains mysterious to me.)


The difference is that the first instance is describing the behavior of the request just presented, and the second is setting the reader up for a macro that behaves differently.

> I may be getting us lost in the weeds re: this bug's topic, so feel free to redirect this discussion to the email list or other alternate venue.


No, that's okay, I think the problem is simply that I was too terse with my presentation in Savannah.  If you get a chance to review the Texinfo manual subsequent to these changes, I'd appreciate hearing if you feel I've still left the point at issue murky.

Granted, there is still other murkiness cavorting about madly...

G. Branden Robinson <gbranden>
Group administrator
Sat 04 Sep 2021 05:45:50 PM UTC, comment #5: 

comment #4:

> @code{de} defines a macro that inherits the compatibility mode
> enablement status of its context (@pxref{Implementation Differences}).


The above seems to say that the defined macro runs in the compatibility state in which it is invoked, while...


> compatibility mode needs to be switched off while such a macro is
> interpreted---without disturbing that state when it is finished.


...this seems to say the defined macro runs in a fixed compatibility state regardless of that of its invoker.

The problem may be the overloading of the word "context"?  Its second appearance specifically says "callable from contexts where...," so it's clear this is talking about the invoker's context.  The first instance may be talking instead about the context in which the macro is defined rather than that in which it is invoked.  That at least lets me mentally reconcile the above two quoted passages, but I'm not sure if it's the correct reading.  (I have little real-world experience with using compatibility mode, so much about it remains mysterious to me.)

I may be getting us lost in the weeds re: this bug's topic, so feel free to redirect this discussion to the email list or other alternate venue.

Dave <barx>
Group Member
Thu 02 Sep 2021 02:56:43 PM UTC, comment #4: 

comment #2:

> comment #1:
> > In ".do while ...", the "do" is valid for the whole loop.
>
> Is this documented?  I don't find mention of it in the Texinfo manual.


Some language I just pushed, but had been working on since before I blundered into this bug, may provide part of the explanation.


@code{de} defines a macro that inherits the compatibility mode
enablement status of its context (@pxref{Implementation Differences}).
Often it is desirable to make a macro that uses @code{groff} features
callable from contexts where compatibility mode is on; for instance,
when writing extensions to a historical macro package.  To achieve this,
compatibility mode needs to be switched off while such a macro is
interpreted---without disturbing that state when it is finished.


Combine this with some older existing text...


The body of a @code{while} request is treated like the body of a
@code{de} request: GNU @code{troff} temporarily stores it in a macro
that is deleted after the loop exits.  It can considerably slow down a
macro if the body of the @code{while} request (within the macro) is
large.  Each time the macro is executed, the @code{while} body is parsed
and stored again as a temporary macro.


...and I think the consequence is implied.

I'll try a few different scenarios and see if just ditching the assertion is warranted; it might well be.
-verbatim-

G. Branden Robinson <gbranden>
Group administrator
Wed 01 Sep 2021 11:36:00 PM UTC, comment #3: 

I don't know.  I just found out, when I used a '.do' inside a '.do while' loop.

Bjarni Ingi Gislason <bjarniig>
Wed 01 Sep 2021 10:47:21 PM UTC, comment #2: 

comment #1:

> In ".do while ...", the "do" is valid for the whole loop.


Is this documented?  I don't find mention of it in the Texinfo manual.

Dave <barx>
Group Member
Wed 01 Sep 2021 01:56:12 PM UTC, comment #1: 

  In ".do while ...", the "do" is valid for the whole loop.

  A simple example to cause a core dump is

.\".cp 1
.pl 20v
.do do nr a 1
.\".do do .nr a 1
\na


Bjarni Ingi Gislason <bjarniig>
Wed 01 Sep 2021 08:59:57 AM UTC, original submission:  

Well, in attempting to "quickly" move a documentation item off my plate to look into John Garnder's assertion failure report in bug #61089, I wrote a little experiment to check my understanding of an issue and provoked an entirely new assertion failure.

Good times, good times.


$ ./build/groff -Tutf8 -ww EXPERIMENTS/compatibility_mode_de.groff | cat -s
troff: ../src/roff/troff/input.cpp:2651: do_request(): assertion failed: 'do_old_compatible_flag == -1'
/home/branden/src/GIT/groff/build/groff: error: troff: Aborted (core dumped)


Input:

$ cat EXPERIMENTS/compatibility_mode_de.groff
.cp 1
.de xx
.do length a \\$1
.nr c 0
.do while \\nc<=\\na \{\
.  do ds s \\$1
.  do substring s 0 \\nc
.  do nop \\*s
.\}
\\$1 Saint-\['E]tienne (\\na)
..
.cp 0
.xx Caf\['e]


The assertion is one I added when implementing the new \n[.cp] feature last year.  It might be that I simply didn't anticipate this use case last year and that I can remove the assertion without causing any harm.

Wouldn't that be nice?

I don't think I anticipated use of "do" within "de" within "cp 1", but in trying to check my understanding of when special character escape sequences get transformed into nodes, I blundered directly into my own land mine.

I have some thinking to do.

G. Branden Robinson <gbranden>
Group administrator

 

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

Attach Files:
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by gbranden (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 2 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-08-10 gbranden StatusPostponed None
    2021-10-28 gbranden StatusIn Progress Postponed

    Back to the top

    Powered by Savane 3.13-4448.
    Corresponding source code