Ruby app core dump on shutdown

[Grant Schoep]

So my work computers are down for part of the day I thought I would post
a question on a problem that I have been really trying to track down. I
have a Ruby/GTK that runs fine through out is operations. But will segv
and core on shutdown. This is an OS level core, not a "ruby core" where
it gives a Ruby like stack trace.

I'm using Ruby 1.9.2p-180(I was on older but tried to uprade) Running on
RHEL 5.4.


My basic question, I am very familier with debugging core files with gdb
on C/C++ applications, but of course the Ruby core files are not as
helpful.

My gut feel of this problem, is it is in one of my C extensions. But I
am wondering how some of you have dealt with really tracking down what
is going on. I have the feeling the problem is in garbage collection,
since it happens after my last statement in my application.

I run in VERBOSE and DEBUG, bot nothing stands out. I've also ran under
valgrind, but its really hard to tell what a normal ruby warnings and
not. I've even tried to build up a "Good valgrind Ruby suppression" file
by making apps that I know have absolutly no problems.

So anyone have a tip or pointer or other cool tool to really try to
figure out what/where the problem is. This application runs perfectly
fine under Ruby 1.8.6, but when I went up to Ruby 1.9.2, made the small
neccesary chages, it will crash at shutdown.

Thanks

 

[andrew mcelroy]

So my work computers are down for part of the day I thought I would post
a question on a problem that I have been really trying to track down. I
have a Ruby/GTK that runs fine through out is operations. But will segv
and core on shutdown. This is an OS level core, not a "ruby core" where
it gives a Ruby like stack trace.

I can has coredump in form of gist (github gist.. or pastie) please?

It's all pure speculation until we can see what this coredump says.

Andrew McElroy

 

[Roger Pack]

does gdb help at all in this case?

 

[Grant Schoep]

Roger Pack wrote in post #994110:

does gdb help at all in this case?

This is where I don't think gdb is helping me out, the first point where
shows is

(gdb) where
#0 0x8744568d in ?? ()
Cannot access memory at address 0x8744568c

All the rest of the threads are in varying states of
#0 0x40000402 in __kernel_vsyscall ()

I have attached a "thread apply all where"
that shows all the threads

I'm loading the core file via

"gdb /prod/ruby/bin/ruby core.12345"

Where /prod/ruby/bin/ruby is the ruby interpreter the ruby script was
using.

Attachments:
http://www.ruby-forum.com/attachment/6139/gdb.where.txt