[issue3631] Improve gdbinit of Python 2.6

Gregory P. Smith added the comment: I updated the note in gdbinit to point to Tools/gdb/libpython.py for py3k (3.2) and 2.7. Thomas: I didn't do anything with your version of pystack because the existing versions in 3.2 and 2.7 appear to work fine for me. -- resolution: -> accepted

[issue3631] Improve gdbinit of Python 2.6

Martin v. Löwis added the comment: > do we have official python docs on this that I should point to? I only know of the doc string of libpython.py itself, in Tools/gdb -- ___ Python tracker ___

[issue3631] Improve gdbinit of Python 2.6

Gregory P. Smith added the comment: do we have official python docs on this that I should point to? -- ___ Python tracker ___ ___ Pyth

[issue3631] Improve gdbinit of Python 2.6

Martin v. Löwis added the comment: I think the reference to EasierPythonDebugging is outdated and should be corrected. Dave Malcolm's work is already part of Python, and available with every Python build. -- nosy: +loewis ___ Python tracker

[issue3631] Improve gdbinit of Python 2.6

Gregory P. Smith added the comment: and the py_decref in there isn't quite right, fixing... -- ___ Python tracker ___ ___ Python-bugs-

[issue3631] Improve gdbinit of Python 2.6

Gregory P. Smith added the comment: everything except the lineno change from gdbinit_python26.patch has been committed in r85646. -- ___ Python tracker ___ _

[issue3631] Improve gdbinit of Python 2.6

Gregory P. Smith added the comment: fyi - for information on using gdb 7 with python see http://bugs.python.org/issue8032 I'm looking at the .gdbinit improvements regardless as not everyone has gdb 7 (notably OS X). -- resolution: out of date -> status: closed -> open _

[issue3631] Improve gdbinit of Python 2.6

Thomas Vander Stichele added the comment: It's too bad this is closed out of date because a) the macro is still there being distributed b) it simply hangs! c) there's no easy way to figure out that you should be using something else instead. I spent a few hours of my life figuring out why i

[issue3631] Improve gdbinit of Python 2.6

STINNER Victor added the comment: Gdb7 now supports Python as a script language, and Python trunk/py3k has a gdb library to debug Python programs. It's much better than the old Misc/gdbinit script. Close this issue as "out of date". -- resolution: -> out of date status: open -> clos

[issue3631] Improve gdbinit of Python 2.6

Changes by Gregory P. Smith <[EMAIL PROTECTED]>: -- assignee: -> gregory.p.smith nosy: +gregory.p.smith priority: -> normal ___ Python tracker <[EMAIL PROTECTED]> ___ ___

[issue3631] Improve gdbinit of Python 2.6

STINNER Victor <[EMAIL PROTECTED]> added the comment: @skip: oh yes, you're right about the core file :-) So forget the changes in lineno. I first rewrote lineno for Python 3.0 because the code changed and it was easier for me to reuse PyCode_Addr2Line() :-) ___

[issue3631] Improve gdbinit of Python 2.6

Skip Montanaro <[EMAIL PROTECTED]> added the comment: Thanks for the patch. Most of it looks okay except for the rewrite of the lineno command. That was written in gdb's command language so that you could get a python stack from a core dump, not just from a running process. Is there some reaso

[issue3631] Improve gdbinit of Python 2.6

Changes by STINNER Victor <[EMAIL PROTECTED]>: -- components: +None type: -> feature request versions: +Python 2.6 ___ Python tracker <[EMAIL PROTECTED]> ___ _

[issue3631] Improve gdbinit of Python 2.6

New submission from STINNER Victor <[EMAIL PROTECTED]>: I wrote a patch to improve gdbinit (gdb macros): - implement py_decref - reuse pyo in pylocals - direclty call PyCode_Addr2Line() in lineno instead of a long and complex reimplemention in gdb script language - avoid memory leak in pyloc