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.
|