Trapping 'exit from ruby world' in a C extension

ruby-talk
1

I've looking into a problem with the QtRuby extension when it occasionally
crashes on exit. I think it's caused be ruby finalizing the objects in an
arbitrary order. What I'd like to be able to do is to have a hook so that I
can call the C++ destructor on the top level application instance,
KApplication while the ruby world is still complete. I've found a function
called 'rb_trap_exit()', but I'm not sure if that's intended for this use.

Here is the top of the crash trace. rb_gc_call_finalizer_at_exit() has
probably deleted some things already before ~x_KApplication() is called and
which were still needed.

#38 0×0f3a7bb8 in x_KApplication::~x_KApplication() ()
from /opt/kde3/lib/libsmokekde.so.1
#39 0×0f36deb8 in xcall_KApplication(short, void*, Smoke::Stack Item?*) ()
from /opt/kde3/lib/libsmokekde.so.1
#40 0×0fc6b0f8 in smokeruby_free(void*) ()
from /usr/lib/ruby/site_ruby/1.8/powerpc-linux/korundum.so
#41 0×0ff57218 in rb_gc_call_finalizer_at_exit () at gc.c:1800
#42 0×0ff35070 in ruby_finalize_1 () at eval.c:1379
#43 0×0ff35260 in ruby_cleanup (ex=0) at eval.c:1416
#44 0×0ff35594 in ruby_stop (ex=0) at eval.c:1447
#45 0×0ff35608 in ruby_run () at eval.c:1459
#46 0×100017fc in __libc_csu_init () at main.c:50
#47 0×0fcbb04c in __libc_start_main (argc=2, ubp_av=0×0, ubp_ev=0×0,

-- Richard

2

Richard Dale wrote:

I've looking into a problem with the QtRuby extension when it occasionally
crashes on exit. I think it's caused be ruby finalizing the objects in an
arbitrary order. What I'd like to be able to do is to have a hook so that
I can call the C++ destructor on the top level application instance,
KApplication while the ruby world is still complete. I've found a function
called 'rb_trap_exit()', but I'm not sure if that's intended for this use.

Here is the top of the crash trace. rb_gc_call_finalizer_at_exit() has
probably deleted some things already before ~x_KApplication() is called
and which were still needed.

I've actually managed to solve this problem a different way now, by deleting
the QApplication or KApplication C++ instance after they return from the
top level exec() call and before the ruby program exits.

-- Richard