[GNC-dev] Debugging for Bug 797236 g_closure_invoke problem

John Ralls jralls at ceridwen.us
Wed Apr 1 21:00:50 EDT 2020



> On Mar 31, 2020, at 9:29 PM, Chris Good <goodchris96 at gmail.com> wrote:
> 
> 
> By adding breakpoints in refresh_handler and gnc_reconcile_view_refresh I
> can see that gnc_reconcile_view_refresh() is being called 8 times (4 times
> for each of the debits + credits panel) and only on the 2nd call for the
> debit panel is cursor_path not NULL. I don't understand why only 1 of the 4
> calls for the debit panel has a cursor path?

Because the debit panel doesn't have focus when those refresh events fire. refresh_handler is registered to the component manager (gnucash/gnome-utils/gnc-component-manager.c) which runs all of the registered event handlers when anything emits a qof_event or calls gnc_gui_refresh_all(). It's quite possible that some of those events have nothing at all of interest to the reconcile window.

As long as the events aren't being put on the main loop then the emission should be in the stack trace though it may be several frames down.
> 
> Up until now, the panel still displays on the 2nd page of splits where it
> was before the Balance button was used.
> 
> 
> 
> Resuming after the 8th call, the debugger gets: No source available for
> "g_closure_invoke() at (address)"
> 
> and I can only Resume.
> 
> 
> 
> I guess g_closure_invoke() is a gtk3 function and I need to install the gtk3
> dev packages which are not stripped? How do I integrate them into my Eclipse
> build?


A g_closure is just a wee bundle containing the callback and parameters registered to an event or a signal. Connecting to the signal or registering a handler on an event adds the closure to a list and when the signal or event fires it runs down the list calling g_closure_invoke() on each one. You probably don't need to step into that. There should be a way to call the 'finish' command that runs the current stack frame to completion and stops at the place it was called in the next one. Just do that until you get back into GnuCash code unless you have a reason to thing that Glib or Gtk is doing something wrong. That's unlikely in this case, it's more likely that either deleting the split doesn't emit a QofEvent or something about the refresh view's handler is filtering it out.

Regards,
John Ralls



More information about the gnucash-devel mailing list