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):
typedef int (*GWEN_CONFIGMGR_GETGROUP_FN)(GWEN_CONFIGMGR *mgr,
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...
Regards
Martin
--
"Things are only impossible until they're not"
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
