attaching debuggers

[Nicholas Clark]

I was having a chat with [someone who doesn't like to be name checked] last
night and he said that the perl debugger is often useless at solving
problems. For a compiled language, one can attach gdb or similar to a
running process after it's got itself into a state, whereas with perl one
either has to run with the debugger from the start (which might take too
long, or never exhibit the problem) or not use the debugger.

It would be really useful to be able to attach the perl6 debugger to a
running parrot VM, and start debugging, without having the speed hit
up to that point of debugging. gdb and similar rely on kernel help to
do their attaching to regular running processes. I've no idea how to do
such a thing without help to the parrot VM (such that people could chose
to have parrot VMs running in production in an attachable state).

Can anyone see a sane way to do it?

Better still, can anyone see a viable way to do it on perl5?

Nicholas Clark

[Dan Sugalski]

On Fri, 19 Sep 2003, Nicholas Clark wrote:

> It would be really useful to be able to attach the perl6 debugger to a
> running parrot VM, and start debugging, without having the speed hit
> up to that point of debugging. gdb and similar rely on kernel help to
> do their attaching to regular running processes. I've no idea how to do
> such a thing without help to the parrot VM (such that people could chose
> to have parrot VMs running in production in an attachable state).
>
> Can anyone see a sane way to do it?

Sure. *If* you've started parrot with remote debugging enabled (Whether
this sh ould be the default is an open question) we could set it up so
that parrot, when starting, opens up a socket it can listen on, and
installs a signal handler on some signal or other (USR1, or USR2 or
something). The signal handler is set up to inject a "kick into remote
debugger" exception. When that exception happens, parrot exits the current
runloop and restarts with the remote debugging runloop attached to the
socket as its control terminal.

So, the sequence is:

1) Connect to the control socket
2) Peg parrot with SIGUSR[12]
3) Profit!

No, wait, #3 isn't right... :)

Dan

[Nicholas Clark]

On Fri, Sep 19, 2003 at 03:33:11PM -0400, Dan Sugalski wrote:

> So, the sequence is:
>
> 1) Connect to the control socket
> 2) Peg parrot with SIGUSR[12]
> 3) Profit!
>
> No, wait, #3 isn't right... :)

Thinking about it, I don't see why we need #2 either
Assuming that we have the event system we've been led to expect, then we'll
attach a handler to the debugger socket that gets called on connection.
(well, in Unix select terms on being readable)
And that handler could kick us into debug mode

It seems that screen, emacs client and ssh-agent already create Unix
domain sockets in subdirectories of /tmp to provide this sort of service,
so I guess this is the right thing for parrot to do (on Unix)

Problem solved?

Nicholas Clark

PS #london.pm's infobot dipsy has been taught a step 4:
<dipsy> step 4 is shred all financial documents and give directors bonuses

[Michal Wallace]

On Fri, 19 Sep 2003, Nicholas Clark wrote:

[talking about dynamically intering the debugger]

>
> Can anyone see a sane way to do it?
>
> Better still, can anyone see a viable way to do it on perl5?

Python does this. There's basically a hook after every
statement, and you can put whatever you want in there.
I have no idea how it works internally, but from your
code you just put this in your code:

import pdb; pdb.set_trace()

and it stops right there and you're in the debugger.

Sincerely,

Michal J Wallace
Sabren Enterprises, Inc.
-------------------------------------
contact: mic...@sabren.com
hosting: http://www.cornerhost.com/
my site: http://www.withoutane.com/
--------------------------------------