Created attachment 328199 [details] My Xchat-ruby script Description of problem: My Xchat ruby script crashes Xchat in every 8-10 minutes after I upgraded from ruby*-1.8.6.114-1.fc9 to ruby*-1.8.6.287-2.fc9. (ruby* = ruby, ruby-irb, ruby-libs, ruby-rdoc, ruby-ri) The script uses hook_timer(), I guess this triggers the bug. Everything works fine after I downgraded to ruby*-1.8.6.114-1.fc9. The script serves me for a long time, I used it on Fedora 7/8 before without problems. Version-Release number of selected component (if applicable): ruby*-1.8.6.287-2.fc9 xchat-ruby-1.2-6.fc9 xchat-2.8.4-16.fc9 How reproducible: Use my script with latest Fedora 9. Steps to Reproduce: 1. Install Fedora 9 with latest upgrades 2. Install Xchat, Xchat-ruby 3. Copy my script into ~/.xchat2/ 4. Start Xchat from a terminal and wait 8-10 minutes Actual results: [dap@dh ~]$ xchat (eval):171: stack level too deep (SystemStackError) (eval):171: [BUG] Segmentation fault ruby 1.8.6 (2008-08-11) [i386-linux] Aborted [dap@dh ~]$ Expected results: Additional info:
that might be a kind of side-effects from changes between 1.8.6.114 and 1.8.6.287 which possibly may spends more system stacks. There are nothing I can do in ruby package since your system configuration also affects this. what I can suggest you is: 1. consider to re-implement your script to reduce spending stacks by the recursive calls 2. change your resource configuration with ulimit to increase the process stack size.
Created attachment 328278 [details] simpler version of my xchat script Now I made my script more simpler, only about 30 lines of code, and crashes too. How could I write simpler than this?! Xchat stack usage is minimal and never grows: [dap@dh .xchat2]$ grep VmStk /proc/`pidof xchat`/status VmStk: 96 kB [dap@dh .xchat2]$ ulimit -s 10240 I tried with a bigger stack: [dap@dh ~]$ ulimit -s 20480 [dap@dh ~]$ ulimit -s 20480 [dap@dh ~]$ time xchat (eval):171: stack level too deep (SystemStackError) (eval):171: [BUG] Segmentation fault ruby 1.8.6 (2008-08-11) [i386-linux] Aborted real 1m55.442s user 0m4.264s sys 0m1.137s With the original stack size: real 2m37.588s user 0m4.539s sys 0m1.124s Runtime vary between 1-3 minutes, but bigger stack doesn't mean longer runtime. I can't believe that this is not a bug in ruby or xchat-ruby (but the later's version didn't changed with the upgrade).
then try to gather more information like ruby's backtrace. you can see how it's deeply stacked.