bug-groff
[Top][All Lists]
Advanced

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

[bug #44018] gtroff hangs in environment::possibly_break_line with -mja


From: Osamu Sayama
Subject: [bug #44018] gtroff hangs in environment::possibly_break_line with -mja
Date: Fri, 16 Jan 2015 04:51:36 +0000
User-agent: Mozilla/5.0 (X11; SunOS i86pc; rv:17.0) Gecko/20100101 Firefox/17.0

URL:
  <http://savannah.gnu.org/bugs/?44018>

                 Summary: gtroff hangs in environment::possibly_break_line
with -mja
                 Project: GNU troff
            Submitted by: sayama
            Submitted on: 2015年01月16日 04時51分35秒
                Severity: 3 - Normal
              Item Group: None
                  Status: None
                 Privacy: Public
             Assigned to: None
             Open/Closed: Open
         Discussion Lock: Any
         Planned Release: None

    _______________________________________________________

Details:

I encountered that gtroff hangs with some Japanese roff file 
if -mja macro is used. I'm using groff-1.22.2 with ja_JP.UTF-8
locale. I could reproduce this problem in some of destro like Ubuntu14.04
which includes groff-1.22.2. For example, by using attached sample1.1,
---
% preconv -D utf8 sample1.1 | gtbl | geqn -Tutf8 | gtroff -E -Tutf8 -mandoc
-mja | grotty -c
---
It hangs. From pstack, it goes into an infinite loop at 
environment::possibly_break_line.
---
$ pstack `pgrep troff`
#0  0x000000000040f532 in environment::possibly_break_line(int, int) ()
#1  0x000000000040f950 in environment::space_newline() ()
#2  0x0000000000410a30 in environment::newline() ()
#3  0x0000000000422594 in process_input_stack() ()
#4  0x0000000000422d83 in process_input_file(char const*) ()
#5  0x0000000000402e1b in main ()
---
Attached sample2_TP.1 is another example for this. I think 
this is a bug in nroff file itself because .TP must have 2
arguments, first one is label, second one is its explanation.
However, I think gtroff should avoid hang.

>From my simple investigation, output_width becomes 0 when this problem
occurs.

     hunits output_width = bp->width + extra_space_width;

So returning this function if output_width <= 0 resolved my issue.

--- groff-1.22.2/src/roff/troff/env.cpp.org     2013-02-07 21:06:06.000000000
+0
900
+++ groff-1.22.2/src/roff/troff/env.cpp 2015-01-14 10:23:07.817142586 +0900
@@ -2110,6 +2110,9 @@
     }
     distribute_space(pre, bp->nspaces, extra_space_width);
     hunits output_width = bp->width + extra_space_width;
+    if (output_width <= 0)
+      return;
+
     input_line_start -= output_width;
     if (bp->hyphenated)
       hyphen_line_count++;
----

I'm not sure about the root cause of this 0 width (bp->width and
extra_space_width
were 0) however I think it's great that going into a infinite loop is avoided

even if output_width is 0.




    _______________________________________________________

File Attachments:


-------------------------------------------------------
Date: 2015年01月16日 04時51分35秒  Name: sample1.1  Size: 117B   By:
sayama

<http://savannah.gnu.org/bugs/download.php?file_id=32837>
-------------------------------------------------------
Date: 2015年01月16日 04時51分35秒  Name: sample2_TP.1  Size: 576B   By:
sayama

<http://savannah.gnu.org/bugs/download.php?file_id=32838>

    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?44018>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/




reply via email to

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