This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author xdegaye
Recipients donaldcallen, ikelly, ned.deily, xdegaye
Date 2013-04-12.14:57:16
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1365778636.39.0.206430125413.issue17697@psf.upfronthosting.co.za>
In-reply-to
Content
The call to set_trace() installs a local trace function on all the
frames of the stack, including on the oldest frame, i.e. the module
level frame. This causes the invocation of frame_settrace() in
frameobject.c and the  module frame f_lineno is evaluated by
PyCode_Addr2Line() (this happens only on the first call to set_trace()
since the module frame local trace is never removed).

Next, the 'continue' command sets the global trace function to None
and removes the local trace function of all the frames of the stack,
*except* the module frame (see set_continue() in bdb.py).

On printing the stack with the 'where' command, the bdb get_stack()
function invokes frame_getlineno() that calls PyFrame_GetLineNumber()
that assumes that the module frame f_lineno is correct since it has a
local trace function.  But as the global trace function has been set
to None by the 'continue' command, f_lineno is not updated by
the interpreter tracing code when running the module level frame.
Hence the problem.

The root cause is that PyFrame_GetLineNumber assumes incorrectly that
when a frame has a local trace function, its f_lineno is correct.

Issue 7238 and issue 17277 are also related to this issue.
History
Date User Action Args
2013-04-12 14:57:16xdegayesetrecipients: + xdegaye, ikelly, ned.deily, donaldcallen
2013-04-12 14:57:16xdegayesetmessageid: <1365778636.39.0.206430125413.issue17697@psf.upfronthosting.co.za>
2013-04-12 14:57:16xdegayelinkissue17697 messages
2013-04-12 14:57:16xdegayecreate