G. Branden Robinson
2020-04-10 08:10:03 UTC
URL:
<https://savannah.gnu.org/bugs/?58153>
Summary: input_stack::backtrace() over-suppresses output
Project: GNU troff
Submitted by: gbranden
Submitted on: Fri 10 Apr 2020 08:10:01 AM UTC
Category: Core
Severity: 3 - Normal
Item Group: Incorrect behaviour
Status: In Progress
Privacy: Public
Assigned to: gbranden
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Details:
The above function in src/roff/troff/input.cpp has the following condition in
a for loop with an accompanying comment:
// only backtrace down to (not including) the topmost file
...
p && !p->get_location(0, &f, &n);
However, for reasons I admit I haven't been able to quite figure out, this
conditional fails under more cases than intended. Specifically, it seems to
fail (ending the loop) when _any_ file_iterator is encountered, halting the
backtrace across .so, .nx, or .pso boundaries. This doesn't happen for the
.backtrace request--only for backtraces triggered by warnings or errors in
input combined with the groff -b flag.
Since read files and not just stdin are involved, I'm attaching a reproducing
case. Here's what I get with the groff 1.22.4 in my distribution:
$ /usr/bin/groff -b -ww -U /tmp/outer >/dev/null
troff: printf '\s[10]\n';printf '\s[-20]\n';printf 'foobar':2: warning: \s
escape results in non-positive point size; set to 1
And here's groff git HEAD with a patch I'm preparing:
$ ./test-groff -U /tmp/outer >/dev/null
troff: backtrace: pipe 'printf '\s[10]\n';printf '\s[-20]\n';printf
'foobar'':2
troff: backtrace: file '/tmp/inner':3
troff: backtrace: pipe 'echo .so /tmp/inner':1
troff: backtrace: file '/tmp/outer':1
troff: printf '\s[10]\n';printf '\s[-20]\n';printf 'foobar':2: warning:
point-size escape results in non-positive size -10000u; set to 1u
This patch does result in one additional line of output when -b is given and
an error or (non-ignored) warning happens at the top level. However, I regard
this as unobjectionable because (1) a backtrace was in fact explicitly
requested; and (2) it seems a poor tradeoff to suppress the backtrace in all
complicated and frustrating cases for the sake of less backtrace output in a
trivial one.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Fri 10 Apr 2020 08:10:01 AM UTC Name: outer Size: 25B By: gbranden
<http://savannah.gnu.org/bugs/download.php?file_id=48799>
-------------------------------------------------------
Date: Fri 10 Apr 2020 08:10:01 AM UTC Name: inner Size: 66B By: gbranden
<http://savannah.gnu.org/bugs/download.php?file_id=48800>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?58153>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
<https://savannah.gnu.org/bugs/?58153>
Summary: input_stack::backtrace() over-suppresses output
Project: GNU troff
Submitted by: gbranden
Submitted on: Fri 10 Apr 2020 08:10:01 AM UTC
Category: Core
Severity: 3 - Normal
Item Group: Incorrect behaviour
Status: In Progress
Privacy: Public
Assigned to: gbranden
Open/Closed: Open
Discussion Lock: Any
Planned Release: None
_______________________________________________________
Details:
The above function in src/roff/troff/input.cpp has the following condition in
a for loop with an accompanying comment:
// only backtrace down to (not including) the topmost file
...
p && !p->get_location(0, &f, &n);
However, for reasons I admit I haven't been able to quite figure out, this
conditional fails under more cases than intended. Specifically, it seems to
fail (ending the loop) when _any_ file_iterator is encountered, halting the
backtrace across .so, .nx, or .pso boundaries. This doesn't happen for the
.backtrace request--only for backtraces triggered by warnings or errors in
input combined with the groff -b flag.
Since read files and not just stdin are involved, I'm attaching a reproducing
case. Here's what I get with the groff 1.22.4 in my distribution:
$ /usr/bin/groff -b -ww -U /tmp/outer >/dev/null
troff: printf '\s[10]\n';printf '\s[-20]\n';printf 'foobar':2: warning: \s
escape results in non-positive point size; set to 1
And here's groff git HEAD with a patch I'm preparing:
$ ./test-groff -U /tmp/outer >/dev/null
troff: backtrace: pipe 'printf '\s[10]\n';printf '\s[-20]\n';printf
'foobar'':2
troff: backtrace: file '/tmp/inner':3
troff: backtrace: pipe 'echo .so /tmp/inner':1
troff: backtrace: file '/tmp/outer':1
troff: printf '\s[10]\n';printf '\s[-20]\n';printf 'foobar':2: warning:
point-size escape results in non-positive size -10000u; set to 1u
This patch does result in one additional line of output when -b is given and
an error or (non-ignored) warning happens at the top level. However, I regard
this as unobjectionable because (1) a backtrace was in fact explicitly
requested; and (2) it seems a poor tradeoff to suppress the backtrace in all
complicated and frustrating cases for the sake of less backtrace output in a
trivial one.
_______________________________________________________
File Attachments:
-------------------------------------------------------
Date: Fri 10 Apr 2020 08:10:01 AM UTC Name: outer Size: 25B By: gbranden
<http://savannah.gnu.org/bugs/download.php?file_id=48799>
-------------------------------------------------------
Date: Fri 10 Apr 2020 08:10:01 AM UTC Name: inner Size: 66B By: gbranden
<http://savannah.gnu.org/bugs/download.php?file_id=48800>
_______________________________________________________
Reply to this item at:
<https://savannah.gnu.org/bugs/?58153>
_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/