[pywin32-bugs] [ pywin32-Bugs-2997392 ] Debugger stack trace failure in 213 and later
OLD project page for the Python extensions for Windows
Brought to you by:
mhammond
From: SourceForge.net <no...@so...> - 2010-05-09 10:24:35
|
Bugs item #2997392, was opened at 2010-05-05 20:39 Message generated for change (Comment added) made by rupole You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&group_id=78018 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: pythonwin Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Paul Heinz (zunzster) Assigned to: Nobody/Anonymous (nobody) Summary: Debugger stack trace failure in 213 and later Initial Comment: Running against Python 2.5.4 When debugging the stack trace view only sees the top level stack frame in 213 and later builds when debugging for me. ---------------------------------------------------------------------- >Comment By: Roger Upole (rupole) Date: 2010-05-09 05:24 Message: The problem seems to be in \Pythonwin\pywin\tools\browser.py, lines 33 and 34. The name is truncated at 20 chars, and the name is used to check if a new item is being added. For frame stack items, the names all wind up as "<frame object at 0x00...", which of course all compare equal. Looks like this can be overriden by passing a name to HierListItem.__init__ (debugger.py, line 55). ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-05 23:47 Message: The list of HierFrameItems returned from HierStackRoot.GetSubList seem to be correct. Also, if I place a breakpoint a few methods in, the initial stack frame is correct. So it appears to be _subsequent_ calls to GetSubList that are mishandled. ---------------------------------------------------------------------- Comment By: Paul Heinz (zunzster) Date: 2010-05-05 23:24 Message: After a bit of debugging the debugger :-), it appears the problem doesn't seem to be the debugger itself but rather the treeview control mishandling the insertion of the frame objects. It seems to keep duplicating the deepest last tree entry rather than inserting the laster stack frame entries at the top. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=551954&aid=2997392&group_id=78018 |