GNU bug report logs - #40008
Backtraces can contain very long strings

Previous Next

Package: guile;

Reported by: Jan Synacek <jsynacek <at> redhat.com>

Date: Tue, 10 Mar 2020 10:06:01 UTC

Severity: normal

To reply to this bug, email your comments to 40008 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-guile <at> gnu.org:
bug#40008; Package guile. (Tue, 10 Mar 2020 10:06:01 GMT) Full text and rfc822 format available.

Acknowledgement sent to Jan Synacek <jsynacek <at> redhat.com>:
New bug report received and forwarded. Copy sent to bug-guile <at> gnu.org. (Tue, 10 Mar 2020 10:06:01 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Jan Synacek <jsynacek <at> redhat.com>
To: bug-guile <at> gnu.org
Subject: Backtraces can contain very long strings
Date: Tue, 10 Mar 2020 11:05:24 +0100
[Message part 1 (text/plain, inline)]
I have the following backtrace:

Backtrace:
In ice-9/boot-9.scm:
  1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
In unknown file:
           8 (apply-smob/0 #<thunk 651b40>)
In ice-9/boot-9.scm:
    718:2  7 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
In ice-9/eval.scm:
    619:8  6 (_ #(#(#<directory (guile-user) 74cf00>)))
In ice-9/boot-9.scm:
   2806:4  5 (save-module-excursion _)
  4351:12  4 (_)
In /home/jsynacek/./git.scm:
     72:0  3 (_)
    61:16  2 (change-spec _ _ "66.33" _ #<output: file 1>)
    48:12  1 (change-release "# We ship a .pc file but don't want t…" …)
In unknown file:
           0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …)

ERROR: In procedure make-regexp:
Wrong type (expecting exact integer): "
<HERE COMES A LOOOONG STRING WHICH IS ABOUT 193000 CHARACTERS WIDE>
"

While this is probably not considered an error, I guess it might be better
to ellipsize strings in errors such is mine that are over a certain length
long. The important part of the backtrace was scrolled away and I got
confused about the string, as I thought it was part of the output and
started wondering why (display ...) keeps the escaped newlines in the
string.

If this is not considered a bug, please, at least consider it an RFE.

-- 
Jan Synacek
Software Engineer, Red Hat
[Message part 2 (text/html, inline)]

Information forwarded to bug-guile <at> gnu.org:
bug#40008; Package guile. (Tue, 10 Mar 2020 11:48:01 GMT) Full text and rfc822 format available.

Message #8 received at submit <at> debbugs.gnu.org (full text, mbox):

From: <tomas <at> tuxteam.de>
To: bug-guile <at> gnu.org
Subject: Re: bug#40008: Backtraces can contain very long strings
Date: Tue, 10 Mar 2020 12:47:11 +0100
[Message part 1 (text/plain, inline)]
On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote:
> I have the following backtrace:
> 
> Backtrace:
> In ice-9/boot-9.scm:
>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> In unknown file:
>            8 (apply-smob/0 #<thunk 651b40>)
> In ice-9/boot-9.scm:
>     718:2  7 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
> In ice-9/eval.scm:
>     619:8  6 (_ #(#(#<directory (guile-user) 74cf00>)))
> In ice-9/boot-9.scm:
>    2806:4  5 (save-module-excursion _)
>   4351:12  4 (_)
> In /home/jsynacek/./git.scm:
>      72:0  3 (_)
>     61:16  2 (change-spec _ _ "66.33" _ #<output: file 1>)
>     48:12  1 (change-release "# We ship a .pc file but don't want t…" …)
> In unknown file:
>            0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …)
> 
> ERROR: In procedure make-regexp:
> Wrong type (expecting exact integer): "
> <HERE COMES A LOOOONG STRING WHICH IS ABOUT 193000 CHARACTERS WIDE>
> "
> 
> While this is probably not considered an error, I guess it might be better
> to ellipsize strings in errors such is mine that are over a certain length
> long. The important part of the backtrace was scrolled away and I got
> confused about the string, as I thought it was part of the output and
> started wondering why (display ...) keeps the escaped newlines in the
> string.

Some want it, some want it not. I remember a couple of discussions
in guile-user and guile-devel about this topic.

Have you tried setting debug options `width' and/or `depth' (cf. procedure
`debug-options')?

(my current defaults are 79 columns/20 rows, this is Guile 3.0).

> If this is not considered a bug, please, at least consider it an RFE.

I guess one could argue about the current defaults, but it'll be
difficult to find values making all people happy all the time.

Cheers
-- t
[signature.asc (application/pgp-signature, inline)]

Information forwarded to bug-guile <at> gnu.org:
bug#40008; Package guile. (Wed, 11 Mar 2020 11:14:01 GMT) Full text and rfc822 format available.

Message #11 received at 40008 <at> debbugs.gnu.org (full text, mbox):

From: Ludovic Courtès <ludo <at> gnu.org>
To: <tomas <at> tuxteam.de>
Cc: 40008 <at> debbugs.gnu.org
Subject: Re: bug#40008: Backtraces can contain very long strings
Date: Wed, 11 Mar 2020 12:13:32 +0100
Hi,

<tomas <at> tuxteam.de> skribis:

> On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote:
>> I have the following backtrace:
>> 
>> Backtrace:
>> In ice-9/boot-9.scm:
>>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
>> In unknown file:
>>            8 (apply-smob/0 #<thunk 651b40>)
>> In ice-9/boot-9.scm:
>>     718:2  7 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
>> In ice-9/eval.scm:
>>     619:8  6 (_ #(#(#<directory (guile-user) 74cf00>)))
>> In ice-9/boot-9.scm:
>>    2806:4  5 (save-module-excursion _)
>>   4351:12  4 (_)
>> In /home/jsynacek/./git.scm:
>>      72:0  3 (_)
>>     61:16  2 (change-spec _ _ "66.33" _ #<output: file 1>)
>>     48:12  1 (change-release "# We ship a .pc file but don't want t…" …)
>> In unknown file:
>>            0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …)
>> 
>> ERROR: In procedure make-regexp:
>> Wrong type (expecting exact integer): "
>> <HERE COMES A LOOOONG STRING WHICH IS ABOUT 193000 CHARACTERS WIDE>
>> "
>> 
>> While this is probably not considered an error, I guess it might be better
>> to ellipsize strings in errors such is mine that are over a certain length
>> long. The important part of the backtrace was scrolled away and I got
>> confused about the string, as I thought it was part of the output and
>> started wondering why (display ...) keeps the escaped newlines in the
>> string.
>
> Some want it, some want it not. I remember a couple of discussions
> in guile-user and guile-devel about this topic.
>
> Have you tried setting debug options `width' and/or `depth' (cf. procedure
> `debug-options')?
>
> (my current defaults are 79 columns/20 rows, this is Guile 3.0).

The backtrace itself is ellipsized, but the value displayed in the
exception (the long string above) is not.

I would rather not ellipsize anything in the exception itself.

Thoughts?

Ludo’.




Information forwarded to bug-guile <at> gnu.org:
bug#40008; Package guile. (Wed, 11 Mar 2020 12:40:01 GMT) Full text and rfc822 format available.

Message #14 received at 40008 <at> debbugs.gnu.org (full text, mbox):

From: Mikael Djurfeldt <mikael <at> djurfeldt.com>
To: Ludovic Courtès <ludo <at> gnu.org>
Cc: 40008 <at> debbugs.gnu.org, Mikael Djurfeldt <mikael <at> djurfeldt.com>,
 tomas <at> tuxteam.de
Subject: Re: bug#40008: Backtraces can contain very long strings
Date: Wed, 11 Mar 2020 13:39:01 +0100
[Message part 1 (text/plain, inline)]
On Wed, Mar 11, 2020 at 12:14 PM Ludovic Courtès <ludo <at> gnu.org> wrote:

> Hi,
>
> <tomas <at> tuxteam.de> skribis:
>
> > On Tue, Mar 10, 2020 at 11:05:24AM +0100, Jan Synacek wrote:
> >> I have the following backtrace:
> >>
> >> Backtrace:
> >> In ice-9/boot-9.scm:
> >>   1736:10  9 (with-exception-handler _ _ #:unwind? _ # _)
> >> In unknown file:
> >>            8 (apply-smob/0 #<thunk 651b40>)
> >> In ice-9/boot-9.scm:
> >>     718:2  7 (call-with-prompt _ _ #<procedure default-prompt-handle…>)
> >> In ice-9/eval.scm:
> >>     619:8  6 (_ #(#(#<directory (guile-user) 74cf00>)))
> >> In ice-9/boot-9.scm:
> >>    2806:4  5 (save-module-excursion _)
> >>   4351:12  4 (_)
> >> In /home/jsynacek/./git.scm:
> >>      72:0  3 (_)
> >>     61:16  2 (change-spec _ _ "66.33" _ #<output: file 1>)
> >>     48:12  1 (change-release "# We ship a .pc file but don't want t…" …)
> >> In unknown file:
> >>            0 (make-regexp "^Release:(\\s*).*$" "# We ship a .pc fil…" …)
> >>
> >> ERROR: In procedure make-regexp:
> >> Wrong type (expecting exact integer): "
> >> <HERE COMES A LOOOONG STRING WHICH IS ABOUT 193000 CHARACTERS WIDE>
> >> "
> >>
> >> While this is probably not considered an error, I guess it might be
> better
> >> to ellipsize strings in errors such is mine that are over a certain
> length
> >> long. The important part of the backtrace was scrolled away and I got
> >> confused about the string, as I thought it was part of the output and
> >> started wondering why (display ...) keeps the escaped newlines in the
> >> string.
> >
> > Some want it, some want it not. I remember a couple of discussions
> > in guile-user and guile-devel about this topic.
> >
> > Have you tried setting debug options `width' and/or `depth' (cf.
> procedure
> > `debug-options')?
> >
> > (my current defaults are 79 columns/20 rows, this is Guile 3.0).
>
> The backtrace itself is ellipsized, but the value displayed in the
> exception (the long string above) is not.
>
> I would rather not ellipsize anything in the exception itself.
>
> Thoughts?
>

It would be nice if this was configurable. As Tomas pointed out this kind
of thing can be a matter of taste. Also, if debugging some specific problem
involving large strings it might be convenient to switch on for anyone.

There could be a debug-option (see (debug-options '?)) `exception-width'
(similar to `width' but for errors and exceptions).

But how is the debug-options interface regarded nowadays? Is it going to be
deprecated? I notice that the `width' option doesn't seem to have an effect
anymore. Looking into backtrace.c and (system repl debug) the width
nowadays rather seems to be controlled by the terminal width only.

Best regards,
Mikael
[Message part 2 (text/html, inline)]

This bug report was last modified 4 years and 55 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.