Changes between Version 9 and Version 10 of TracTroubleshooting

Timestamp:

Mar 24, 2012, 4:40:33 PM (12 years ago)

Author:

Christian Boos

Comment:

#SystemErrors: alternative way to get python backtrace within gdb 7.x

TracTroubleshooting

@@ -84 +84 @@
 In this case, the first thing to do is to identify the subsystem involved, by getting the ''stack trace'' of the process. This can be done using `gdb` on Unix or [http://www.microsoft.com/whdc/devtools/debugging/default.mspx WinDbg] on Windows (or MS Developer Studio).
 
-With GDB, you can also make the link between the C stack trace and the Python backtrace. For this, you need to teach `gdb` a few additional commands: Get the following  [http://svn.python.org/view/python/trunk/Misc/gdbinit gdbinit] script, and "source" it.
+With GDB, you can also make the link between the C stack trace and the Python backtrace. For this, you need to teach `gdb` a few additional commands: Get the following  [http://hg.python.org/cpython/file/2.7/Misc/gdbinit gdbinit] script, and "source" it.
 You should be able to issue interesting commands like `pystack`, `pyframe`, `pylocals`, etc.
+
+If you're using a gdb 7.x version built "`--with-python`", you can instead "`source`" [http://hg.python.org/cpython/file/2.7/Tools/gdb/libpython.py  libpython.py] and use `py-bt` (see also [http://sourceware.org/gdb/current/onlinedocs/gdb/Python.html Scripting gdb using Python]). 
 
 ==== Debugging Segmentation Faults ====
@@ -146 +148 @@
 
 The `bt` command is what gives you the "backtrace" of the program, usually the most interesting bit of information. You can also resume execution of the program (using `cont`) and interrupt the process a bit later, to see if it remains hanged in the same area. In case there's no hang (you "attached" to it just for curiosity),  you can also `detach` from the process and it will continue to work unaffected.
-