bugGNU roff - Bugs: bug #62040, [troff] audit mtsm/statem memory...

 
 

bug #62040: [troff] audit mtsm/statem memory usage

Submitter:  G. Branden Robinson <gbranden>
Submitted:  Sat 12 Feb 2022 08:04:29 AM UTC
   
 
Category:  Core Severity:  4 - Important
Item Group:  Crash/Unresponsive Status:  Confirmed
Privacy:  Public Assigned to:  gbranden
Open/Closed:  Open Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Wed 25 Jan 2023 08:24:22 AM UTC, comment #16: 

If we translate the reproducer into an ms(7) document, no problem arises.


$ cat EXPERIMENTS/54909b-for-ms.ms
.NH 1
.DS
display
.DE
$ groff -ms -Thtml EXPERIMENTS/54909b-for-ms.ms && echo good exit status
<!-- Creator     : groff version 1.22.4 -->
<!-- CreationDate: Wed Jan 25 08:23:07 2023 -->
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"
"http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<meta name="generator" content="groff -Thtml, see www.gnu.org">
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<meta name="Content-Style" content="text/css">
<style type="text/css">
       p       { margin-top: 0; margin-bottom: 0; vertical-align: top }
       pre     { margin-top: 0; margin-bottom: 0; vertical-align: top }
       table   { margin-top: 0; margin-bottom: 0; vertical-align: top }
       h1      { text-align: center }
</style>
<title></title>
</head>
<body>

<a href="#1.">1.</a><br>

<hr>


<h2>1.
<a name="1."></a>
</h2>


<p style="margin-left:8%; margin-top: 1em">display</p>
<hr>
</body>
</html>
good exit status


This suggests that mm is doing, perhaps in the environment created for the display, is leading "mtsm" astray.

G. Branden Robinson <gbranden>
Group administrator
Wed 25 Jan 2023 08:20:31 AM UTC, comment #15: 

Commenting out what is presently line 2251 in "m.tmac" prevents the problem from arising.


.ds*div!\\n[ds*snr]


Unfortunately all this does is emit a diversion (the stored display); it completely defeats the purpose of the `DS`/`DE` macros.  It seems the problem really must be in the formatter, lurking somewhere in "mtsm.cpp".  :-(

G. Branden Robinson <gbranden>
Group administrator
Wed 25 Jan 2023 07:44:06 AM UTC, comment #14: 


comment #11:

> Maybe I can add a linear scan to the stack object to check for previously used pointers and die there; I'm hopeful that the performance hit will be negligible (and in any event, only -Thtml users will pay it).  Then the formatter may bomb at a more revealing point when processing the input, instead of long after, when cleanup and exit is taking place.


Nope, that didn't smoke it out either.

G. Branden Robinson <gbranden>
Group administrator
Wed 25 Jan 2023 07:27:48 AM UTC, comment #13: 


> Another possibility is to comment out the same line that Jeff did and see if that makes the problem go away; if it does, then the foregoing may be unnecessary, as the culprit will be narrowed down.


The line in question was:


diff --git a/contrib/mm/m.tmac b/contrib/mm/m.tmac
index 0a5ab82b0..7b0b27ee8 100644
--- a/contrib/mm/m.tmac
+++ b/contrib/mm/m.tmac
@@ -809,7 +809,7 @@ in=\\n[.i] fi=\\n[.u] .d=\\n[.d] nl=\\n[nl] pg=\\n[%]
 .      sp -1
 .\}
 .sp -1
-\h'\\n[misc*.k]u'\c
+.\"\h'\\n[misc*.k]u'\c
 .rr misc*.k
 .vpt 1
 .\}


This makes no difference to the double-free.

G. Branden Robinson <gbranden>
Group administrator
Wed 25 Jan 2023 07:25:03 AM UTC, comment #12: 

I added Jeff Conrad to the CC list since after 4 years and 3 months, someone is finally looking into his report.

G. Branden Robinson <gbranden>
Group administrator
Wed 25 Jan 2023 07:19:31 AM UTC, comment #11: 

