Just a quick note because this is way too cool not to share. When
python.org came back up today, it almost immediately got cpu slammed
(and has been for at least the last 3 hours). I know what's going on
-- it has to do with performance problems in Mailman that in this case
was triggered by a flood of incoming messages to all the mailing
lists. This Mailman problem has been seen by a few other users, but
it's dang hard to track down. Guido, Jeremy, and I got to talking
about what tools we'd like to have to help debug this problem.
My model was gdb's attach feature where you can attach to, stop and
trace through a running external C program. I would love to be able
to do the same thing at the Python level. We started talking about
remote pdb's with threads listening on sockets, etc. (still cool ideas
but more work). I mentioned that I'd love to be able to just get a
traceback of where the program is currently stopped. Even if it hoses
the interpreter afterwards, it would still be incredibly useful.
Guido and I spent some fun after hours hacking time and came up with
the following trick.
[.This is described in terms of gdb, but you might be able to do
something similar with dbx or other Unix and non-Unix debuggers, I
dunno]
First, get the pid of the running Python process. Start up gdb on the
python executable and at the gdb prompt type "attach XXX" where XXX is
the pid. Now, at the gdb prompt, type the following:
(gdb) call PyRun_SimpleString("import sys, traceback; sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()")
Sitting in /tmp/tb will be the stack trace of where the Python program
was when you stopped it! There's reason to believe this will not
always work, and it could seriously confuse your interpreter depending
on where it stops. But every time I've tried it it /does/ work, and
you can even detach the program and let it continue on!
Chris Tismer, somehow I think your stackless Python might either make
this trick harder or much easier :)
makes-this-geek-quiver-with-joy-but-my-mom-would-just-scratch-her-head-ly y'rs,
-Barry
python.org came back up today, it almost immediately got cpu slammed
(and has been for at least the last 3 hours). I know what's going on
-- it has to do with performance problems in Mailman that in this case
was triggered by a flood of incoming messages to all the mailing
lists. This Mailman problem has been seen by a few other users, but
it's dang hard to track down. Guido, Jeremy, and I got to talking
about what tools we'd like to have to help debug this problem.
My model was gdb's attach feature where you can attach to, stop and
trace through a running external C program. I would love to be able
to do the same thing at the Python level. We started talking about
remote pdb's with threads listening on sockets, etc. (still cool ideas
but more work). I mentioned that I'd love to be able to just get a
traceback of where the program is currently stopped. Even if it hoses
the interpreter afterwards, it would still be incredibly useful.
Guido and I spent some fun after hours hacking time and came up with
the following trick.
[.This is described in terms of gdb, but you might be able to do
something similar with dbx or other Unix and non-Unix debuggers, I
dunno]
First, get the pid of the running Python process. Start up gdb on the
python executable and at the gdb prompt type "attach XXX" where XXX is
the pid. Now, at the gdb prompt, type the following:
(gdb) call PyRun_SimpleString("import sys, traceback; sys.stderr=open('/tmp/tb','w',0); traceback.print_stack()")
Sitting in /tmp/tb will be the stack trace of where the Python program
was when you stopped it! There's reason to believe this will not
always work, and it could seriously confuse your interpreter depending
on where it stops. But every time I've tried it it /does/ work, and
you can even detach the program and let it continue on!
Chris Tismer, somehow I think your stackless Python might either make
this trick harder or much easier :)
makes-this-geek-quiver-with-joy-but-my-mom-would-just-scratch-her-head-ly y'rs,
-Barry