Re: Dispatch of GObject virtual functions in GtkMM

[Murray Cumming <murrayc murrayc com>]

On Thu, 2007-01-11 at 08:20 -0600, Matt Hoosier wrote:
> Oh, sorry; typographical errors didn't make my meaning very clear.
> 
> The test program which I attached earlier

Of course I had to comment out the on_expose_event() method, because it
calls the now non-existant Window::on_expose_event(). I found it rather
odd that it called Main::quit() anyway.

>  hangs forever on the
> Window::add() call.

It works for me. It shows a matrix of buttons and checkboxes. 

I built glibmm with
  --enable-vfuncs=no --enable-default-signal-handlers=no
and then I rebuilt gtkmm with
  --enable-demos=no --enable-examples=no

Could you post your exact test case and also the stacktrace, please.

Another thought: If these slowdowns are real and significant, then you
could invesigate them with a tool such as kcachegrind (after getting the
data from valgrind). kcachegrind isn't useful for IO-bound performance
problems, but should be fine for this.

>  When I take a look at the stacktrace in a
> debugger, the results make no sense:
> 
> There's only one thread, and none of the frames in its stack are
> resolvable to any known symbol. Not even the bottommost one, which
> should be main().
> 
> This is the exact set of symptoms that showed up when I was debugging
> the problem in glibmm which turned out to be caused by a wrong
> C_GNUC_NORETURN annotation.
> 
> But none of the various overrides of Container::add() seems to put
> that annotation on, so I'm out of obvious suspects to consider.

-- 
Murray Cumming
murrayc murrayc com
www.murrayc.com
www.openismus.com