469,924 Members | 1,406 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,924 developers. It's quick & easy.

saving Python process state for later debugging

Hi!

Is there a way to save the state of a Python process for later
inspection with a debugger? One way to do this is to dump core, but is
the result usable for debugging with pdb (it can be debugged by gdb,
which can inspect PyObjects in a CPython core, for example, but it's
not much fun)?

If there is no way to do this today, are there essential difficulties
in implementing this on top of an OS support for "raw" core dumps?

TIA,
Yossi

Mar 31 '07 #1
4 2707
On 31 mar, 16:48, yossi.krei...@gmail.com wrote:
Hi!

Is there a way to save the state of a Python process for later
inspection with a debugger? One way to do this is to dump core, but is
the result usable for debugging with pdb (it can be debugged by gdb,
which can inspect PyObjects in a CPython core, for example, but it's
not much fun)?

If there is no way to do this today, are there essential difficulties
in implementing this on top of an OS support for "raw" core dumps?
Pylon has something like that.
http://pylonshq.com/docs/0.9.4.1/int..._debugger.html

Turbogears has the same with option tg.fancy_exception

You can navigate into the stack trace from the web interface :-)
>
TIA,
Yossi

Mar 31 '07 #2
On Apr 1, 2:07 am, "aspineux" <aspin...@gmail.comwrote:
>
Pylon has something like that.http://pylonshq.com/docs/0.9.4.1/int..._debugger.html

Turbogears has the same with option tg.fancy_exception
I could get it wrong, but these things seem to be about debugging
crashed processes "online", not saving snapshots to files for later
inspection. Can you e-mail a process snapshot to a different machine
with them, for example? I understood that you are supposed to debug
the original process, which is kept alive, via the web. I'm talking
about a situation where you have a Python program deployed to a user
who is not running a web server, and have the user send you a snapshot
as a bug report.

-- Yossi

Apr 1 '07 #3
On 1 avr, 09:39, yossi.krei...@gmail.com wrote:
On Apr 1, 2:07 am, "aspineux" <aspin...@gmail.comwrote:
Pylon has something like that.http://pylonshq.com/docs/0.9.4.1/int..._debugger.html
Turbogears has the same with option tg.fancy_exception

I could get it wrong, but these things seem to be about debugging
crashed processes "online", not saving snapshots to files for later
inspection. Can you e-mail a process snapshot to a different machine
with them, for example? I understood that you are supposed to debug
the original process, which is kept alive, via the web. I'm talking
about a situation where you have a Python program deployed to a user
who is not running a web server, and have the user send you a snapshot
as a bug report.

-- Yossi
A context in python is no more than 2 dictionaries ( globals() and
locals()).
You can easily serialize both to store them.
You can navigate into the python stack using module inspect and
generate the context for all
the functions in the stack trace.

This is probably no more than 50 lines of code, maybe 20 :-)

You can find sample of how to get these info and use them in the
sample I was reffering before.

Apr 1 '07 #4
On Apr 1, 2:57 pm, "aspineux" wrote:
>
A context in python is no more than 2 dictionaries ( globals() and
locals()).
You can easily serialize both to store them.
I don't think it will work with objects defined by extension modules,
except if they somehow support serialization, will it? I guess I can
dump core for debugging these objects, and serialize the Python
context for debugging the rest. Finding the extension objects in the
core dump can be a pain though, as will be figuring out the stack with
interlaced Python & native code. And then there are the lovely cases
when CPython crashes, like "deletion of interned string failed. Abort
(core dumped)", where you get to shovel through CPython state with a
native debugger.

The thing with mixing native code with Python is that when native code
misbehaves, it's a big problem, and if Python code misbehaves, it's
still a problem, although a smaller one (serializing the native state
& navigating through it). Maybe the best way around this is to spawn
sub-processes for running native code...

Apr 1 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

13 posts views Thread by Allison Bailey | last post: by
699 posts views Thread by mike420 | last post: by
226 posts views Thread by Stephen C. Waterbury | last post: by
4 posts views Thread by Jacob H | last post: by
8 posts views Thread by Paul Cochrane | last post: by
112 posts views Thread by mystilleef | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.