Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Simon Marchi <simon.marchi@polymtl.ca>
To: Maxim Akhmedov <max42@yandex-team.com>
Cc: gdb@sourceware.org
Subject: Re: Default value for option "python print-stack"
Date: Sat, 18 Feb 2017 15:00:00 -0000	[thread overview]
Message-ID: <5528d675aa4c171442a7c8b1aba9c135@polymtl.ca> (raw)
In-Reply-To: <97321487117014@webcorp03e.yandex-team.ru>

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


  reply	other threads:[~2017-02-18 15:00 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 [this message]
2017-02-20 10:26   ` Phil Muldoon

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=5528d675aa4c171442a7c8b1aba9c135@polymtl.ca \
    --to=simon.marchi@polymtl.ca \
    --cc=gdb@sourceware.org \
    --cc=max42@yandex-team.com \
    /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