Version: (using KDE 4.3.2) OS: Linux Installed from: Ubuntu Packages When Qt is not initialized and a static method of a QObject is called, ruby crashes. First reported on Launchpad: https://bugs.launchpad.net/ubuntu/+source/kdebindings/+bug/454597 Example with irb: $ irb irb(main):001:0> require 'Qt4' => true irb(main):002:0> Qt::SystemTrayIcon::isSystemTrayAvailable() (irb):2: [BUG] Segmentation fault ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux] Aborted This bug is not so much about the method not working as Ruby crashing, it should ideally post an error message indicating and error rather than crashing.
*** Bug 210989 has been marked as a duplicate of this bug. ***
It is not Ruby crashing but Qt (see backtrace). You're not supposed to do GUI stuff without creating a QApplication. #0 0x00007f4b48026549 in XInternAtom () from /usr/lib/libX11.so.6 #1 0x00007f4b4c4fca31 in QSystemTrayIconSys::locateSystemTray () at util/qsystemtrayicon_x11.cpp:72 #2 0x00007f4b4c4fcb09 in QSystemTrayIconPrivate::isSystemTrayAvailable_sys () at util/qsystemtrayicon_x11.cpp:379 #3 0x00007f4b4b393875 in __smokeqt::xcall_QSystemTrayIcon (xi=<value optimized out>, obj=0x3, args=0x1d9cc50) at /home/kde/build/KDE/kdebindings/smoke/qt/x_16.cpp:4553 #4 0x00007f4b4ae3fbb6 in QtRuby::MethodCall::callMethod (this=0x7fff56a578b0) at /home/kde/src/KDE/kdebindings/ruby/qtruby/src/marshall_types.h:148 #5 0x00007f4b4ae3daea in QtRuby::MethodCallBase::next (this=0x7fff56a578b0) at /home/kde/src/KDE/kdebindings/ruby/qtruby/src/marshall_types.cpp:467 #6 0x00007f4b4ae09a43 in class_method_missing (argc=1, argv=0x7fff56a57f10, klass=<value optimized out>) at /home/kde/src/KDE/kdebindings/ruby/qtruby/src/Qt.cpp:959 #7 0x00007f4b4e58c6c2 in rb_call0 (klass=139961418323440, recv=139961267698000, id=4057, oid=4057, argc=1, argv=0x7fff56a57f10, [...]
David is right about this. This is by design.
As I said before, it's not about Qt crashing, that's expected. But ruby, as an interpreted language, should not crash. Some error should be thrown ideally. But that's just my opinion and it's not a huge deal.
Due to the way Ruby's interpreter works, it honestly doesn't surprise me. I've seen far worse segfaults from ruby gems like ActiveLDAP when I maintained code that used it at a previous employer due to the way Ruby's garbage collector works. Since QtRuby and Korundum both are C++ bindings with complex internals, if any of the shared variables aren't properly marked, and the object is improperly destroyed from the stack without the mark and sweep gc's help, a crash of the interpreter will likely occur when it attempts to collect a stack trace for error output as early in the initialization of the binding. Richard, do think that maybe there are a few corner cases in the binding that would allow a shared object to be reaped too soon in this case?