[GNC-dev] segmentation fault / gnucash crashing upon using online banking actions

John Ralls jralls at ceridwen.us
Mon Oct 14 20:13:44 EDT 2019

> On Oct 14, 2019, at 2:51 PM, Martin Preuss <martin at aqbanking.de> wrote:
> Hi,
> Am 14.10.19 um 21:51 schrieb Christian Stimming:
> [...]
>>> (gdb) bt full
>>> #0  0x00007fffd6075989 in GWEN_Text_EscapeToBuffer ()
>>>    at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60
>>> #1  0x00007fffbe22d5a3 in GWEN_ConfigMgrDir_AddGroupFileName ()
>>>    at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so
>>> #2  0x00007fffbe22e18e in GWEN_ConfigMgrDir_DeleteGroup ()
>>>    at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so
>>> #3  0x00007fffd632be8c in AB_Banking_ReadConfigGroup (ab=0x5555582f8820,
> [...]
> I don't understand this: I see no path from
> AB_Banking_ReadConfigGroup() to GWEN_ConfigMgrDir_DeleteGroup(),
> especially no direct one. This function isn't called from within
> AB_Banking_ReadConfigGroup().
> GWEN_ConfigMgrDir_DeleteGroup() is an implementation of the "virtual"
> function GWEN_ConfigMgr_DeleteGroup() and is only called from there, so
> there shouldn't be a direct connection between an outside function (in
> this case: AB_Banking_ReadConfigGroup()) to that implementation... THere
> should at least be a step between them...
> Maybe the problem is, that the definition of the "virtual" functions is
> just (example):
>                                          const char *groupName,
>                                          const char *subGroupName,
>                                          GWEN_DB_NODE **pDb);
> i.e. without GWENHYWFAR_CB.
> This shouldn't be a problem, since those functions are only called from
> within libgwenhywfar, which is built at the same time the config mgr
> plugin is built, using the same environment, so it should always be
> clear to the compiler how to call those functions, even on windows...


He's not on Windows, he's on Linux: /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so

It may be that something has written into the stack and trashed the backtrace.

One needs to interactively debug cases like that, starting from a breakpoint in GWEN_ConfigMgr_SetMkUniqueIdFromIdFn (which is where that call at banking_cfg.c line 413 is supposed to go) and stepping through until it crashes, then repeat, stepping into the crashed function, and so on. It usually takes me several runs in the debugger to isolate the right path to step into to find the actual location of the crash.

John Ralls

More information about the gnucash-devel mailing list