[Kde-bindings] debugging a korundum program after a crash

[Richard Dale]

On Tuesday 31 March 2009 09:52:02 Stefano Crocco wrote:
> Alle Monday 30 March 2009, Richard Dale ha scritto:
> > On Monday 30 March 2009 10:38:57 Stefano Crocco wrote:
> > > My korundum4 program is randomly crashing. By 'crashing', I don't mean
> > > it's raising an exception which isn't caught, but that it's crashing at
> > > the C++ level. This could mean I just found a bug in qtruby or korundum
> > > but it's much more likely that it simply means my program is doing
> > > something it shouldn't.
> > >
> > > If my program raised an exception, I could simply look at the line
> > > where the exception was raised and from there follow the program flow
> > > and try to understand what's wrong. Of course, with a C++-level crash,
> > > I can't do that, since the backtrace only contains calls to
> > > qt/kde/smoke/qtruby/ruby internal functions.
> > >
> > > Do you have any advice on how to proceed?
> >
> > Post the C++ backtrace on the mailing list in case that gives a clue
> > about the cause. Try to make the smallest program that is possible that
> > reproduces the crash. Does it still crash if you turn off garbage
> > collection with 'GC.disable'?
>
> Thanks for your answer. I tried disabling garbage collection, but the
> errors persisted. As for making the smallest program that reproduces the
> crash, this is going to be difficult, for two reasons: first, the crashes
> are random, so that the same operation sometimes works and sometimes
> crashes; second I think the bugs I see seem to be caused by the interaction
> among several pieces of my application, so I don't think I can make a
> smaller program. At any rate, I'll post the backtrace as soon as I get the
> crash again.
>
> However, I think I found a way to at least find out were the crash happens:
> since I know which actions can lead to a crash, I use set_trace_func just
> before those points, so that I can at least see where the crash happens.
>
> The first results haven't as yet given me any clue as to the cause of the
> crashes. However, I've found an exception being raised by the following
> code (simplified):
>
> class Document < Qt::Object
>
>   def method_missing name, *args, &blk
>     begin super
>     rescue NoMethodError, NameError
>       @doc.send name, *args, &blk
>     end
>   end
>
>   ...
>
> end
>
> What I'm trying to do here is to create a wrapper around an instance of
> KTextEditor::Document (stored in @doc). The idea is that, if a method isn't
> defined in Document, it should forward it to @doc. Since I know that qtruby
> uses method_missing itself, I first called the Qt::Object implementation of
> method_missing and only if it fails I pass the method call to @doc. Do you
> known whether what I'm doing here is safe? I admit I don't like it at all,
> and I'd like to replace it with something else (most likely using the
> Forwardable module), but I've never done that because of the huge number of
> methods in KTextEditor::Document.
>
Yes I can't see anything wrong with using method_missing to divert method 
calls. I do something similar in the Plasma Ruby bindings to forward calls 
from the scripting applet code to the underlying c++ applet:

    # If a method is called on a PlasmaScripting::Applet instance is found to 
be missing
    # then try calling the method on the underlying Plasma::Applet in the 
ScriptEngine.
    def method_missing(method, *args)
      begin
        super(method, *args)
      rescue
        applet_script.applet.method_missing(method, *args)
      end
    end

    def self.const_missing(name)
      begin
        super(name)
      rescue
        Plasma::Applet.const_missing(name)
      end
    end

-- Richard