GDB is a great xNix debugger than is hugely useful into tracking down why a ruby process is hung. Below is a very simple how-to.
1. Install GDB
This is different between operating system. On Ubuntu, it is as simple as:
sudo apt-get install gdb
2. Find the hung process id
It will typically be the far left number associated with process you are looking for.
ps aux | grep ruby
3. Point GDB at that process
Once started you will see a lot of text scroll past.
gdb -p <process-id>
4. Print the backtrace
This is the part where you find what you are looking for.
bt
While this may look a little cryptic, it is a C backtrace and will tell you exactly where things are seizing. In this example it was a long running profiling tool that locked things up.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
#0 0x007611e0 in rb_stack_trace (result=0xbfd493ac, max_depth=64) at perftools.c:87 | |
#1 0x007613af in CpuProfiler::prof_handler (sig=27, signal_ucontext=0xbfd4958c, cpu_profiler=0x76b4e0) at src/profiler.cc:285 | |
#2 0x007622da in ProfileHandler::SignalHandler (sig=27, sinfo=0xbfd4950c, ucontext=0xbfd4958c) at src/profile-handler.cc:450 | |
#3 <signal handler called> | |
#4 0x08055b78 in catch_timer () | |
#5 <signal handler called> | |
#6 0x0018a606 in memcpy () from /lib/tls/i686/nosegneg/libc.so.6 | |
#7 0x11aebb00 in ?? () | |
#8 0x080573fa in stack_extend () | |
#9 0x0df18c24 in ?? () |
5. Go forth and fix your code
Now you just need to quit out of GDB; thank the world for its existance and go fix your code.
quit
Even better - http://weblog.jamisbuck.org/2006/9/22/inspecting-a-live-ruby-process
ReplyDelete