Ruby Debuggers

[Kevin Kleinfelter]

------=_NextPart_000_001B_01C4F046.8D021F40
Content-Type: text/plain;
charset="us-ascii"
Content-Transfer-Encoding: 7bit

I've been playing around with ruby debuggers (-rdebug -rrem and RDT). When I debug Instiki, there's a point that it starts a thread
and goes off to wait for an http request. If I just let it run, how do I get control back to the debugger? I'm thinking of
something along the lines of Visual Basic, where control-break always interrupts the program and returns you to the debugger. Is
there any way in any of the Ruby debuggers to get control back? How can I find out what line last had control if it is waiting on
some event.

Thanks!
Kevin Kleinfelter



------=_NextPart_000_001B_01C4F046.8D021F40--

 

[Nicholas Van Weerdenburg]

http://dev-utils.rubyforge.org/ might be helpful.

 

[Laurent Julliard]

I've been playing around with ruby debuggers (-rdebug -rrem and RDT). When I debug Instiki, there's a point that it starts a thread
and goes off to wait for an http request. If I just let it run, how do I get control back to the debugger? I'm thinking of
something along the lines of Visual Basic, where control-break always interrupts the program and returns you to the debugger. Is
there any way in any of the Ruby debuggers to get control back? How can I find out what line last had control if it is waiting on
some event.

Thanks!
Kevin Kleinfelter

Hiting CTRL-C should interrupt the debugger in all cases then you can
switch from one thread to another with the "thread switch #N" command.
Isn't it working this way on your machine?

For a more user friandly user interface to the debugger you can also
euse the debugger in FreeRIDE, the free Ruby IDE.

Laurent

 

[Kevin Kleinfelter]

Half-way there. Turning trace on and being patient lets me see the last statement executed (IO.select, if anyone was wondering). I
hate being new to an environment. The obvious things aren't.

However, control-C does *not* return control to the debugger. It produces:
[2005-01-02 22:04:47] INFO going to shutdown ...
[2005-01-02 22:04:47] INFO WEBrick::HTTPServer#start done.
I'm betting that the reason it does so is the trap("INT") in the app. Is there a way to get the debugger's SIGINT handler priority
over application handling? (I'm running on WinXP, if p;atform matters.)

TIA

Kevin Kleinfelter
****************************************************************************
Hiting CTRL-C should interrupt the debugger in all cases then you can
switch from one thread to another with the "thread switch #N" command.
Isn't it working this way on your machine?

For a more user friandly user interface to the debugger you can also
euse the debugger in FreeRIDE, the free Ruby IDE.

Laurent

 

[Laurent Julliard]

Half-way there. Turning trace on and being patient lets me see the last statement executed (IO.select, if anyone was wondering). I
hate being new to an environment. The obvious things aren't.

However, control-C does *not* return control to the debugger. It produces:
[2005-01-02 22:04:47] INFO going to shutdown ...
[2005-01-02 22:04:47] INFO WEBrick::HTTPServer#start done.
I'm betting that the reason it does so is the trap("INT") in the app. Is there a way to get the debugger's SIGINT handler priority
over application handling? (I'm running on WinXP, if p;atform matters.)

TIA

Unforunately no. If your application traps the INT signal as you are
stuck as this is THE mechanism that the debugger itself uses to pause
in the trace function.

So for now the only thing you can do is comment out the portion of the
code tht does the trap.

And for sure the debugger should definitely redefine the trap method
to catch any new definition of signal handler attached to INT. But
this is not the way it works for now.

Laurent