Forum: Ruby Debugging endless loops

Announcement (2017-05-07): www.ruby-forum.com is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see rubyonrails.org/community and ruby-lang.org/en/community for other Rails- und Ruby-related community platforms.
D895471fbc8b3b1233a250186d542af8?d=identicon&s=25 Alexey Verkhovsky (alexeyv)
on 2006-01-22 19:05
(Received via mailing list)
Hi all,

Say, we have a Ruby app going into an endless loop (or perhaps a thread
deadlock) mode. Let us further assume that it happens in production and
you don't know how to reproduce it anywhere else. How would you debug
this?

Debugging these conditions in Java is trivial because of the "thread
dump" feature of JVM (where you send a kill -3 signal to a JVM process
and it spits out stack tracces of all threads to stdout). In any
environemnt where you can attach a debugger to a running app, it is not
heinously difficult either (although it may be problematic to attach a
debugger to a productiuon environment).

But what do I do if it's Ruby?

Alex Verkhovsky
Fe9b2d0628c0943af374b2fe5b320a82?d=identicon&s=25 Eero Saynatkari (rue)
on 2006-01-22 21:08
Alexey Verkhovsky wrote:
> Hi all,
>
> Say, we have a Ruby app going into an endless loop (or perhaps a thread
> deadlock) mode. Let us further assume that it happens in production and
> you don't know how to reproduce it anywhere else. How would you debug
> this?
>
> Debugging these conditions in Java is trivial because of the "thread
> dump" feature of JVM (where you send a kill -3 signal to a JVM process
> and it spits out stack tracces of all threads to stdout). In any
> environemnt where you can attach a debugger to a running app, it is not
> heinously difficult either (although it may be problematic to attach a
> debugger to a productiuon environment).
>
> But what do I do if it's Ruby?

Can you do ruby -rdebug program.rb instead of running it normally?

> Alex Verkhovsky


E
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 Florian GroÃ? (Guest)
on 2006-01-22 22:27
(Received via mailing list)
Alexey Verkhovsky wrote:

> Say, we have a Ruby app going into an endless loop (or perhaps a thread
> deadlock) mode. Let us further assume that it happens in production and
> you don't know how to reproduce it anywhere else. How would you debug this?
>
> But what do I do if it's Ruby?

This might work and give you a remote debugging back door. I'm just not
sure if it will survive deadlocks:

require 'breakpoint'
Breakpoint.activate_drb

Thread.new do
   Thread.current.priority = 100
   loop do
     begin
       breakpoint
     rescue Exception
     end
   end
end

You can then connect to your application with breakpoint_client.

You'll need the ruby-breakpoint library which is available from
http://ruby-breakpoint.rubyforge.org/
D895471fbc8b3b1233a250186d542af8?d=identicon&s=25 Alexey Verkhovsky (alexeyv)
on 2006-01-22 23:46
(Received via mailing list)
Eero Saynatkari wrote:

>>Say, we have a Ruby app going into an endless loop (or perhaps a thread
>>deadlock) mode. Let us further assume that it happens in production and
>>you don't know how to reproduce it anywhere else. How would you debug
>>this?
>>
>>
>Can you do ruby -rdebug program.rb instead of running it normally?
>
>
By the conditions of our imaginary problem, we only reproduce our
endless loop in the production environment, and -rdebug makes a typical
Ruby code two orders of magnitude slower, so this wouldn't do.

Florian GroÃ? wrote:
 > This might work and give you a remote debugging back door. I'm just
not sure if it will survive deadlocks:
 > require 'breakpoint'
...
 > You can then connect to your application with breakpoint_client.

Hi, Florian,
Remote 'breakpointer' might be a workable idea. But when I am in IRB,
how do I get stack traces for all currently running threads?
Rest assured, I do know where to find 'breakpoint' library - I keep
telling about it to everyone pissed off or puzzled by the absence of a
decent debugger in the Ruby world.

Alex
E0ed615bd6632dd23165e045e3c1df09?d=identicon&s=25 Florian GroÃ? (Guest)
on 2006-01-23 00:07
(Received via mailing list)
Alexey Verkhovsky wrote:

> Hi, Florian,

Moin Alexey.

> Remote 'breakpointer' might be a workable idea. But when I am in IRB,
> how do I get stack traces for all currently running threads?

