Ruby进程在脚本结束、分析、解决方案后达到100%



更新:我的相关问题中的问题-Nokogiri性能问题

我的程序出现了严重问题。在程序到达最后一行语句后,Aptana工作室显示,即使在评估了最后一行之后,程序仍在运行。Ruby进程(在脚本的最后一行之后)仍然以100%的CPU使用率运行,它在几秒钟后结束(可能是15-30秒)。我试着至少看看问题出在哪里,但过了很长时间,我仍然处于开始阶段。所以问题是,是什么导致了这个问题,我怎么才能至少看到问题在哪里,我有什么选择?一些附加信息:

Aptana debbug模式:在最后一行之后,这将显示在Debug窗口中:<terminated, exit value: 0>path/to/ruby但Ruby进程仍在运行,并且使用100%的CPU

我曾试图使用gdb来评测Ruby进程本身,但最终并没有使用本文描述的方法:使用gdb进行评测。我使用的是debian挤压64位,我尝试了两个版本的脚本(8,12>16,24)。当我试图获得一些堆栈信息时,我只得到了这个:

Program received signal SIGSEGV, Segmentation fault.
0x00007f20539a80b8 in ?? () from /lib/libc.so.6
/home/giron/programovani/gdb_init.sh:1: Error in sourced command file:
The program being debugged was signaled while in a function called from GDB.
GDB remains in the frame where the signal was received.
To change this behavior use "set unwindonsignal on".
Evaluation of the expression containing the function
(backtrace) will be abandoned.
When the function is done executing, GDB will silently stop.

退出gdb后,Aptana控制台中显示以下输出(但这可能完全没有用,可能是gdb做的,我不知道):

/home/giron/Aptana Studio 3 Workspace/RedisXmlConcept/bin/main.rb: [BUG] Segmentation fault
ruby 1.9.2p290 (2011-07-09 revision 32553) [x86_64-linux]
-- control frame ----------
c:0001 p:0000 s:0002 b:0002 l:000f68 d:000f68 TOP   
---------------------------
-- C level backtrace information -------------------------------------------
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(rb_vm_bugreport+0x5f)[0x7f205488216f]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(+0x63274) [0x7f205476a274]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(rb_bug+0xb3) [0x7f205476a413]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/lib/libruby.so.1.9(+0x10c215) [0x7f2054813215]
/lib/libpthread.so.0(+0xeff0) [0x7f20544f9ff0]
/lib/libc.so.6(+0xe40b8) [0x7f20539a80b8]
/lib/libgcc_s.so.1(_Unwind_Backtrace+0x49) [0x7f2050d5b599]
/lib/libc.so.6(backtrace+0x4e) [0x7f20539a81ae]
/home/giron/.rvm/rubies/ruby-1.9.2-p290/bin/ruby(_start+0) [0x400890]
[NOTE]
You may have encountered a bug in the Ruby interpreter or extension libraries.
Bug reports are welcome.
For details: http://www.ruby-lang.org/bugreport.html

为了确保我已经很好地描述了这个问题,最后一行代码(在此之前,Nokogiri解析和Redis数据库的工作已经完成):

puts "End"

结束被打印出来,在这个Ruby过程之后,将在几秒钟内消耗100%的CPU

这个问题与我之前的一个问题有关:Nokogiri性能问题,这里有更多的代码片段,但由于我在这里关注不同的方法(评测Ruby),我提出了新的问题。

提前谢谢你的任何提示,我现在几乎一无所知。

我试图使用gdb来评测Ruby进程本身

不要那样做。在您正在执行的上下文中,调用backtrace可能不安全,并且(显然)会导致程序变为SIGSEGV

相反,只需将gdb附加到Ruby进程,然后执行thread apply all where命令。用输出更新你的问题,你可能会得到更好的答案。

相关内容

  • 没有找到相关文章