Back in 2018, Jeff Conrad reported a problem with groff mm (the second item in bug #54909) that seems related to this.

He observed bad vertical spacing in a well-formed mm document when formatting for the HTML device.

I've trimmed out the other issue, which was a macro package bug for which I have a fix pending.

original submission:

> Computer: Core-i7 6700, 32 GB RAM
> OS: Windows 10 Pro, version 1803, 64 bit
> Environment: MKS Toolkit, version 10.0
> groff version: 1.22.3, Windows binary distribution
>                (https://sourceforge.net/projects/ezwinports/files/groff-1.22.3-3-w32-bin.zip)
>


> There seem to be a couple of bugs in the mm macro package (file m.tmac):

[...]

> 0  If a list or display follows a heading, there is considerable extra vertical space between the heading and the list or display.
>
> I just discovered these issues because for the last 20 years, I was using a modified version of AT&T mm (which worked fine after I made sure that requests were followed by whitespace; I may have had to make a few other changes, but not many).
>

[...]

> = Extra Vertical Space =
> For the extra vertical space, the problem seems to result from the line
>


>     \h'\\n[misc*.k]u'\c


>
> near the end of the macro misc@tag, which is called at the end of macro H.  This seems to generate something that is forced out when the br request is given at the beginning of macro SP.
>
> Offhand, I don’t have a fix.  To be honest, I don’t really understand what is happening with the generation of HTML tags.  But—at least with mm—the results I get from Thtml aren’t very good, so I’ve just commented out the call to misc@tag.  Although it solves my problem, it clearly isn’t a general solution.


The news gets worse.  In both groff 1.22.4 and Git HEAD, the problem no longer seems to be (just?) excess vertical space but an outright crash in the formatter.

Here is a minimal reproducer.  A display has to follow a heading, and the `DE` call is essential; leave it out, and mm's unclosed diversion handling avoids the problem.  Also, the display MUST have some content.


$ cat EXPERIMENTS/54909b.mm
.H 1
.DS
display
.DE


The crash does not occur until the formatter is exiting.  A double-free occurs in the mtsm ("mini-troff state machine") destructor, a feature that is only used with HTML output.


Core was generated by `troff -b -ww -mm -dwww-image-template=grohtml-9560- -Thtml'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
##(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007f36aceaa537 in __GI_abort () at abort.c:79
#2  0x00007f36acf03768 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7f36ad0213a5 "%s\n") at ../sysdeps/posix/libc_fatal.c:155
#3  0x00007f36acf0aa5a in malloc_printerr (str=str@entry=0x7f36ad0236f0 "free(): double free detected in tcache 2") at malloc.c:5347
#4  0x00007f36acf0c055 in _int_free (av=0x7f36ad057b80 <main_arena>, p=0x5568fb85d5b0, have_lock=0) at malloc.c:4201
#5  0x00005568fab7d5ea in sfree (ptr=<optimized out>) at ../src/libs/libgroff/string.cpp:46
#6  0x00005568fab7d815 in string::~string (this=<optimized out>, __in_chrg=<optimized out>) at ../src/libs/libgroff/string.cpp:126
#7  0x00005568fab633bb in string_value::~string_value (this=<optimized out>, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:141
#8  0x00005568fab63849 in statem::~statem (this=0x5568fb920a00, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:199
#9  0x00005568fab64184 in stack::~stack (this=0x5568fb85d1d0, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:357
#10 0x00005568fab6424e in mtsm::~mtsm (this=<optimized out>, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:372
#11 0x00005568fab69a31 in output_file::~output_file (this=this@entry=0x5568fb7ebc20, __in_chrg=<optimized out>) at ../src/roff/troff/node.cpp:1631
#12 0x00005568fab69cf4 in real_output_file::~real_output_file (this=this@entry=0x5568fb7ebc20, __in_chrg=<optimized out>)
    at ../src/roff/troff/node.cpp:1667
#13 0x00005568fab69d97 in troff_output_file::~troff_output_file (this=0x5568fb7ebc20, __in_chrg=<optimized out>)
    at ../src/roff/troff/node.cpp:1586
#14 0x00005568fab69dc0 in troff_output_file::~troff_output_file (this=0x5568fb7ebc20, __in_chrg=<optimized out>)
    at ../src/roff/troff/node.cpp:1589
#15 0x00005568fab3ef97 in cleanup_and_exit (exit_code=exit_code@entry=0) at ../src/roff/troff/div.cpp:567
#16 0x00005568fab3f133 in top_level_diversion::begin_page (this=this@entry=0x5568fb722b50, n=...) at ../src/roff/troff/div.cpp:582
#17 0x00005568fab3f6a4 in top_level_diversion::space (this=0x5568fb722b50, n=..., forced=<optimized out>) at ../src/roff/troff/hvunits.h:110
#18 0x00005568fab6034b in exit_troff () at ../src/roff/troff/input.cpp:2616
#19 0x00005568fab60fcd in main (argc=6, argv=0x7fff77b0dad8) at ../src/roff/troff/input.cpp:8279


I instrumented the `mtsm` class to detect a recursive call to the destructor but did not find one.  My guess at this point is that it is a possible for a cycle to be created in the stack of `state` objects that `mtsm` maintains.


#9  0x00005568fab64184 in stack::~stack (this=0x5568fb85d1d0, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:357
357         delete state;
##(gdb) list
352     }
353
354     stack::~stack()
355     {
356       if (state)
357         delete state;
358       if (next)
359         delete next;
360     }
361


Somehow mm is able to accomplish this.  I suspect absent input validation somewhere.

Despite its formal importance I have some doubt whether I'll be able to fix this for groff 1.23.  Maybe I can add a linear scan to the stack object to check for previously used pointers and die there; I'm hopeful that the performance hit will be negligible (and in any event, only -Thtml users will pay it).  Then the formatter may bomb at a more revealing point when processing the input, instead of long after, when cleanup and exit is taking place.

Another possibility is to comment out the same line that Jeff did and see if that makes the problem go away; if it does, then the foregoing may be unnecessary, as the culprit will be narrowed down.

G. Branden Robinson <gbranden>
Group administrator
Sun 15 May 2022 09:11:05 AM UTC, comment #10: 


commit ab0793f5cadb8dbcb84cb49d59bc31855fd8b5ac
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Sat May 14 23:32:14 2022 -0500

    [grohtml]: Mitigate Savannah #62040.

    [grohtml]: Mitigate double-free problem exposed by malformed input.

    * src/roff/troff/mtsm.h (struct statem): Place member variable
      `issue_no` behind `DEBUGGING` preprocessor symbol, omitting it
      from production and ordinary development builds.

    * src/roff/troff/mtsm.cpp (no_of_statems): Place global variable
      behind `DEBUGGING` preprocessor symbol, omitting it from production
      and ordinary development builds.

      (statem::statem): Make constructor trivial if `DEBUGGING` not defined
      in preprocessor; it manipulates only `issue_no` and `no_of_statems`,
      which are synchronized.

      (statem::statem {copy}): Gate assignment of `issue_no` member variable
      from copy constructor behind `DEBUGGING` preprocessor symbol.

      (statem::flush, mtsm::inherit): Gate debugging output, already
      runtime-gated on `debug_state` symbol, of `issue_no` member variable,
      so that we don't reference it when it is not declared.

    See <https://savannah.gnu.org/bugs/?62040>.


G. Branden Robinson <gbranden>
Group administrator
Sun 15 May 2022 05:34:29 AM UTC, comment #9: 

Thanks for the follow-up, Bjarni.

I have a mitigation for this that I'll be pushing soon; by "mitigation", I mean that the SEGV no longer happens.  This will enable the severity to be lowered to "normal", or perhaps "minor".

I do not regard the problem as root-caused yet, and I'm not confident that your explanation is a correct one.  Yes, any exiting Unix process gets all its memory freed, but that's not a reason to be careless with memory.  When we're done with heap-allocated memory, we should delete or free it.  A double free is usually a bug.


commit ab0793f5cadb8dbcb84cb49d59bc31855fd8b5ac
Author:     G. Branden Robinson <g.branden.robinson@gmail.com>
AuthorDate: Sat May 14 23:32:14 2022 -0500
Commit:     G. Branden Robinson <g.branden.robinson@gmail.com>
CommitDate: Sat May 14 23:34:49 2022 -0500

    [grohtml]: Mitigate Savannah #62040.

    [grohtml]: Mitigate double-free problem exposed by malformed input.

    * src/roff/troff/mtsm.h (struct statem): Place member variable
      `issue_no` behind `DEBUGGING` preprocessor symbol, omitting it
      from production and ordinary development builds.

    * src/roff/troff/mtsm.cpp (no_of_statems): Place global variable
      behind `DEBUGGING` preprocessor symbol, omitting it from production
      and ordinary development builds.

      (statem::statem): Make constructor trivial if `DEBUGGING` not defined
      in preprocessor; it manipulates only `issue_no` and `no_of_statems`,
      which are synchronized.

      (statem::statem {copy}): Gate assignment of `issue_no` member variable
      from copy constructor behind `DEBUGGING` preprocessor symbol.

      (statem::flush, mtsm::inherit): Gate debugging output, already
      runtime-gated on `debug_state` symbol, of `issue_no` member variable,
      so that we don't reference it when it is not declared.

    See <https://savannah.gnu.org/bugs/?62040>.


G. Branden Robinson <gbranden>
Group administrator
Sun 15 May 2022 04:50:01 AM UTC, comment #8: 

  Correction:

  "Comment #1" should be "the original submission".

Bjarni Ingi Gislason <bjarniig>
Sun 15 May 2022 04:44:56 AM UTC, comment #7: 

  My comment #2 is wrong(?), I must have overlooked the error messages
as they were early in the output and not at the end.

  The double free is caused by the line "delete the_output;" in
"src/roff/troff/div.cpp" (line 567); comment #1 points at line
566.

  The freeing of memory is not necessary near the exit of a programme
(learned from the folks from GNULIB, bug-gnulib).

Bjarni Ingi Gislason <bjarniig>
Sat 14 May 2022 09:34:21 PM UTC, comment #6: 

Bertrand recently updated our gnulib.

This did not resolve the problem.

Interestingly, specifying the '-z' option avoids the SEGV, but '-Z' doesn't.  So the problem is not occurring in the output driver.  The backtrace didn't suggest that it was, but the still-SEGV-with-'-Z' wrinkle is noteworthy to me.


G. Branden Robinson <gbranden>
Group administrator
Tue 15 Mar 2022 10:41:52 PM UTC, comment #5: 


comment #2:

>   I neither get an empty line nor a memory dump.
>
>   I use the most recent files in the gnulib git repository.
>
>   I have eliminated those warnings from the gcc compiler (latest in the
> testing distribution of Debian), that are easy to fix.
>


Hi Bjarni,

This feedback is not as helpful as it could be.  Do you know if:

1) Upgrading gnulib is, by itself, sufficient to fix the problem?

And if it isn't,

2) Which warning-suppression fix is?

And moreover, are both a gnulib upgrade and a warning-suppression fix required?

As Ingo has suggested, we don't want to fire blindly when fixing compiler warnings.  It is not sufficient to address them; we must also understand them.

The above information would expedite the resolution of this bug.  Failing that, it's going to require more time and experimentation on my part.

G. Branden Robinson <gbranden>
Group administrator
Tue 15 Mar 2022 10:37:21 PM UTC, comment #4: 

This bug is not in groff 1.22.4.  I exposed it at a considerable distance with the following commit.


commit 384b5b2b235a053d905304abfe24712afe90d441 (HEAD, refs/bisect/bad)
Author: G. Branden Robinson <g.branden.robinson@gmail.com>
Date:   Thu May 20 00:36:35 2021 +1000

    tmac/an-old.tmac: Drop no-op .tl requests.

    * tmac/an-old.tmac (an-header, an-footer): Drop no-op .tl requests.
[...]
diff --git a/tmac/an-old.tmac b/tmac/an-old.tmac
index 1747728a5..ed4769367 100644
--- a/tmac/an-old.tmac
+++ b/tmac/an-old.tmac
@@ -284,9 +284,7 @@
 .  ps \\n[PS]u
 .  vs \\n[VS]u
 .  lt \\n[LT]u
-.  ie \\n[an-is-output-html] \
-.    tl ''''
-.  el \{\
+.  if !\\n[an-is-output-html] \
 .    if !\\n[cR] \
 .      sp .5i
 .    PT
@@ -310,10 +308,7 @@
 .  ps \\n[PS]u
 .  vs \\n[VS]u
 .  lt \\n[LT]u
-.  ie \\n[an-is-output-html] \{\
-.    tl ''''
-.  \}
-.  el \{\
+.  if !\\n[an-is-output-html] \{\
 .    ie \\n[cR] \
 .      ds an-outer-footer-text "\\*[an-title](\\*[an-section])\"
 .    el \{\


I say "exposed" rather than "caused" because a change to a macro package should not be able to make the output driver drop core.  It seems reasonable to infer that a raw roff document could be constructed that would provoke the same behavior.

With respect to why this change exposed the bug, my surmise remains consistent with comment #1.  I think the blank titles put nodes on the output, such that was no longer "nothing" where the output driver was expecting "something".

G. Branden Robinson <gbranden>
Group administrator
Sun 06 Mar 2022 06:26:10 PM UTC, comment #3: 

For posterity, this bug revealed itself in the thread http://lists.gnu.org/r/groff/2022-02/msg00037.html, which was started to report a minor rendering problem.

I get the crash on a groff built on November 3 from the then most recent sources.

$ groff --version
GNU groff version 1.23.0.rc1.1499-34c5f
Copyright (C) 2020 Free Software Foundation, Inc.
GNU groff comes with ABSOLUTELY NO WARRANTY.
You may redistribute copies of groff and its subprograms
under the terms of the GNU General Public License.
For more information about these matters, see the file
named COPYING.

called subprograms:

GNU grops (groff) version 1.23.0.rc1.1499-34c5f
GNU troff (groff) version 1.23.0.rc1.1499-34c5f
$ cat 62040
.TH foo 1 2022-02-12 "groff test suite"
.TP 1n \" not enough room for 'A' plus a space, so break after 'A'
A
.\" ...but input unexpectedly ends.
$ groff -man -Thtml 62040 | wc
free(): double free detected in tcache 2
groff: error: troff: Aborted
     29      84     820
$ sed s/1n/2n/ 62040 | groff -man -Thtml | wc
     39     101    1005
$


Dave <barx>
Group Member
Sun 13 Feb 2022 11:26:19 PM UTC, comment #2: 

  I neither get an empty line nor a memory dump.

  I use the most recent files in the gnulib git repository.

  I have eliminated those warnings from the gcc compiler (latest in the
testing distribution of Debian), that are easy to fix.

Bjarni Ingi Gislason <bjarniig>
Sat 12 Feb 2022 08:18:38 AM UTC, comment #1: 

I forgot to credit Alejandro Colomar for the original reproducer.

Here's a smaller one, with comments outlining my suspicion of contributing factors to the problem.

If you widen the `TP` indentation to 2n, or give the paragraph some "meat" after the tag (even a single letter), the crash is avoided.


$ cat EXPERIMENTS/tag2.man
.TH foo 1 2022-02-12 "groff test suite"
.TP 1n \" not enough room for 'A' plus a space, so break after 'A'
A
.\" ...but input unexpectedly ends.


It appears to me that whatever in grohtml handles tagged paragraphs is assuming something will be present, and it goes wrong when it isn't.

G. Branden Robinson <gbranden>
Group administrator
Sat 12 Feb 2022 08:04:29 AM UTC, original submission:  

Problem exists in groff Git HEAD but not groff 1.22.4.  However, (speculating) this problem may have been masked in the past by groff's use of its own allocator.


$ cat EXPERIMENTS/tag-list-in-html.man
.TH foo 1 2022-02-12 "groff test suite"
.TP
List
.RS
.TP
.B LOOOOOONG_ITEM
.TQ
.B LOOOOONGISH_ITEM
.TQ
.B SHORT
.TQ
.B ANOTHER_LONG_ONE
.RE
$ ./build/test-groff -man -Thtml EXPERIMENTS/tag-list-in-html.man >| tag.html
free(): double free detected in tcache 2
groff: error: troff: Aborted (core dumped)
$ gdb ./build/troff ./core
GNU gdb (Debian 8.2.1-2+b3) 8.2.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Find the GDB manual and other documentation resources online at:
    <http://www.gnu.org/software/gdb/documentation/>.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./build/troff...done.
[New LWP 45485]
Core was generated by `troff -b -ww -man -dwww-image-template=grohtml-45478- -Thtml'.
Program terminated with signal SIGABRT, Aborted.
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
50      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
##(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
#1  0x00007fb5285be535 in __GI_abort () at abort.c:79
#2  0x00007fb528615508 in __libc_message (action=action@entry=do_abort, fmt=fmt@entry=0x7fb52872028d "%s\n") at ../sysdeps/posix/libc_fatal.c:181
#3  0x00007fb52861bc1a in malloc_printerr (str=str@entry=0x7fb528721f58 "free(): double free detected in tcache 2") at malloc.c:5341
#4  0x00007fb52861d6fd in _int_free (av=0x7fb528757c40 <main_arena>, p=0x55ca61849700, have_lock=<optimized out>) at malloc.c:4193
#5  0x000055ca5f8b1c8c in sfree (ptr=0x55ca61849710 "P$ra\312U") at ../src/libs/libgroff/string.cpp:47
#6  0x000055ca5f8b1ffe in string::~string (this=0x55ca61720c98, __in_chrg=<optimized out>) at ../src/libs/libgroff/string.cpp:127
#7  0x000055ca5f88e51e in string_value::~string_value (this=0x55ca61720c98, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:139
#8  0x000055ca5f88eb7f in statem::~statem (this=0x55ca61720c40, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:193
#9  0x000055ca5f88fac7 in stack::~stack (this=0x55ca61713890, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:349
#10 0x000055ca5f88fbb8 in mtsm::~mtsm (this=0x55ca616d8a80, __in_chrg=<optimized out>) at ../src/roff/troff/mtsm.cpp:364
#11 0x000055ca5f894a62 in output_file::~output_file (this=0x55ca616d8a70, __in_chrg=<optimized out>) at ../src/roff/troff/node.cpp:1631
#12 0x000055ca5f894ec2 in real_output_file::~real_output_file (this=0x55ca616d8a70, __in_chrg=<optimized out>) at ../src/roff/troff/node.cpp:1667
#13 0x000055ca5f894725 in troff_output_file::~troff_output_file (this=0x55ca616d8a70, __in_chrg=<optimized out>)
    at ../src/roff/troff/node.cpp:1586
#14 0x000055ca5f894740 in troff_output_file::~troff_output_file (this=0x55ca616d8a70, __in_chrg=<optimized out>)
    at ../src/roff/troff/node.cpp:1589
#15 0x000055ca5f85f1fa in cleanup_and_exit (exit_code=0) at ../src/roff/troff/div.cpp:566
#16 0x000055ca5f85f281 in top_level_diversion::begin_page (this=0x55ca61671b60, n=...) at ../src/roff/troff/div.cpp:581
#17 0x000055ca5f85ed21 in top_level_diversion::space (this=0x55ca61671b60, n=..., forced=1) at ../src/roff/troff/div.cpp:475
#18 0x000055ca5f877f6e in exit_troff () at ../src/roff/troff/input.cpp:2587
#19 0x000055ca5f887919 in main (argc=6, argv=0x7ffdfd993208) at ../src/roff/troff/input.cpp:8229
##(gdb) quit


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 gbranden (original reporter of #54909)
  • -email is unavailable- added by barx (Posted a comment)
  • -email is unavailable- added by bjarniig (Posted a comment)
  • -email is unavailable- added by alx
  • -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 9 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2023-01-25 gbranden Carbon-Copy- Added -email is unavailable-
    2023-01-25 gbranden Item GroupLint Crash/Unresponsive
    2023-01-25 gbranden Severity2 - Minor 4 - Important
    2022-05-15 gbranden Severity4 - Important 2 - Minor
        Item GroupCrash/Unresponsive Lint
        Assigned toNone gbranden
        Summary[troff] double-free crash provoked by HTML man(7) output [troff] audit mtsm/statem memory usage
    2022-02-12 alx Carbon-Copy- Added alejandro colomar <alx.manpages@gmail.com>
    2022-02-12 gbranden StatusNone Confirmed

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code