bugGNU troff - Bugs: bug #44018, gtroff hangs in...

 
 

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

Submitted by:  Osamu Sayama <sayama>
Submitted on:  Fri 16 Jan 2015 04:51:35 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: None
Privacy: PublicAssigned to: None
Open/Closed: OpenPlanned Release: None

Add a New Comment(Rich Markup)
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 16 Jan 2015 04:51:35 AM UTC, original submission:

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.

Osamu Sayama <sayama>

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #32837:  sample1.1 added by sayama (117B - application/octet-stream)
file #32838:  sample2_TP.1 added by sayama (576B - application/octet-stream)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by sayama (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 2 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 16 Jan 2015 04:51:35 AM UTCsayamaAttached File-=>Added sample1.1, #32837
      Attached File-=>Added sample2_TP.1, #32838

    Back to the top


    Powered by Savane 3.1-cleanup1