From: Phil Muldoon <pmuldoon@redhat.com>
To: Simon Marchi <simon.marchi@polymtl.ca>,
Maxim Akhmedov <max42@yandex-team.com>
Cc: gdb@sourceware.org
Subject: Re: Default value for option "python print-stack"
Date: Mon, 20 Feb 2017 10:26:00 -0000 [thread overview]
Message-ID: <cc789375-e1b7-dfda-1282-fc5f78d7458a@redhat.com> (raw)
In-Reply-To: <5528d675aa4c171442a7c8b1aba9c135@polymtl.ca>
On 18/02/17 15:00, Simon Marchi wrote:
> On 2017-02-14 19:03, Maxim Akhmedov wrote:
>> Hi,
>>
>> Currently the default value for an option "python print-stack" is "message"
>> that enables show only the messages of Python exceptions, but not their
>> tracebacks nor line numbers.
>>
>> Though, usually the message of a Python error itself is pretty useless as it
>> doesn't point you where exactly the error happened. Like, suppose you have a
>> pretty-printer written in Python, and then you get the following output:
>>
>> (gdb) yp lastKey
>> Python Exception <type 'exceptions.UnboundLocalError'> local variable
>> 'value_data' referenced before assignment:
>> Error occurred in Python command: local variable 'value_data' referenced before
>> assignment
>>
>> it doesn't really tell you anything, there may be lots of usages of a mentioned
>> variable, and due to the dynamic nature of Python you may easily mess somewhere
>> and it's particularly hard to find out the exact place by this message. Also,
>> the exception message is duplicated.
>>
>> I see two options here.
>> First one is choosing "full" as a default value for this option. Is their any
>> rationale for not doing that? Python tracebacks are usually not that large to
>> intentionally suppress them.
>> Second one is appending the sourcefile:lineno to the message. Like:
>> "/path/to/source.py:123". I believe it should be possible to extract this
>> information from the traceback object you get after invoking the Python code.
>>
>> From my point of view, it's a good idea to implement both of this options.
>
> I agree with the first one, I spent so much time tracking bugs in my Python code before knowing about this setting.
>
> Simon
Originally, the message only approach was chosen because Python
pretty-printed values that caused exceptions in backtraces would often
generate large amounts of Python exceptions that totally messed up the
backtrace. This is always the case when the pretty-printed values are
not initialised. I have no strong position on message or stack-trace;
I prefer the former because there was thought put into the reasoning.
Just as a note, you can set the exception printing parameter, as well
as any other GDB parameter, in the user .gdbinit. I've often mulled,
and I think I brought up once, a review of GDB default values (like
set print pretty on, for example). This will generate some
disagreements to this list, though! ;)
Cheers
Phil
prev parent reply other threads:[~2017-02-20 10:26 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-15 0:03 Maxim Akhmedov
2017-02-18 15:00 ` Simon Marchi
2017-02-20 10:26 ` Phil Muldoon [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=cc789375-e1b7-dfda-1282-fc5f78d7458a@redhat.com \
--to=pmuldoon@redhat.com \
--cc=gdb@sourceware.org \
--cc=max42@yandex-team.com \
--cc=simon.marchi@polymtl.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox