From: Joel VanderWerf <vjoel@...>
Date: 2005-11-12T05:12:49+09:00
Subject: Re: Getting a stack trace of a running Ruby program.

Ron M wrote:
> 
> Is there a way of displaying the stack trace of a running ruby program
> without killing it?
> 
> Java virtual machines(*) will show the stack trace(s) of a running program
> if you send them a QUIT signal (or on windows <ctrl><break>) without
> stopping
> the program.   On Linux, the "pstack" program gives you the same
> capabilities
> for C programs.
> 
> This is useful when a program runs for days and gets gradually slower.  By
> periodically sending QUIT signals you can essentally poll the program's
> stack to see where it's getting slow.
> 
> Is there any way to do similar in Ruby?   Even if I need to attach using
> GDB, it would help me - but I'd need someone to point me to what data
> structures I should look at with the debugger.  Otherwise, I think it'd
> be a really nice feature if, like java, a QUIT signal could show the
> stack trace(s) of the existing nthread(s) without killing an application
> 
> 
>    Ron
> 
> * http://java.sun.com/developer/technicalArticles/Programming/Stacktrace/
> * http://linuxcommand.org/man_pages/pstack1.html

Yes, this is a very late comment to this thread, but as it happens I
needed something like this last week. Unfortunately none of the proposed
solutions in this thread would have worked for me, because I was
debugging a multithreaded ruby process. (I was debugging from inside the
process using irb while other threads ran.)

Robert Klemme's suggestion to fork and raise an exception is nice, but
only works an a single thread. A forked ruby process keeps only one
thread from the parent (unless something has changed since 1.8.2):

  threads = (0..3).map {Thread.new {sleep}}

  p Thread.list.size # ==> 5

  sleep 1

  fork do
    p Thread.list.size # ==> 1
  end

  sleep 1

In any case, #fork doesn't work on all platforms.

Eric Hodel's suggestion to trap some signal and use #caller is also
nice, but only gives you information about one thread (the main thread,
IIRC).

Robert also suggested set_trace_func. But that doesn't tell you where
your threads are sleeping, unless you've enabled the trace func before
the threads went to sleep. Keeping set_trace_func enabled can have
serious overhead costs.

It would be very nice to be able to ask a thread for its current backtrace.

-- 
      vjoel : Joel VanderWerf : path berkeley edu : 510 665 3407