Ouch, I'm afraid this is yet another case where Ruby's reflection isn't
as useful as it could be...

You can get the backtrace via Thread#raise (set
thread.abort_on_exception to true first and catch the exception which
will have the backtrace) but it has the rather unfortunate side effect
of killing Ruby in the process.

I really think that Thread#caller would be a good idea...

> Rest assured, I do know where to find 'breakpoint' library - I keep
> telling about it to everyone pissed off or puzzled by the absence of a
> decent debugger in the Ruby world.

And I hope I'll be able to finally add a sensible GUI soon enough.
Thanks for the kind words.
D895471fbc8b3b1233a250186d542af8?d=identicon&s=25 Alexey Verkhovsky (alexeyv)
on 2006-01-23 00:25
(Received via mailing list)
Florian GroÃ? wrote:

> I really think that Thread#caller would be a good idea...

As well as a thread dump default signal handler on "kill -3". In some
circumstances, this Java feature is just priceless.

Alex
D812408537ac3a0fa2fec96eb8811559?d=identicon&s=25 John Carter (Guest)
on 2006-01-23 04:19
(Received via mailing list)
On Mon, 23 Jan 2006, Alexey Verkhovsky wrote:

> Say, we have a Ruby app going into an endless loop (or perhaps a thread
> deadlock) mode. Let us further assume that it happens in production and you
> don't know how to reproduce it anywhere else. How would you debug this?


Thread.abort_on_exception = true




John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong
later."

From this principle, all of life and physics may be deduced.
D895471fbc8b3b1233a250186d542af8?d=identicon&s=25 Alexey Verkhovsky (alexeyv)
on 2006-01-23 05:48
(Received via mailing list)
John Carter wrote:

>> Say, we have a Ruby app going into an endless loop (or perhaps a
>> thread deadlock) mode. Let us further assume that it happens in
>> production and you don't know how to reproduce it anywhere else. How
>> would you debug this?
>
> Thread.abort_on_exception = true

Neither endless loop, nor deadlock are exception conditions.

Alex
D812408537ac3a0fa2fec96eb8811559?d=identicon&s=25 John Carter (Guest)
on 2006-01-23 20:56
(Received via mailing list)
On Mon, 23 Jan 2006, Alexey Verkhovsky wrote:

> John Carter wrote:
>
>>> Say, we have a Ruby app going into an endless loop (or perhaps a thread
>>> deadlock) mode. Let us further assume that it happens in production and
>>> you don't know how to reproduce it anywhere else. How would you debug
>>> this?
>>
>> Thread.abort_on_exception = true
>
> Neither endless loop, nor deadlock are exception conditions.

Yup, but if a thread dies and you don't have a handler of last resort
nor
have set abort on exception, it just dies silently. ie. You may think
your
problem is a deadlock or infinite loop, but your actual problem may be a
needed thread has quietly died.


John Carter                             Phone : (64)(3) 358 6639
Tait Electronics                        Fax   : (64)(3) 359 4632
PO Box 1645 Christchurch                Email : john.carter@tait.co.nz
New Zealand

Carter's Clarification of Murphy's Law.

"Things only ever go right so that they may go more spectacularly wrong
later."

From this principle, all of life and physics may be deduced.
5befe95e6648daec3dd5728cd36602d0?d=identicon&s=25 Robert Klemme (Guest)
on 2006-01-24 17:40
(Received via mailing list)
Alexey Verkhovsky wrote:
> environemnt where you can attach a debugger to a running app, it is
> not heinously difficult either (although it may be problematic to
> attach a debugger to a productiuon environment).
>
> But what do I do if it's Ruby?

You can write a singnal handler that outputs current thread states.
set_trace_func may help here also.

Kind regards

    robert
Dba0cb4cdad3b8e3b7ed0fddff5d20a5?d=identicon&s=25 Stephen Kellett (Guest)
on 2006-01-24 18:20
(Received via mailing list)
In message <43D3C973.1010306@verk.info>, Alexey Verkhovsky
<alex@verk.info> writes
>But what do I do if it's Ruby?

What about a flow tracer?

Ruby Bug Validator. http://www.softwareverify.com

Stephen
This topic is locked and can not be replied to.