Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
Thanks for helping me out with this. How could I oversee this? I removed all those much older repository packages which I had installed some time late at night tired from failing. Compiling succeeded with de_DE and we're back in book keeping! Online actions working fine. Trying to transfer a donation via Gnucash SEPA transfer to Geert Jaansens account failed somehow. I will use the Browser for now and look into that issue tommorrow. Best wishes to all of you have a great day Alex PS. tax export still crashing giving segmentation fault error. On Tue, 15 Oct 2019 06:08:29 -0400 "Derek Atkins" wrote: > Hi, > > It looks like you may have a system-installed libgwenhywfar? It's > finding (and using) one from /usr/lib/x86_64-linux-gnu/ ?? > > -derek > > > On Tue, October 15, 2019 6:00 am, Alex wrote: > > First of all, I forgot to say I'm on Linux Debian, sorry @Martin > > for not mentioning! > > > > Dear Christian, > > > > I'm not sure if the "--enable-debug" flag changed the output of > > the first lines of the gdb backtrace in any way, please see > > below, to me they seem just the same... > > > > Here's what I dit: > > > > recompiled gwenhywfar: > > I did not git pull, so we are as of Oct 14th. > > $ export LANG="C" > > $ ./configure --with-guis="gtk3" --enable-debug > > > > also recompiled aqb and gnucash. > > > > Then ran: > > $ gdb gnucash > > (gdb) run --debug --extra > > Starting program: /usr/local/bin/gnucash --debug --extra > > [Thread debugging using libthread_db enabled] > > Using host libthread_db library > > "/lib/x86_64-linux-gnu/libthread_db.so.1". [ … here's some > > various gnucash startup debugging outputs … ] > > > > Gnucash is open. Empty file. I enter the aqbanking wizard > > straight away, "edit" the only existing user, "get certificate", > > OK, "Get Bank Info", Crash. > > > > Here's the first lines of the backtrace: > > > > Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. > > 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () > >from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > > (gdb) bt full > > #0 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () > > at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > > #1 0x7fffba4325a3 in GWEN_ConfigMgrDir_AddGroupFileName () > > at > > /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > > #2 0x7fffba43318e in GWEN_ConfigMgrDir_DeleteGroup () at > > /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > > #3 0x7fffd6539e8c in AB_Banking_ReadConfigGroup > > (ab=0x57dda620, groupName=groupName@entry=0x7fffd66b8393 > > "users", uniqueId=uniqueId@entry=1, doLock=doLock@entry=1, > > doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff70c8) at > > banking_cfg.c:413 rv = > > idBuf = > > "\230'\aXUU\000\000\002\000\000\000\000\000\000\000\000(\aXUU", > > '\000' , > > "Q\303\312\352\377\177\000\000\000\000\000\000\000\000\000\000\020%\217UUU\000\000 > > \217\225UUU\000\000\300m\377\377\377\177\000\000\377\377\377\377\377\377\377\377\357\252\312\352\377\177\000\000\000\000\000\000\000\000\000\000\030\275\024\367\377\177\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000@\257\225UUU\000\000pn\377\377\377\177\000\000c\276\024\367\377\177\000\000pn\377\377\377\177\000\000\277\276\024\367\377\177\000\000\v\272\336\352\377\177\000\000\200\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\000"... > > __PRETTY_FUNCTION__ = "AB_Banking_ReadConfigGroup" > > #4 0x7fffd653d9a1 in AB_Banking_Read_UserConfig > > (ab=, uid=uid@entry=1, doLock=doLock@entry=1, > > doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff70c8) > > at banking_user.c:20 > > rv = > > #5 0x7fffd6552110 in AB_Provider_ReadUser > > (pro=pro@entry=0x57b0a2f0, uid=uid@entry=1, > > doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, > > user=user@entry=0x57b0b900) at provider_user.c:24 > > rv = > > db = 0x0 > > uidInDb = > > #6 0x7fffd6552b77 in AB_Provider_BeginExclUseUser > > (pro=0x57b0a2f0, u=0x57b0b900) at provider_user.c:226 > > rv = > > uid = 1 > > [ … and so on … ] > > > > Please let me know if I can do anything else. > > > > Kindly > > Alex > > > > On Mon, 14 Oct 2019 21:51:41 +0200 > > Christian Stimming wrote: > >
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
As derek already said: you are using a system-installed gwenhywfar. You need to check at aqbanking configure time that it really chose the correct libgwenhywfar, and gnucash subsequently too. Thanks! Christian > Am 15.10.2019 um 12:00 schrieb Alex : > > First of all, I forgot to say I'm on Linux Debian, sorry @Martin for not > mentioning! > > Dear Christian, > > I'm not sure if the "--enable-debug" flag changed the output of the first > lines of the gdb backtrace in any way, please see below, to me they seem just > the same... > > Here's what I dit: > > recompiled gwenhywfar: > I did not git pull, so we are as of Oct 14th. > $ export LANG="C" > $ ./configure --with-guis="gtk3" --enable-debug > > also recompiled aqb and gnucash. > > Then ran: > $ gdb gnucash > (gdb) run --debug --extra > Starting program: /usr/local/bin/gnucash --debug --extra > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [ … here's some various gnucash startup debugging outputs … ] > > Gnucash is open. Empty file. I enter the aqbanking wizard straight away, > "edit" the only existing user, "get certificate", OK, "Get Bank Info", Crash. > > Here's the first lines of the backtrace: > > Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. > 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () > from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > (gdb) bt full > #0 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () >at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > #1 0x7fffba4325a3 in GWEN_ConfigMgrDir_AddGroupFileName () >at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #2 0x7fffba43318e in GWEN_ConfigMgrDir_DeleteGroup () >at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #3 0x7fffd6539e8c in AB_Banking_ReadConfigGroup (ab=0x57dda620, > groupName=groupName@entry=0x7fffd66b8393 "users", uniqueId=uniqueId@entry=1, > doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, > pDb=pDb@entry=0x7fff70c8) at banking_cfg.c:413 >rv = >idBuf = > "\230'\aXUU\000\000\002\000\000\000\000\000\000\000\000(\aXUU", '\000' > , > "Q\303\312\352\377\177\000\000\000\000\000\000\000\000\000\000\020%\217UUU\000\000 > > \217\225UUU\000\000\300m\377\377\377\177\000\000\377\377\377\377\377\377\377\377\357\252\312\352\377\177\000\000\000\000\000\000\000\000\000\000\030\275\024\367\377\177\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000@\257\225UUU\000\000pn\377\377\377\177\000\000c\276\024\367\377\177\000\000pn\377\377\377\177\000\000\277\276\024\367\377\177\000\000\v\272\336\352\377\177\000\000\200\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\000"... >__PRETTY_FUNCTION__ = "AB_Banking_ReadConfigGroup" > #4 0x7fffd653d9a1 in AB_Banking_Read_UserConfig (ab=, > uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, > pDb=pDb@entry=0x7fff70c8) >at banking_user.c:20 >rv = > #5 0x7fffd6552110 in AB_Provider_ReadUser (pro=pro@entry=0x57b0a2f0, > uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, > user=user@entry=0x57b0b900) >at provider_user.c:24 >rv = >db = 0x0 >uidInDb = > #6 0x7fffd6552b77 in AB_Provider_BeginExclUseUser (pro=0x57b0a2f0, > u=0x57b0b900) at provider_user.c:226 >rv = >uid = 1 > [ … and so on … ] > > Please let me know if I can do anything else. > > Kindly > Alex > > On Mon, 14 Oct 2019 21:51:41 +0200 > Christian Stimming wrote: > >> Dear Alex, >> >> we're getting closer... the libaqbanking lines already have full >> debug info, but only the libgwenhywfar do not have it. Can you >> compile again gwenhywfar, this time with --enable-debug, so that >> the first few lines from the backtrace (only those are important) >> contain some more information such as the function arguments? This >> would be a big help. Thanks! >> >> Regards, >> Christian >> >> Am Montag, 14. Oktober 2019, 18:15:00 CEST schrieb Alex: >>> Here is a backtrace of Gnucash when crashing upon clicking on >>> "Get Bank Info" in the aqbanking wizard. Let me know if I can do >>> anything else. >>> >>> -- GDB BACKTRACE START --- >>> >>> Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. >>> 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () &g
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
Hi, It looks like you may have a system-installed libgwenhywfar? It's finding (and using) one from /usr/lib/x86_64-linux-gnu/ ?? -derek On Tue, October 15, 2019 6:00 am, Alex wrote: > First of all, I forgot to say I'm on Linux Debian, sorry @Martin for not > mentioning! > > Dear Christian, > > I'm not sure if the "--enable-debug" flag changed the output of the first > lines of the gdb backtrace in any way, please see below, to me they seem > just the same... > > Here's what I dit: > > recompiled gwenhywfar: > I did not git pull, so we are as of Oct 14th. > $ export LANG="C" > $ ./configure --with-guis="gtk3" --enable-debug > > also recompiled aqb and gnucash. > > Then ran: > $ gdb gnucash > (gdb) run --debug --extra > Starting program: /usr/local/bin/gnucash --debug --extra > [Thread debugging using libthread_db enabled] > Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". > [ … here's some various gnucash startup debugging outputs … ] > > Gnucash is open. Empty file. I enter the aqbanking wizard straight away, > "edit" the only existing user, "get certificate", OK, "Get Bank Info", > Crash. > > Here's the first lines of the backtrace: > > Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. > 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () >from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > (gdb) bt full > #0 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () > at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > #1 0x7fffba4325a3 in GWEN_ConfigMgrDir_AddGroupFileName () > at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #2 0x7fffba43318e in GWEN_ConfigMgrDir_DeleteGroup () > at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #3 0x7fffd6539e8c in AB_Banking_ReadConfigGroup (ab=0x57dda620, > groupName=groupName@entry=0x7fffd66b8393 "users", > uniqueId=uniqueId@entry=1, doLock=doLock@entry=1, > doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff70c8) at > banking_cfg.c:413 > rv = > idBuf = > "\230'\aXUU\000\000\002\000\000\000\000\000\000\000\000(\aXUU", > '\000' , > "Q\303\312\352\377\177\000\000\000\000\000\000\000\000\000\000\020%\217UUU\000\000 > \217\225UUU\000\000\300m\377\377\377\177\000\000\377\377\377\377\377\377\377\377\357\252\312\352\377\177\000\000\000\000\000\000\000\000\000\000\030\275\024\367\377\177\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000@\257\225UUU\000\000pn\377\377\377\177\000\000c\276\024\367\377\177\000\000pn\377\377\377\177\000\000\277\276\024\367\377\177\000\000\v\272\336\352\377\177\000\000\200\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\000"... > __PRETTY_FUNCTION__ = "AB_Banking_ReadConfigGroup" > #4 0x7fffd653d9a1 in AB_Banking_Read_UserConfig (ab=, > uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, > pDb=pDb@entry=0x7fff70c8) > at banking_user.c:20 > rv = > #5 0x7fffd6552110 in AB_Provider_ReadUser > (pro=pro@entry=0x57b0a2f0, uid=uid@entry=1, doLock=doLock@entry=1, > doUnlock=doUnlock@entry=0, user=user@entry=0x57b0b900) > at provider_user.c:24 > rv = > db = 0x0 > uidInDb = > #6 0x7fffd6552b77 in AB_Provider_BeginExclUseUser > (pro=0x57b0a2f0, u=0x57b0b900) at provider_user.c:226 > rv = > uid = 1 > [ … and so on … ] > > Please let me know if I can do anything else. > > Kindly > Alex > > On Mon, 14 Oct 2019 21:51:41 +0200 > Christian Stimming wrote: > >> Dear Alex, >> >> we're getting closer... the libaqbanking lines already have full >> debug info, but only the libgwenhywfar do not have it. Can you >> compile again gwenhywfar, this time with --enable-debug, so that >> the first few lines from the backtrace (only those are important) >> contain some more information such as the function arguments? This >> would be a big help. Thanks! >> >> Regards, >> Christian >> >> Am Montag, 14. Oktober 2019, 18:15:00 CEST schrieb Alex: >> > Here is a backtrace of Gnucash when crashing upon clicking on >> > "Get Bank Info" in the aqbanking wizard. Let me know if I can do >> > anything else. >> > >> > -- GDB BACKTRACE START --- >> > >> > Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. >> > 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () >> >from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 >> > (gdb)
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
Additionally, here's the last lines of the /tmp/gnucash.trace file: * 11:48:56 INFO job_new.c: 339: Single message job │ * 11:48:56 INFO jobgetbankinfo.c: 71: JobGetBankInfo created │ * 11:48:56 INFO outbox.c: 1182: CBox for customer "XXX" not found │ * 11:48:56 MESSG outbox.c: 1203: Creating CBox for customer "XXX" │ * 11:48:56 INFO job.c: 616: Changing status of job "JobGetBankInfo" from "unknown" (0) to "todo" (1) │ * 11:48:56 INFO outbox.c: 1090: Locking customer "1" │ * 11:48:56 INFO provider_user.c: 224: Locking customer "1" On Tue, 15 Oct 2019 12:00:33 +0200 Alex wrote: > First of all, I forgot to say I'm on Linux Debian, sorry @Martin > for not mentioning! > > Dear Christian, > > I'm not sure if the "--enable-debug" flag changed the output of the > first lines of the gdb backtrace in any way, please see below, to > me they seem just the same... > > Here's what I dit: > > recompiled gwenhywfar: > I did not git pull, so we are as of Oct 14th. > $ export LANG="C" > $ ./configure --with-guis="gtk3" --enable-debug > > also recompiled aqb and gnucash. > > Then ran: > $ gdb gnucash > (gdb) run --debug --extra > Starting program: /usr/local/bin/gnucash --debug --extra > [Thread debugging using libthread_db enabled] > Using host libthread_db library > "/lib/x86_64-linux-gnu/libthread_db.so.1". [ … here's some various > gnucash startup debugging outputs … ] > > Gnucash is open. Empty file. I enter the aqbanking wizard straight > away, "edit" the only existing user, "get certificate", OK, "Get > Bank Info", Crash. > > Here's the first lines of the backtrace: > > Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. > 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () >from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > (gdb) bt full > #0 0x7fffd6283989 in GWEN_Text_EscapeToBuffer () > at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > #1 0x7fffba4325a3 in GWEN_ConfigMgrDir_AddGroupFileName () > at > /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so #2 > 0x7fffba43318e in GWEN_ConfigMgrDir_DeleteGroup () at > /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so #3 > 0x7fffd6539e8c in AB_Banking_ReadConfigGroup > (ab=0x57dda620, groupName=groupName@entry=0x7fffd66b8393 > "users", uniqueId=uniqueId@entry=1, doLock=doLock@entry=1, > doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff70c8) at > banking_cfg.c:413 rv = idBuf = > "\230'\aXUU\000\000\002\000\000\000\000\000\000\000\000(\aXUU", > '\000' , > "Q\303\312\352\377\177\000\000\000\000\000\000\000\000\000\000\020%\217UUU\000\000 > \217\225UUU\000\000\300m\377\377\377\177\000\000\377\377\377\377\377\377\377\377\357\252\312\352\377\177\000\000\000\000\000\000\000\000\000\000\030\275\024\367\377\177\000\000\377\377\377\377\377\377\377\377\000\000\000\000\000\000\000\000\002\000\000\000\000\000\000\000@\257\225UUU\000\000pn\377\377\377\177\000\000c\276\024\367\377\177\000\000pn\377\377\377\177\000\000\277\276\024\367\377\177\000\000\v\272\336\352\377\177\000\000\200\000\000\000\000\000\000\000\b\000\000\000\000\000\000\000\000"... > __PRETTY_FUNCTION__ = "AB_Banking_ReadConfigGroup" #4 > 0x7fffd653d9a1 in AB_Banking_Read_UserConfig (ab= out>, uid=uid@entry=1, doLock=doLock@entry=1, > out>doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff70c8) at > out>banking_user.c:20 rv = #5 0x7fffd6552110 > out>in AB_Provider_ReadUser (pro=pro@entry=0x57b0a2f0, > out>uid=uid@entry=1, doLock=doLock@entry=1, > out>doUnlock=doUnlock@entry=0, user=user@entry=0x57b0b900) at > out>provider_user.c:24 rv = db = 0x0 uidInDb = > out> #6 0x7fffd6552b77 in > out>AB_Provider_BeginExclUseUser (pro=0x57b0a2f0, > out>u=0x57b0b900) at provider_user.c:226 > rv = > uid = 1 > [ … and so on … ] > > Please let me know if I can do anything else. > > Kindly > Alex > > On Mon, 14 Oct 2019 21:51:41 +0200 > Christian Stimming wrote: > > > Dear Alex, > > > > we're getting closer... the libaqbanking line
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
> On Oct 14, 2019, at 2:51 PM, Martin Preuss wrote: > > Hi, > > Am 14.10.19 um 21:51 schrieb Christian Stimming: > [...] >>> (gdb) bt full >>> #0 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () >>>at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 >>> #1 0x7fffbe22d5a3 in GWEN_ConfigMgrDir_AddGroupFileName () >>>at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so >>> #2 0x7fffbe22e18e in GWEN_ConfigMgrDir_DeleteGroup () >>>at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so >>> #3 0x7fffd632be8c in AB_Banking_ReadConfigGroup (ab=0x582f8820, > [...] > > 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... Martin, 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. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
Hi, Am 14.10.19 um 21:51 schrieb Christian Stimming: [...] >> (gdb) bt full >> #0 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () >> at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 >> #1 0x7fffbe22d5a3 in GWEN_ConfigMgrDir_AddGroupFileName () >> at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so >> #2 0x7fffbe22e18e in GWEN_ConfigMgrDir_DeleteGroup () >> at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so >> #3 0x7fffd632be8c in AB_Banking_ReadConfigGroup (ab=0x582f8820, [...] 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
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
Dear Alex, we're getting closer... the libaqbanking lines already have full debug info, but only the libgwenhywfar do not have it. Can you compile again gwenhywfar, this time with --enable-debug, so that the first few lines from the backtrace (only those are important) contain some more information such as the function arguments? This would be a big help. Thanks! Regards, Christian Am Montag, 14. Oktober 2019, 18:15:00 CEST schrieb Alex: > Here is a backtrace of Gnucash when crashing upon clicking on "Get Bank > Info" in the aqbanking wizard. Let me know if I can do anything else. > > -- GDB BACKTRACE START --- > > Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. > 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () >from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > (gdb) bt full > #0 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () > at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > #1 0x7fffbe22d5a3 in GWEN_ConfigMgrDir_AddGroupFileName () > at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #2 0x7fffbe22e18e in GWEN_ConfigMgrDir_DeleteGroup () > at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #3 0x7fffd632be8c in AB_Banking_ReadConfigGroup (ab=0x582f8820, > groupName=groupName@entry=0x7fffd64aa393 "users", > uniqueId=uniqueId@entry=1, doLock=doLock@entry=1, > doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff71b8) at > banking_cfg.c:413 rv = > idBuf = "\005", '\000' , > "\001\000\000\000\000\000\000\000\000\210\221UUU\000\000\005\000\000\000\00 > 0\000\000\000V@\323\352\377\177\000\000\000\000\000\000\000\000\000\000X\213 > \221UUU\000\000pn\377\377\377\177\000\000\340!\336\367\377\177\000\000\000\2 > 10\221UUU\000\000\374\b\000\000\000\000\000\000\000\000\250UUU\000\000H\367\ > 374\325\377\177\000\000\200\033\376\325\377\177\000\000\363*\336\367\377\177 > \000\000\374\b\000\000\000\000\000\000\200\033\376\325\377\177\000\000\000\0 > 00\250UUU\000\000\030o\377\377\377\177\000\000\024o\377\377\377\177\000\000H > \367\374\325\377\177\000\000=\223\060\326\377\177\000\000\360\020\060\326\37 > 7\177\000\000\030o\377\377\377\177\000\000"... __PRETTY_FUNCTION__ = > "AB_Banking_ReadConfigGroup" > #4 0x7fffd632f9a1 in AB_Banking_Read_UserConfig (ab=, > uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, > pDb=pDb@entry=0x7fff71b8) at banking_user.c:20 > rv = > #5 0x7fffd6344110 in AB_Provider_ReadUser > (pro=pro@entry=0x559d8d20, uid=uid@entry=1, doLock=doLock@entry=1, > doUnlock=doUnlock@entry=0, user=user@entry=0x585e9720) at > provider_user.c:24 > rv = > db = 0x0 > uidInDb = ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
Here is a backtrace of Gnucash when crashing upon clicking on "Get Bank Info" in the aqbanking wizard. Let me know if I can do anything else. -- GDB BACKTRACE START --- Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 (gdb) bt full #0 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 #1 0x7fffbe22d5a3 in GWEN_ConfigMgrDir_AddGroupFileName () at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so #2 0x7fffbe22e18e in GWEN_ConfigMgrDir_DeleteGroup () at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so #3 0x7fffd632be8c in AB_Banking_ReadConfigGroup (ab=0x582f8820, groupName=groupName@entry=0x7fffd64aa393 "users", uniqueId=uniqueId@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff71b8) at banking_cfg.c:413 rv = idBuf = "\005", '\000' , "\001\000\000\000\000\000\000\000\000\210\221UUU\000\000\005\000\000\000\000\000\000\000V@\323\352\377\177\000\000\000\000\000\000\000\000\000\000X\213\221UUU\000\000pn\377\377\377\177\000\000\340!\336\367\377\177\000\000\000\210\221UUU\000\000\374\b\000\000\000\000\000\000\000\000\250UUU\000\000H\367\374\325\377\177\000\000\200\033\376\325\377\177\000\000\363*\336\367\377\177\000\000\374\b\000\000\000\000\000\000\200\033\376\325\377\177\000\000\000\000\250UUU\000\000\030o\377\377\377\177\000\000\024o\377\377\377\177\000\000H\367\374\325\377\177\000\000=\223\060\326\377\177\000\000\360\020\060\326\377\177\000\000\030o\377\377\377\177\000\000"... __PRETTY_FUNCTION__ = "AB_Banking_ReadConfigGroup" #4 0x7fffd632f9a1 in AB_Banking_Read_UserConfig (ab=, uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff71b8) at banking_user.c:20 rv = #5 0x7fffd6344110 in AB_Provider_ReadUser (pro=pro@entry=0x559d8d20, uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, user=user@entry=0x585e9720) at provider_user.c:24 rv = db = 0x0 uidInDb = #6 0x7fffd6344b77 in AB_Provider_BeginExclUseUser (pro=0x559d8d20, u=0x585e9720) at provider_user.c:226 rv = uid = 1 #7 0x7fffd642261f in AH_Outbox_LockUsers (lockedUsers=0x5597fa30, ob=0x5597fbd0) at outbox.c:1095 rv = cbox = 0x584093a0 rv = pid = 47 lockedUsers = 0x5597fa30 __PRETTY_FUNCTION__ = "AH_Outbox_Execute" #8 0x7fffd642261f in AH_Outbox_Execute (ob=ob@entry=0x5597fbd0, ctx=ctx@entry=0x583a0bd0, withProgress=withProgress@entry=1, nounmount=nounmount@entry=1, doLock=doLock@entry=1) at outbox.c:1550 rv = pid = 47 lockedUsers = 0x5597fa30 __PRETTY_FUNCTION__ = "AH_Outbox_Execute" #9 0x7fffd642d04b in AH_Provider_GetBankInfo (pro=, u=, ctx=ctx@entry=0x583a0bd0, withTanSeg=withTanSeg@entry=0, withProgress=withProgress@entry=1, nounmount=nounmount@entry=0, doLock=1) at provider_online.c:122 ab = h = 0x55a64db0 job = 0x58b080d0 ob = 0x5597fbd0 rv = hp = __PRETTY_FUNCTION__ = "AH_Provider_GetBankInfo" #10 0x7fffd638eb27 in AH_EditUserPinTanDialog_HandleActivatedGetBankInfo (dlg=0x55a85a00) at dlg_edituserpintan.c:756 xdlg = 0x55a469c0 rv = ctx = 0x583a0bd0 __PRETTY_FUNCTION__ = "AH_EditUserPinTanDialog_HandleActivatedGetBankInfo" #11 0x7fffd60908cd in GWEN_Dialog_EmitSignal () at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 #12 0x7fffd670da95 in Gtk3Gui_WPushButton_Clicked_handler () at /usr/local/lib/libgwengui-gtk3.so #13 0x7fffeb255f04 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #14 0x7fffeb270c85 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #15 0x7fffeb27137f in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #16 0x7fffece70d7d in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #17 0x7fffece70de5 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #18 0x7fffeb255c2f in g_closure_invoke () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #19 0x7fffeb267e84 in () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #20 0x7fffeb270f98 in g_signal_emit_valist () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #21 0x7fffeb27137f in g_signal_emit () at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 #22 0x7fffece6f1e0 in () at /usr/lib/x86_64-linux-gnu/libgtk-3.so.0 #23 0x7fffea1ea038 in ffi_call_unix64 () at /usr/lib/x86_64-linux-gnu/libffi.so.6 #24 0x7fffea1e9a9a in ffi_call () at /usr/lib/x86_64-linux-gnu/libffi.so.6 #25 0x7
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
HI, Please be sure to CC the list on all replies so that the other developers can actually respond. Me, I was just getting them more information. I am not looking into it. However, from the crash, it's crashing in GWEN, which is an AqB library. -derek On Mon, October 14, 2019 11:29 am, Alex wrote: > Hi Derek, > thanks for looking into it. > Here is a backtrace of Gnucash when crashing upon clicking on "Get Bank > Info" in the aqbanking wizard. Let me know if I can do anything else. > > -- GDB BACKTRACE START --- > > Thread 1 "gnucash" received signal SIGSEGV, Segmentation fault. > 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () >from /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > (gdb) bt full > #0 0x7fffd6075989 in GWEN_Text_EscapeToBuffer () > at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > #1 0x7fffbe22d5a3 in GWEN_ConfigMgrDir_AddGroupFileName () > at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #2 0x7fffbe22e18e in GWEN_ConfigMgrDir_DeleteGroup () > at /usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr/dir.so > #3 0x7fffd632be8c in AB_Banking_ReadConfigGroup (ab=0x582f8820, > groupName=groupName@entry=0x7fffd64aa393 "users", > uniqueId=uniqueId@entry=1, doLock=doLock@entry=1, > doUnlock=doUnlock@entry=0, pDb=pDb@entry=0x7fff71b8) at > banking_cfg.c:413 > rv = > idBuf = "\005", '\000' , > "\001\000\000\000\000\000\000\000\000\210\221UUU\000\000\005\000\000\000\000\000\000\000V@\323\352\377\177\000\000\000\000\000\000\000\000\000\000X\213\221UUU\000\000pn\377\377\377\177\000\000\340!\336\367\377\177\000\000\000\210\221UUU\000\000\374\b\000\000\000\000\000\000\000\000\250UUU\000\000H\367\374\325\377\177\000\000\200\033\376\325\377\177\000\000\363*\336\367\377\177\000\000\374\b\000\000\000\000\000\000\200\033\376\325\377\177\000\000\000\000\250UUU\000\000\030o\377\377\377\177\000\000\024o\377\377\377\177\000\000H\367\374\325\377\177\000\000=\223\060\326\377\177\000\000\360\020\060\326\377\177\000\000\030o\377\377\377\177\000\000"... > __PRETTY_FUNCTION__ = "AB_Banking_ReadConfigGroup" > #4 0x7fffd632f9a1 in AB_Banking_Read_UserConfig (ab=, > uid=uid@entry=1, doLock=doLock@entry=1, doUnlock=doUnlock@entry=0, > pDb=pDb@entry=0x7fff71b8) > at banking_user.c:20 > rv = > #5 0x7fffd6344110 in AB_Provider_ReadUser > (pro=pro@entry=0x559d8d20, uid=uid@entry=1, doLock=doLock@entry=1, > doUnlock=doUnlock@entry=0, user=user@entry=0x585e9720) > at provider_user.c:24 > rv = > db = 0x0 > uidInDb = > #6 0x7fffd6344b77 in AB_Provider_BeginExclUseUser > (pro=0x559d8d20, u=0x585e9720) at provider_user.c:226 > rv = > uid = 1 > #7 0x7fffd642261f in AH_Outbox_LockUsers (lockedUsers=0x5597fa30, > ob=0x5597fbd0) at outbox.c:1095 > rv = > cbox = 0x584093a0 > rv = > pid = 47 > lockedUsers = 0x5597fa30 > __PRETTY_FUNCTION__ = "AH_Outbox_Execute" > #8 0x7fffd642261f in AH_Outbox_Execute (ob=ob@entry=0x5597fbd0, > ctx=ctx@entry=0x583a0bd0, withProgress=withProgress@entry=1, > nounmount=nounmount@entry=1, doLock=doLock@entry=1) at outbox.c:1550 > rv = > pid = 47 > lockedUsers = 0x5597fa30 > __PRETTY_FUNCTION__ = "AH_Outbox_Execute" > #9 0x7fffd642d04b in AH_Provider_GetBankInfo (pro=, > u=, ctx=ctx@entry=0x583a0bd0, > withTanSeg=withTanSeg@entry=0, withProgress=withProgress@entry=1, > nounmount=nounmount@entry=0, doLock=1) at provider_online.c:122 > ab = > h = 0x55a64db0 > job = 0x58b080d0 > ob = 0x5597fbd0 > rv = > hp = > __PRETTY_FUNCTION__ = "AH_Provider_GetBankInfo" > #10 0x7fffd638eb27 in > AH_EditUserPinTanDialog_HandleActivatedGetBankInfo (dlg=0x55a85a00) at > dlg_edituserpintan.c:756 > xdlg = 0x55a469c0 > rv = > ctx = 0x583a0bd0 > __PRETTY_FUNCTION__ = > "AH_EditUserPinTanDialog_HandleActivatedGetBankInfo" > #11 0x7fffd60908cd in GWEN_Dialog_EmitSignal () > at /usr/lib/x86_64-linux-gnu/libgwenhywfar.so.60 > #12 0x7fffd670da95 in Gtk3Gui_WPushButton_Clicked_handler () > at /usr/local/lib/libgwengui-gtk3.so > #13 0x7fffeb255f04 in () at > /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #14 0x7fffeb270c85 in g_signal_emit_valist () > at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 > #15 0x7fffeb27137f in g_signal_emit () > at /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0 &g
Re: [GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
How about a GDB Backtrace? -derek On Mon, October 14, 2019 11:01 am, Alex wrote: > May anyone help me and others resolving this issue? > > Gnucash crashes upon online-actions with "segmentation fault" and maybe > other errors (see log / trace excerpts below). > > I had compiled and installed gwenhywfar (./configure --with-guis="gtk3") > and aqbanking bleeding edge from auqamaniac git, latest commits (as of Oct > 14th), including Revision 1f34d9ec (ID > 1f34d9ec49e890a96cf9ab3a4d16f3618c8aedf8) labeled with: "GTK3 GUI: Fixed > memory leaks." > $ aqbanking-config --vstring > 5.99.40 > $ gwenhywfar-config --vstring > 4.99.22 > > I had also compiled and installed Gnucash from github, maint branch. Tried > the following three cmake instructions, neither of them resolves the > issue: > cmake -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_PYTHON=ON -D > GENERATE_SWIG_WRAPPERS=ON ../gnucash-3.7/ > cmake ../gnucash-3.7/ > and finally: > cmake -D CMAKE_INSTALL_PREFIX=/usr/local ../gnucash-3.7/ > $ gnucash --version > GnuCash 3.7 development version > Build ID: git 3.7-131-g57e403b04+(2019-10-12) > > I used LANG="C" and LC_CTYPE="C" while compiling; Also tried "de_DE.UTF-8" > yesterday which did not make a difference. > > Seting up aqbanking profile/user according to the aqbanking wiki entry > "SetupPinTan" was no problem, everything works from the command line and > returns me my transactions without errors. So the communications with the > bank works - so far... > $ aqbanking-cli request --account=1234567890 --fromdate=20190913 > --transactions > asks for Pin and returns transactions as expected. > $ aqhbci-tool4 getsysid -u 1 > and other aqhbci commands show expected behaviour. > > But when using online actions in gnucash, like getting transactions or > getting sysinfo / itanmodes from the bank, Gnucash crashes with a > "segmentation fault" error. Btw: Same with tax reports / exports. > Getting the bank's certificate is the only online actions which does not > crash gnucash. > > Anybody help? My business book keeping is stuck for a few weeks already > because of that new PSD2 disaster. > I have read that at least a few other users are experiencing the same > issue right now. > > Please see log and trace excerpts below or get back to me with any > additional requests. > > banking server hbci url: https://hbci-pintan.gad.de/cgi-bin/hbciservlet > (GLS Bank eG, Bochum, Germany) > > LANG flag is set to LANG="C" at all times. > > export GWEN_LOGLEVEL=debug > export AQBANKING_LOGLEVEL=debug > export AQOFXCONNECT_LOGLEVEL=debug > export AQHBCI_LOGLEVEL=debug > > $ gnucash --debug --extra > This is a development version. It may or may not work. > Report bugs and other problems to gnucash-devel@gnucash.org > You can also lookup and file bug reports at https://bugs.gnucash.org > To find the last stable version, please refer to https://www.gnucash.org/ > (gnucash:13501): Gtk-WARNING **: 16:02:38.620: Theme parsing error: > gtk-widgets.css:186:14: not a number > (gnucash:13501): Gtk-WARNING **: 16:02:38.620: Theme parsing error: > gtk-widgets.css:186:14: Expected a string. > [… similar GTK warnings repeating with different values …] > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 250: Initializing I18N > module > 6:2019/10/14 16-02-38:gwen(13501):i18n.c: 199: Real locale is [C] > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 254: Initializing > InetAddr module > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 258: Initializing Socket > module > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 262: Initializing > Libloader module > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 266: Initializing Crypt3 > module > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 270: Initializing Process > module > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 274: Initializing Plugin > module > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 278: Initializing > DataBase IO module > 6:2019/10/14 16-02-38:gwen(13501):plugin.c: 558: Plugin type "dbio" > registered > 6:2019/10/14 16-02-38:gwen(13501):dbio.c: 106: Adding plugin path > [/usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/dbio] > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 282: Initializing > ConfigMgr module > 6:2019/10/14 16-02-38:gwen(13501):plugin.c: 558: Plugin type "configmgr" > registered > 6:2019/10/14 16-02-38:gwen(13501):configmgr.c: 80: Adding plugin path > [/usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr] > 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 286: Initializing > CryptToken2 module > 6:2019/10/1
[GNC-dev] segmentation fault / gnucash crashing upon using online banking actions
May anyone help me and others resolving this issue? Gnucash crashes upon online-actions with "segmentation fault" and maybe other errors (see log / trace excerpts below). I had compiled and installed gwenhywfar (./configure --with-guis="gtk3") and aqbanking bleeding edge from auqamaniac git, latest commits (as of Oct 14th), including Revision 1f34d9ec (ID 1f34d9ec49e890a96cf9ab3a4d16f3618c8aedf8) labeled with: "GTK3 GUI: Fixed memory leaks." $ aqbanking-config --vstring 5.99.40 $ gwenhywfar-config --vstring 4.99.22 I had also compiled and installed Gnucash from github, maint branch. Tried the following three cmake instructions, neither of them resolves the issue: cmake -D CMAKE_INSTALL_PREFIX=/usr/local -D WITH_PYTHON=ON -D GENERATE_SWIG_WRAPPERS=ON ../gnucash-3.7/ cmake ../gnucash-3.7/ and finally: cmake -D CMAKE_INSTALL_PREFIX=/usr/local ../gnucash-3.7/ $ gnucash --version GnuCash 3.7 development version Build ID: git 3.7-131-g57e403b04+(2019-10-12) I used LANG="C" and LC_CTYPE="C" while compiling; Also tried "de_DE.UTF-8" yesterday which did not make a difference. Seting up aqbanking profile/user according to the aqbanking wiki entry "SetupPinTan" was no problem, everything works from the command line and returns me my transactions without errors. So the communications with the bank works - so far... $ aqbanking-cli request --account=1234567890 --fromdate=20190913 --transactions asks for Pin and returns transactions as expected. $ aqhbci-tool4 getsysid -u 1 and other aqhbci commands show expected behaviour. But when using online actions in gnucash, like getting transactions or getting sysinfo / itanmodes from the bank, Gnucash crashes with a "segmentation fault" error. Btw: Same with tax reports / exports. Getting the bank's certificate is the only online actions which does not crash gnucash. Anybody help? My business book keeping is stuck for a few weeks already because of that new PSD2 disaster. I have read that at least a few other users are experiencing the same issue right now. Please see log and trace excerpts below or get back to me with any additional requests. banking server hbci url: https://hbci-pintan.gad.de/cgi-bin/hbciservlet (GLS Bank eG, Bochum, Germany) LANG flag is set to LANG="C" at all times. export GWEN_LOGLEVEL=debug export AQBANKING_LOGLEVEL=debug export AQOFXCONNECT_LOGLEVEL=debug export AQHBCI_LOGLEVEL=debug $ gnucash --debug --extra This is a development version. It may or may not work. Report bugs and other problems to gnucash-devel@gnucash.org You can also lookup and file bug reports at https://bugs.gnucash.org To find the last stable version, please refer to https://www.gnucash.org/ (gnucash:13501): Gtk-WARNING **: 16:02:38.620: Theme parsing error: gtk-widgets.css:186:14: not a number (gnucash:13501): Gtk-WARNING **: 16:02:38.620: Theme parsing error: gtk-widgets.css:186:14: Expected a string. [… similar GTK warnings repeating with different values …] 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 250: Initializing I18N module 6:2019/10/14 16-02-38:gwen(13501):i18n.c: 199: Real locale is [C] 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 254: Initializing InetAddr module 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 258: Initializing Socket module 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 262: Initializing Libloader module 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 266: Initializing Crypt3 module 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 270: Initializing Process module 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 274: Initializing Plugin module 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 278: Initializing DataBase IO module 6:2019/10/14 16-02-38:gwen(13501):plugin.c: 558: Plugin type "dbio" registered 6:2019/10/14 16-02-38:gwen(13501):dbio.c: 106: Adding plugin path [/usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/dbio] 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 282: Initializing ConfigMgr module 6:2019/10/14 16-02-38:gwen(13501):plugin.c: 558: Plugin type "configmgr" registered 6:2019/10/14 16-02-38:gwen(13501):configmgr.c: 80: Adding plugin path [/usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/configmgr] 7:2019/10/14 16-02-38:gwen(13501):gwenhywfar.c: 286: Initializing CryptToken2 module 6:2019/10/14 16-02-38:gwen(13501):plugin.c: 558: Plugin type "ct" registered 6:2019/10/14 16-02-38:gwen(13501):ctplugin.c: 65: Adding plugin path [/usr/lib/x86_64-linux-gnu/gwenhywfar/plugins/60/ct] 6:2019/10/14 16-02-41:gwen(13501):gui.c: 130: Using own callbacks in gui 0x555a52a6ec00 woop /usr/local/share/gnucash/python Hello from python! test dict_keys(['genericpath', […] [… lots of output here, no errors …] […] ,'xaccTransactionTraverse'] 7:2019/10/14 16-03-00:gwen(13501):urlfns.c: 175: Path: [/home/anon/.aqbanking/settings6] 7:2019/10/14 16-03-00:gwen(13501):libloa
Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791 - Segmentation fault when correcting invalid date
Am Samstag, 18. Januar 2014, 16:50:22 schrieb John Ralls: Author: jralls Date: 2014-01-18 16:50:21 -0500 (Sat, 18 Jan 2014) New Revision: 23706 Trac: http://svn.gnucash.org/trac/changeset/23706 Modified: gnucash/trunk/src/register/ledger-core/split-register-model.c Log: Bug 721791 - Segmentation fault when correcting invalid date And greatly simplify gnc_split_register_get_date_help by just getting a GDate and running g_date_strftime on it instead of messing around with Timespecs and g_localtime_r (twice!) and all of that just to make a stupid string. Thanks for fixing the bug! Note that the functions for using the GDate are still relatively new in gnucash. That's why in most cases they are not (yet) being used, even though they are more suitable and less error-prone and better altogether :-) Regards, Christian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: r23706 - gnucash/trunk/src/register/ledger-core - Bug 721791 - Segmentation fault when correcting invalid date
On Jan 18, 2014, at 2:47 PM, Christian Stimming christ...@cstimming.de wrote: Am Samstag, 18. Januar 2014, 16:50:22 schrieb John Ralls: Author: jralls Date: 2014-01-18 16:50:21 -0500 (Sat, 18 Jan 2014) New Revision: 23706 Trac: http://svn.gnucash.org/trac/changeset/23706 Modified: gnucash/trunk/src/register/ledger-core/split-register-model.c Log: Bug 721791 - Segmentation fault when correcting invalid date And greatly simplify gnc_split_register_get_date_help by just getting a GDate and running g_date_strftime on it instead of messing around with Timespecs and g_localtime_r (twice!) and all of that just to make a stupid string. Thanks for fixing the bug! Note that the functions for using the GDate are still relatively new in gnucash. That's why in most cases they are not (yet) being used, even though they are more suitable and less error-prone and better altogether :-) And one of the GLib dependencies that we're getting rid of. ;-) No worries, though: Boost::gregorian [1] has more-or-less the same functionality with I hope less work. Regards, John Ralls [1] http://www.boost.org/doc/libs/1_55_0/doc/html/date_time/gregorian.html#date_time.gregorian.date_class ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation-Fault when click on File - Open
On Dec 2, 2013, at 8:47 AM, Herbert Mühlburger m...@muehlburger.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 02.12.13 16:55, schrieb John Ralls: That's a very strange crash. I don't see it, but I'm got other weird behavior, where none of the GUI buttons, checkboxes, or GtkTreeList in the file chooser would respond, but only on the dmg downloaded from SF. Using the dmg on my local disk (the one I uploaded to SF yesterday) worked fine. I tried re-uploading that, same problem, so I regenerated the dmg and uploaded that. It now works, no problems with opening another account file. Please try downloading the new dmg. Just to be sure that there's no corruption, you can run md5 on the downloaded dmg (in Terminal); the hash should be b1a83ce89ba97439b3b24c2d60c20457. If you still have the problem, I need to know exactly what point you're getting the crash; from the stack trace you attached, it looks like it's after you select the file, either after double-clicking or clicking OK on the File Chooser dialog box. I'm afraid that it's not just a problem of the Mac OS X .dmg bundle ... I get the same error on Linux (Ubuntu) using the latest git commit. Attached you find my current gdb walkthrough as well as the stacktrace. Please remember to CC the list on all replies: Use reply-list if your mail client provides it, otherwise use reply-all. At this point I think you should open a bug report. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation-Fault when click on File - Open
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 02.12.13 18:18, schrieb John Ralls: At this point I think you should open a bug report. I created the bug https://bugzilla.gnome.org/show_bug.cgi?id=719726 regarding this issue. Do you have any idea where the problem could be? Kind regards, Herbert. -BEGIN PGP SIGNATURE- Version: GnuPG/MacGPG2 v2.0.22 (Darwin) Comment: GPGTools - https://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iF4EAREKAAYFAlKdBf4ACgkQBJGnfYOuu33NcAEAjJ0PXXf2acUwyzZpBKnkNWbm 44jm39oGjvHZ7eFHPaMA/0fW/7YF9HjmUuPDWnph5dIUxutamKpbWD63NN39Nl2S =CIw6 -END PGP SIGNATURE- ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation-Fault when click on File - Open
On Dec 2, 2013, at 2:13 PM, Herbert Mühlburger m...@muehlburger.at wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am 02.12.13 18:18, schrieb John Ralls: At this point I think you should open a bug report. I created the bug https://bugzilla.gnome.org/show_bug.cgi?id=719726 regarding this issue. Do you have any idea where the problem could be? Yes, but I’ll put the details on the bug report. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation fault: r22108
Am Samstag, 24. März 2012, 17:38:31 schrieb Alex Aycinena:
Christian,
I built a clean copy of trunk on r22118 and got a seg fault on start
up as follows:
Program received signal SIGSEGV, Segmentation fault.
0x7792b31c in gnc_split_register_load (reg=0x7f2980, slist=
0xd04a20 = {...}, default_account=0xb943f0)
at
/home/gnucash-dev/svncheckouts/gnucash-clean/src/register/ledger-core/split
-register-load.c:439 439 autoreadonly_time =
timespecToTime_t(gdate_to_timespec(*d));
I'm pretty sure it worked OK somewhere between 22108 and 22118, so not
sure what gives.
I forgot to check for one more NULL condition in r22118. Fixed now in r22122.
Sorry for that.
Regards,
Christian
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation fault: r22108
Christian,
On Sun, Mar 25, 2012 at 12:15 PM, Christian Stimming
christ...@cstimming.de wrote:
Am Samstag, 24. März 2012, 17:38:31 schrieb Alex Aycinena:
Christian,
I built a clean copy of trunk on r22118 and got a seg fault on start
up as follows:
Program received signal SIGSEGV, Segmentation fault.
0x7792b31c in gnc_split_register_load (reg=0x7f2980, slist=
0xd04a20 = {...}, default_account=0xb943f0)
at
/home/gnucash-dev/svncheckouts/gnucash-clean/src/register/ledger-core/split
-register-load.c:439 439 autoreadonly_time =
timespecToTime_t(gdate_to_timespec(*d));
I'm pretty sure it worked OK somewhere between 22108 and 22118, so not
sure what gives.
I forgot to check for one more NULL condition in r22118. Fixed now in r22122.
Sorry for that.
Regards,
Christian
Works now. Thanks.
Regards,
Alex
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Segmentation fault: r22108
Christian,
I built a clean copy of trunk on r22118 and got a seg fault on start
up as follows:
Program received signal SIGSEGV, Segmentation fault.
0x7792b31c in gnc_split_register_load (reg=0x7f2980, slist=
0xd04a20 = {...}, default_account=0xb943f0)
at
/home/gnucash-dev/svncheckouts/gnucash-clean/src/register/ledger-core/split-register-load.c:439
439 autoreadonly_time = timespecToTime_t(gdate_to_timespec(*d));
I'm pretty sure it worked OK somewhere between 22108 and 22118, so not
sure what gives.
Regards,
Alex
On Wed, Mar 21, 2012 at 3:18 PM, Christian Stimming
cs...@code.gnucash.org wrote:
Author: cstim
Date: 2012-03-21 18:18:41 -0400 (Wed, 21 Mar 2012)
New Revision: 22108
Trac: http://svn.gnucash.org/trac/changeset/22108
Modified:
gnucash/trunk/src/business/business-ledger/gncEntryLedgerLoad.c
gnucash/trunk/src/register/ledger-core/split-register-load.c
gnucash/trunk/src/register/register-core/table-model.c
gnucash/trunk/src/register/register-core/table-model.h
gnucash/trunk/src/register/register-gnome/gnucash-grid.c
Log:
Add a second red divider line to the register to denote the read-only
section for older transactions.
___
gnucash-patches mailing list
gnucash-patc...@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-patches
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation fault
On Wed, Apr 22, 2009 at 10:26:44AM +0200, Sebastian Held wrote: Am Mittwoch 22 April 2009 09:53:21 schrieb Dave Hardman: On Wed, Apr 22, 2009 at 07:42:31AM +0200, Sebastian Held wrote: Without synchronized debug information, it's hopeless to find the bug. The next step you can take is to set a breakpoint at table-gnome.c:189 and step the program until the error occurs. Ah - stop it. The one-liner for enabling debug: did you disable optimization, too? CFLAGS should not include -O2, but include -O0 -ggdb Sebastian Sebastian, The Makefile.local now contains two lines: CONFIGURE_ARGS+=--enable-debug CFLAGS+= -O0 -ggdb As before I opened a file, which opened with only the accounts window, the program crashed when I selected an account ( or would have if I had'nt had gdb running). And the backtrace follows. Dave Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x808202180 (LWP 100211)] 0x000800c0e28f in set_dimensions_pass_one (sheet=0x80be18060, cursor=0x808256700, dimensions=0x80be14860) at gnucash-style.c:177 177 gnucash-style.c: No such file or directory. in gnucash-style.c (gdb) bt #0 0x000800c0e28f in set_dimensions_pass_one (sheet=0x80be18060, cursor=0x808256700, dimensions=0x80be14860) at gnucash-style.c:177 #1 0x000800c0ebb2 in styles_recompute_layout_dimensions (sheet=0x80be18060, default_width=680) at gnucash-style.c:493 #2 0x000800c0ec8e in gnucash_sheet_styles_set_dimensions (sheet=0x80be18060, default_width=680) at gnucash-style.c:506 #3 0x000800c0f44d in gnucash_sheet_compile_styles (sheet=0x80be18060) at gnucash-style.c:668 #4 0x000800c108ce in gnc_table_init_gui (widget=0x80bd79e20, data=0x8085a0910) at table-gnome.c:189 Please try to apply the attached patch from Jonathan Kamens. Sebastian Sebastian, That worked, thanks. Dave ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation fault
On Wed, Apr 22, 2009 at 07:42:31AM +0200, Sebastian Held wrote: Without synchronized debug information, it's hopeless to find the bug. The next step you can take is to set a breakpoint at table-gnome.c:189 and step the program until the error occurs. Ah - stop it. The one-liner for enabling debug: did you disable optimization, too? CFLAGS should not include -O2, but include -O0 -ggdb Sebastian Sebastian, The Makefile.local now contains two lines: CONFIGURE_ARGS+=--enable-debug CFLAGS+= -O0 -ggdb As before I opened a file, which opened with only the accounts window, the program crashed when I selected an account ( or would have if I had'nt had gdb running). And the backtrace follows. Dave Script started on Wed Apr 22 17:40:09 2009 gnucash-env gdb gnucash-bin GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd...(no debugging symbols found)... (gdb) run --nofile Starting program: /usr/local/bin/gnucash-bin --nofile [New LWP 100211] [New Thread 0x808202180 (LWP 100211)] gnc.bin-Message: main: binreloc relocation support was disabled at configure time. [New Thread 0x808202f00 (LWP 100133)] Found Finance::Quote version 1.15 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x808202180 (LWP 100211)] 0x000800c0e28f in set_dimensions_pass_one (sheet=0x80be18060, cursor=0x808256700, dimensions=0x80be14860) at gnucash-style.c:177 177 gnucash-style.c: No such file or directory. in gnucash-style.c (gdb) bt #0 0x000800c0e28f in set_dimensions_pass_one (sheet=0x80be18060, cursor=0x808256700, dimensions=0x80be14860) at gnucash-style.c:177 #1 0x000800c0ebb2 in styles_recompute_layout_dimensions (sheet=0x80be18060, default_width=680) at gnucash-style.c:493 #2 0x000800c0ec8e in gnucash_sheet_styles_set_dimensions (sheet=0x80be18060, default_width=680) at gnucash-style.c:506 #3 0x000800c0f44d in gnucash_sheet_compile_styles (sheet=0x80be18060) at gnucash-style.c:668 #4 0x000800c108ce in gnc_table_init_gui (widget=0x80bd79e20, data=0x8085a0910) at table-gnome.c:189 #5 0x0008009a1dda in gsr_create_table (gsr=0x808aaf1e0) at gnc-split-reg.c:387 #6 0x0008009a1cce in gnc_split_reg_init2 (gsr=0x808aaf1e0) at gnc-split-reg.c:353 #7 0x0008009a1be2 in gnc_split_reg_new (ld=0x80bda4240, parent=0x8085e0030, numberOfLines=10, read_only=0) at gnc-split-reg.c:325 #8 0x000800999672 in gnc_plugin_page_register_create_widget (plugin_page=0x80bda32f0) at gnc-plugin-page-register.c:727 #9 0x0008011ecdd2 in gnc_plugin_page_create_widget (plugin_page=0x80bda32f0) at gnc-plugin-page.c:151 #10 0x0008011e31aa in gnc_main_window_open_page (window=0x8085e0030, page=0x80bda32f0) at gnc-main-window.c:2211 #11 0x0008009914a5 in gppat_open_account_common (page=0x8095c2000, account=0x80852b930, include_subs=0) at gnc-plugin-page-account-tree.c:672 #12 0x00080099156b in gnc_plugin_page_account_tree_double_click_cb (treeview=0x8085b4000, path=0x8095cda00, col=0x808aa8f00, page=0x8095c2000) at gnc-plugin-page-account-tree.c:685 #13 0x0008072e36ff in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #14 0x0008072f71a7 in g_signal_parse_name () from /usr/local/lib/libgobject-2.0.so.0 #15 0x0008072f8bf6 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #16 0x0008072f8fb3 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #17 0x00080458a85b in gtk_tree_view_set_fixed_height_mode () from /usr/local/lib/libgtk-x11-2.0.so.0 #18 0x00080449f44f in gtk_marshal_BOOLEAN__VOID () from /usr/local/lib/libgtk-x11-2.0.so.0 #19 0x0008072e36ff in g_closure_invoke () from /usr/local/lib/libgobject-2.0.so.0 #20 0x0008072f7344 in g_signal_parse_name () from /usr/local/lib/libgobject-2.0.so.0 #21 0x0008072f8907 in g_signal_emit_valist () from /usr/local/lib/libgobject-2.0.so.0 #22 0x0008072f8fb3 in g_signal_emit () from /usr/local/lib/libgobject-2.0.so.0 #23 0x00080459b5de in gtk_widget_class_list_style_properties () ---Type return to continue, or q return to quit--- from /usr/local/lib/libgtk-x11-2.0.so.0 #24 0x0008044984b2 in gtk_propagate_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #25 0x000804499545 in gtk_main_do_event () from /usr/local/lib/libgtk-x11-2.0.so.0 #26 0x0008048843cc in gdk_add_client_message_filter () from /usr/local/lib/libgdk-x11-2.0.so.0 #27 0x000807551e42 in g_main_context_dispatch () from /usr/local/lib/libglib-2.0.so.0 #28 0x000807555086 in g_main_context_check
Re: Segmentation fault
Am Mittwoch 22 April 2009 09:53:21 schrieb Dave Hardman:
On Wed, Apr 22, 2009 at 07:42:31AM +0200, Sebastian Held wrote:
Without synchronized debug information, it's hopeless to find the bug.
The next step you can take is to set a breakpoint at table-gnome.c:189
and step the program until the error occurs.
Ah - stop it. The one-liner for enabling debug: did you disable
optimization, too?
CFLAGS should not include -O2, but include -O0 -ggdb
Sebastian
Sebastian,
The Makefile.local now contains two lines:
CONFIGURE_ARGS+=--enable-debug
CFLAGS+= -O0 -ggdb
As before I opened a file, which opened with only the
accounts window, the program crashed when I selected an account (
or would have if I had'nt had gdb running).
And the backtrace follows.
Dave
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x808202180 (LWP 100211)]
0x000800c0e28f in set_dimensions_pass_one (sheet=0x80be18060,
cursor=0x808256700, dimensions=0x80be14860) at gnucash-style.c:177
177 gnucash-style.c: No such file or directory.
in gnucash-style.c
(gdb) bt
#0 0x000800c0e28f in set_dimensions_pass_one (sheet=0x80be18060,
cursor=0x808256700, dimensions=0x80be14860) at gnucash-style.c:177
#1 0x000800c0ebb2 in styles_recompute_layout_dimensions
(sheet=0x80be18060, default_width=680) at gnucash-style.c:493
#2 0x000800c0ec8e in gnucash_sheet_styles_set_dimensions
(sheet=0x80be18060, default_width=680) at gnucash-style.c:506
#3 0x000800c0f44d in gnucash_sheet_compile_styles (sheet=0x80be18060)
at gnucash-style.c:668
#4 0x000800c108ce in gnc_table_init_gui (widget=0x80bd79e20,
data=0x8085a0910) at table-gnome.c:189
Please try to apply the attached patch from Jonathan Kamens.
Sebastian
Index: /home/sebastian/src/gnucash-2.2/src/register/register-gnome/gnucash-style.c
===
--- /home/sebastian/src/gnucash-2.2/src/register/register-gnome/gnucash-style.c (.../trunk/src/register/register-gnome/gnucash-style.c) (Revision 13692)
+++ /home/sebastian/src/gnucash-2.2/src/register/register-gnome/gnucash-style.c (.../branches/2.2/src/register/register-gnome/gnucash-style.c) (Revision 18054)
@@ -48,7 +48,16 @@
return key;
}
+static gpointer
+style_create_key (SheetBlockStyle *style)
+{
+static gint key;
+key = style-cursor-num_rows;
+
+return g_memdup(key, sizeof(key));
+}
+
static void
cell_dimensions_construct (gpointer _cd, gpointer user_data)
{
@@ -103,7 +112,7 @@
if (!dimensions) {
dimensions = style_dimensions_new (style);
g_hash_table_insert (sheet-dimensions_hash_table,
- style_get_key (style), dimensions);
+ style_create_key (style), dimensions);
}
dimensions-refcount++;
___
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation fault
Am Dienstag 14 April 2009 09:29:25 schrieb Dave Hardman: I updated the ports (on freebsd 7.1 amd64) and gnucash-2.2.7 was recompiled since there was a later version of one or more of its dependencies. Over 400 ports were recompiled. Gnucash now loads the file, if file previously had account windows open the gnucash crashes, if the only window open is the list of accounts then gnucash does not crash until I attempt to open an account. I tried more than one file, including a backup, with consistent results. Presumably, the fault was caused by one or more of the new dependencies. The information below is from a session which crashed when I attempted open an account. : gnucash --debug --extra :~ gnc.bin-Message: main: binreloc relocation support was disabled at configure time. Found Finance::Quote version 1.15 [1]93890 segmentation fault gnucash --debug --extra Extracts from gnucash.trace * 15:44:13 INFO gnc.engine [gnc_hook_lookup] no hook lists * 15:44:13 INFO qof.engine [init_from_file] guid_init got 512 bytes from /dev/urandom * 15:44:13 INFO qof.engine [init_from_file] guid_init got 1903 bytes from /etc/passwd * 15:44:13 INFO qof.engine [guid_init] got 18951 bytes * 15:44:27 MESSG gnc.bin loading system configuration * 15:44:27 MESSG gnc.bin loading user configuration * 15:44:27 MESSG gnc.bin loading auto configuration * 15:44:27 MESSG gnc.bin loading saved reports * 15:44:27 MESSG gnc.bin loading stylesheets * 15:44:27 MESSG gnc.scm Found Finance::Quote version 1.15 * 15:44:27 INFO gnc.account [xaccAccountRecomputeBalance] acct= starting baln=0/1 * 15:44:27 INFO gnc.commodity [gnc_commodity_table_insert] insert 0x80810b908 AFA into nsp=0x8089a11e0 CURRENCY The missing entries are overwhelmingly INFO with a few MESSG * 15:44:33 INFO gnc.account [xaccAccountGetBalanceInCurrency] baln=647830/100 * 15:44:33 INFO gnc.account [xaccAccountGetBalanceInCurrency] baln=647830/100 * 15:44:33 INFO gnc.account [xaccAccountGetBalanceInCurrency] baln=647830/100 * 15:44:33 INFO gnc.account [xaccAccountGetBalanceInCurrency] baln=647830/100 * 15:44:33 INFO qof.object [qof_object_foreach] type=Split * 15:44:33 INFO qof.query [qof_query_run_internal] matching objects=0x80bd22000 count=60 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=5 hi=0x8094a8aa0 han=0x80118b020 data=0x0 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=3 hi=0x8089bb820 han=0x800946530 data=0x0 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=2 hi=0x8087db280 han=0x801416900 data=0x0 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=1 hi=0x8084bbb40 han=0x80117ba60 data=0x0 * 15:44:33 INFO gnc.engine [xaccTransSetDateInternal] addr=0x8094a3530 set date to 1239631200.0 Tue Apr 14 00:00:00 2009 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=5 hi=0x8094a8aa0 han=0x80118b020 data=0x7fffcf50 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=3 hi=0x8089bb820 han=0x800946530 data=0x7fffcf50 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=2 hi=0x8087db280 han=0x801416900 data=0x7fffcf50 * 15:44:33 INFO qof.engine [qof_event_generate_internal] id=1 hi=0x8084bbb40 han=0x80117ba60 data=0x7fffcf50 I Dave ___ gnucash-user mailing list gnucash-u...@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-user - Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. Am Saturday 18 April 2009 03:47:34 schrieben Sie: On Tue, Apr 14, 2009 at 10:24:06AM +0200, Sebastian Held wrote: Am Dienstag 14 April 2009 09:29:25 schrieb Dave Hardman: Gnucash now loads the file, if file previously had account windows open the gnucash crashes, if the only window open is the list of accounts then gnucash does not crash until I attempt to open an account. I tried more than one file, including a backup, with consistent results. Presumably, the fault was caused by one or more of the new dependencies. Please create a backtrace by following http://wiki.gnucash.org/wiki/Stack_Trace This will show the library where the crash occurs. Sebastian Sebastion, Attached Dave Dear Dave, Please respond to the list, too. I'm sorry for the delay, but currently I've no internet access at home. Thanks for the backtrace. I will look into it. The backtrace will be even more meaningful, if you substitute bt full for the bt command (should be changed at the wiki...). Sebastian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation fault
Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x808102180 (LWP 100227)] gnucash_sheet_styles_set_dimensions (sheet=0x80bd340c0, default_width=680) at gnucash-style.c:177 177gnucash-style.c: No such file or directory. in gnucash-style.c Function gnucash_sheet_styles_set_dimensions is located at lines 501, not 177 ... (gdb) bt #0 gnucash_sheet_styles_set_dimensions (sheet=0x80bd340c0, default_width=680) at gnucash-style.c:177 #1 0x000800bc6aab in gnc_table_init_gui (widget=Variable widget is not available. ) at table-gnome.c:189 gnc_table_init_gui() is at table-gnome.c:189, but invokes gnucash_sheet_compile_styles() from there Is your gnucash-2.2.7 patched? Sebastian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation fault
Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All. Am Wednesday 22 April 2009 06:11:34 schrieben Sie: On Tue, Apr 21, 2009 at 01:56:44PM +0200, Sebastian Held wrote: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 0x808102180 (LWP 100227)] gnucash_sheet_styles_set_dimensions (sheet=0x80bd340c0, default_width=680) at gnucash-style.c:177 177 gnucash-style.c: No such file or directory. in gnucash-style.c Function gnucash_sheet_styles_set_dimensions is located at lines 501, not 177 ... (gdb) bt #0 gnucash_sheet_styles_set_dimensions (sheet=0x80bd340c0, default_width=680) at gnucash-style.c:177 #1 0x000800bc6aab in gnc_table_init_gui (widget=Variable widget is not available. ) at table-gnome.c:189 gnc_table_init_gui() is at table-gnome.c:189, but invokes gnucash_sheet_compile_styles() from there Is your gnucash-2.2.7 patched? Sebastian There does not appear to be any patches applied. I extracted the source and gnucash_sheet_styles_set_dimensions is at line 501 in gnucash_style.c The distribution info is: MD5 (gnucash-2.2.7.tar.bz2) = 0f3f324c274b136070b769aa10591ccf SHA256 (gnucash-2.2.7.tar.bz2) = aaa558e76427b7a990287089a6e0e5ecb0f4404e0343a7200e1588f60ffab1e8 SIZE (gnucash-2.2.7.tar.bz2) = 7362491 The ports makefile is attached. None of the options were used. I added Makefile.local with one line enabling debug. Dave Without synchronized debug information, it's hopeless to find the bug. The next step you can take is to set a breakpoint at table-gnome.c:189 and step the program until the error occurs. Ah - stop it. The one-liner for enabling debug: did you disable optimization, too? CFLAGS should not include -O2, but include -O0 -ggdb Sebastian ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: segmentation fault AND Re: crash creating new file
David Hampton wrote: On Fri, 2006-02-24 at 22:43 -0700, Mark Johnson wrote: Josh Sled wrote: On Thu, 2006-02-23 at 20:28 -0700, Mark Johnson wrote: Funny enough, Mark's message was delivered (to me, anyways) about 30 seconds after we started talking about it on IRC. Chris reports -- and I can verify -- it's fixed in r13378. gnucash --nofile just gave me a segmentation fault on 13378. Can you post the top 10 frames of the stack trace? David Here is the complete stack trace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1229826368 (LWP 15329)] 0xb6bc06db in strlen () from /lib/tls/libc.so.6 (gdb) bt #0 0xb6bc06db in strlen () from /lib/tls/libc.so.6 #1 0xb6cddb56 in g_option_context_add_main_entries () from /usr/lib/libglib-2.0.so.0 #2 0xb6cde9cf in g_option_context_parse () from /usr/lib/libglib-2.0.so.0 #3 0x0804a2c3 in gnucash_command_line (argc=0xbface970, argv=0xbface9f4) at gnucash-bin.c:311 #4 0x0804a79c in main (argc=2, argv=0xbface9f4) at gnucash-bin.c:492 Mark ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: segmentation fault AND Re: crash creating new file
On Thu, 2006-02-23 at 20:28 -0700, Mark Johnson wrote: With gnucash svn 13366, I am getting a segmentation fault for the command line: $ gnucash --nofile This is repeatable. I was trying this because it was crashing when I tried File-New-new file with a file open. That crash was also repeatable. Any one else seeing this? Is it fixed in a newer svn? On Fri, 2006-02-24 at 05:24 -0600, Michael D. Wise wrote: When I try to create a new file I get the following error: *** glibc detected *** gnucash: double free or corruption (fasttop): 0x0a0b82a0 *** === Backtrace: = /lib/libc.so.6[0x72fde8] /lib/libc.so.6(__libc_free+0x79)[0x7332ed] /usr/lib/libglib-2.0.so.0(g_free+0x31)[0x61b581] /home/michael.wise/usr/local/gnucash//lib/libqof.so.1(qof_session_destroy+0xab)[0xb6a16b] Funny enough, Mark's message was delivered (to me, anyways) about 30 seconds after we started talking about it on IRC. Chris reports -- and I can verify -- it's fixed in r13378. -- ...jsled http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: segmentation fault AND Re: crash creating new file
Josh Sled wrote: On Thu, 2006-02-23 at 20:28 -0700, Mark Johnson wrote: With gnucash svn 13366, I am getting a segmentation fault for the command line: $ gnucash --nofile This is repeatable. I was trying this because it was crashing when I tried File-New-new file with a file open. That crash was also repeatable. Any one else seeing this? Is it fixed in a newer svn? On Fri, 2006-02-24 at 05:24 -0600, Michael D. Wise wrote: When I try to create a new file I get the following error: *** glibc detected *** gnucash: double free or corruption (fasttop): 0x0a0b82a0 *** === Backtrace: = /lib/libc.so.6[0x72fde8] /lib/libc.so.6(__libc_free+0x79)[0x7332ed] /usr/lib/libglib-2.0.so.0(g_free+0x31)[0x61b581] /home/michael.wise/usr/local/gnucash//lib/libqof.so.1(qof_session_destroy+0xab)[0xb6a16b] Funny enough, Mark's message was delivered (to me, anyways) about 30 seconds after we started talking about it on IRC. Chris reports -- and I can verify -- it's fixed in r13378. gnucash --nofile just gave me a segmentation fault on 13378. Mark ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: segmentation fault AND Re: crash creating new file
On Fri, 2006-02-24 at 22:43 -0700, Mark Johnson wrote: Josh Sled wrote: On Thu, 2006-02-23 at 20:28 -0700, Mark Johnson wrote: Funny enough, Mark's message was delivered (to me, anyways) about 30 seconds after we started talking about it on IRC. Chris reports -- and I can verify -- it's fixed in r13378. gnucash --nofile just gave me a segmentation fault on 13378. Can you post the top 10 frames of the stack trace? David ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
segmentation fault
With gnucash svn 13366, I am getting a segmentation fault for the command line: $ gnucash --nofile This is repeatable. I was trying this because it was crashing when I tried File-New-new file with a file open. That crash was also repeatable. Any one else seeing this? Is it fixed in a newer svn? Here is some output from gdb for the gnucash --nofile case: Starting program: /opt/gnucash-svn13366/bin/gnucash-bin --nofile [Thread debugging using libthread_db enabled] [New Thread -1230563648 (LWP 19744)] (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\x9c' (-100) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\u0002' (2) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\xd8' (-40) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\u0002' (2) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\xb0' (-80) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\xe0' (-32) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\xe0' (-32) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\xcf' (-49) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\x92' (-110) (process:19744): GLib-WARNING **: goption.c:1672: ignoring invalid short option '\u0006' (6) Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1230563648 (LWP 19744)] 0xb6b0d6db in strlen () from /lib/tls/libc.so.6 (gdb) bt #0 0xb6b0d6db in strlen () from /lib/tls/libc.so.6 #1 0xb6c2ab56 in g_option_context_add_main_entries () from /usr/lib/libglib-2.0.so.0 #2 0xb6c2b9cf in g_option_context_parse () from /usr/lib/libglib-2.0.so.0 #3 0x0804a2c3 in gnucash_command_line (argc=0xbfa17480, argv=0xbfa17504) at gnucash-bin.c:311 #4 0x0804a79c in main (argc=2, argv=0xbfa17504) at gnucash-bin.c:492 Mark ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
segmentation fault
r12021 and at least a couple earlier give me a segmentation fault on launch. Since no one else has been complaining, I figured it must be me, but I'm looking for suggestions. the guile crash log starts out: Host Name: G5D Date/Time: 2005-11-23 18:40:19.481 -0500 OS Version: 10.4.3 (Build 8F46) Report Version: 3 Command: guile-1.6 Path:/sw/bin/guile-1.6 Parent: tcsh [25212] Version: ??? (???) PID:16667 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbf7fffe0 Thread 0 Crashed: 0 libgncmod-engine.0.dylib 0x02b8e320 gnc_should_log + 28 (gnc- engine-util.c:132) 1 libgncmod-engine.0.dylib 0x02b8e330 gnc_should_log + 44 (gnc- engine-util.c:135) followed by about 500 lines just like the one just above the line, plus info on thread state and loaded images trying one of the gdb recipes, I get: [G5D:/opt/gnc-g2-unstable/bin] dbr% gnucash-env gdb /sw/bin/guile-1.6 (gdb) run -e main -s /opt/gnc-g2-unstable/bin/gnucash Starting program: /sw/bin/guile-1.6 -e main -s /opt/gnc-g2-unstable/ bin/gnucash ERROR: In procedure skip_scsh_block_comment: ERROR: unterminated `#! ... !#' comment Program exited with code 02. The string skip_scsh_block_comment does appear in my libguile. 12.3.0.dylib file (and not surprisingly in libguile.a). Is my libguile corrupt? How far back in dependency building to I go to try to fix things? Thanks. -- David Reiser [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: segmentation fault
It was me. I don't know quite what did it. But I wiped out both the source and install directories, checked out r12027, and it builds and runs. Time to go figure how I twisted it... Dave On Nov 23, 2005, at 7:29 PM, David Reiser wrote: r12021 and at least a couple earlier give me a segmentation fault on launch. Since no one else has been complaining, I figured it must be me, but I'm looking for suggestions. the guile crash log starts out: Host Name: G5D Date/Time: 2005-11-23 18:40:19.481 -0500 OS Version: 10.4.3 (Build 8F46) Report Version: 3 Command: guile-1.6 Path:/sw/bin/guile-1.6 Parent: tcsh [25212] Version: ??? (???) PID:16667 Thread: 0 Exception: EXC_BAD_ACCESS (0x0001) Codes: KERN_INVALID_ADDRESS (0x0001) at 0xbf7fffe0 Thread 0 Crashed: 0 libgncmod-engine.0.dylib 0x02b8e320 gnc_should_log + 28 (gnc- engine-util.c:132) 1 libgncmod-engine.0.dylib 0x02b8e330 gnc_should_log + 44 (gnc- engine-util.c:135) followed by about 500 lines just like the one just above the line, plus info on thread state and loaded images trying one of the gdb recipes, I get: [G5D:/opt/gnc-g2-unstable/bin] dbr% gnucash-env gdb /sw/bin/guile-1.6 (gdb) run -e main -s /opt/gnc-g2-unstable/bin/gnucash Starting program: /sw/bin/guile-1.6 -e main -s /opt/gnc-g2-unstable/ bin/gnucash ERROR: In procedure skip_scsh_block_comment: ERROR: unterminated `#! ... !#' comment Program exited with code 02. The string skip_scsh_block_comment does appear in my libguile. 12.3.0.dylib file (and not surprisingly in libguile.a). Is my libguile corrupt? How far back in dependency building to I go to try to fix things? Thanks. -- David Reiser [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel -- David Reiser [EMAIL PROTECTED] ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation Fault in xaccFreeSplit
I see nothing wrong with this code. It should be perfectly legal to set an invalid pointer like this. Unless you are specifically doing bounds-checking on pointer-sets I can't see how setting a pointer would cause a SEGV. You're not ACCESSING the memory then, you're only setting the pointer. It should be no more special than setting the pointer to NULL or to some other arbitrary value. And yes, this code has been there a long time, in order to detect a double-free. You could probably change the code to have: static char deleted_string = ***this object deleted***; And then use 'deleted_string' instead of (char *) 1.. -derek Matthew Vanecek [EMAIL PROTECTED] writes: hey, I don't know if this is just my machine, or what, but I've started getting a segmentation fault in Gnucash, gnucash-gnome2-dev branch. I'm running Fedora Core 3, updated via up2date somewhat regularly. The crash occurs when loading an existing file, or when exiting after creating a new file and adding a split. E.g., start gnucash, create empty file, add account with opening balance (Opening Balance account auto-creates). Quit, and select yesyouwanttosave. Application crashes. It also is crashing on opening an existing known good file. Now, I don't know if this is a Fedora problem or a GC problem (or maybe even a bad bit in memory), but I do know the bit of code. The code that is causing the problem is in Transaction.c in the xaccFreeSplit() function: split-memo= (char *) 1; I think this has been that way a long long time, but I thought I'd poll for opinions anyhow. I put together a small test program (source attached) that does the samae type of assignment, and sure enough it crashes. Anyhow, I'll eventually get around to rebooting, but in the meantime, is this supposed to (continue to be) a valid assignment? Much appears to be changing with newer versions of glibc, etc., WRT standards enforcement, etc. Thanks, -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation Fault in xaccFreeSplit
Derek Atkins [EMAIL PROTECTED] writes: I see nothing wrong with this code. It should be perfectly legal to set an invalid pointer like this. Unless you are specifically doing bounds-checking on pointer-sets I can't see how setting a pointer would cause a SEGV. You're not ACCESSING the memory then, you're only setting the pointer. It should be no more special than setting the pointer to NULL or to some other arbitrary value. There are processors which have special address registers, and which do fault as soon as you store certain kinds of illegal addresses in them rather than waiting for an access. How important these processors are, and whether you want to worry about them, is a different question. Thomas ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation Fault in xaccFreeSplit
On Fri, 2005-01-21 at 11:37 -0800, Thomas Bushnell BSG wrote: Derek Atkins [EMAIL PROTECTED] writes: I see nothing wrong with this code. It should be perfectly legal to set an invalid pointer like this. Unless you are specifically doing bounds-checking on pointer-sets I can't see how setting a pointer would cause a SEGV. You're not ACCESSING the memory then, you're only setting the pointer. It should be no more special than setting the pointer to NULL or to some other arbitrary value. There are processors which have special address registers, and which do fault as soon as you store certain kinds of illegal addresses in them rather than waiting for an access. How important these processors are, and whether you want to worry about them, is a different question. Thomas It's faulting on my P3 nowadays for some reason. I wasn't sure if it was a glibc thing or what. Quite annoying. I was wondering if someone could reproduce this on his/her machine, to see if it's my machine/setup or something else. I'm kinda skeptical about using the contents of a freed Split to see if the Split has been freed, though. What if something else has overwritten the freed memory? Why is that particular pointer guaranteed to still be == (char *)1 if the split is run through the function again? Thanks, -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation Fault in xaccFreeSplit
On Fri, 2005-01-21 at 21:09 -0600, Matthew Vanecek wrote: On Fri, 2005-01-21 at 11:37 -0800, Thomas Bushnell BSG wrote: Derek Atkins [EMAIL PROTECTED] writes: [snip] It's faulting on my P3 nowadays for some reason. I wasn't sure if it was a glibc thing or what. Quite annoying. I was wondering if someone could reproduce this on his/her machine, to see if it's my machine/setup or something else. I'm kinda skeptical about using the contents of a freed Split to see if the Split has been freed, though. What if something else has overwritten the freed memory? Why is that particular pointer guaranteed to still be == (char *)1 if the split is run through the function again? Hmm, it was my debugging attempt causing the problem--can't *printf(% s) on a char* field that's been set to (char *)1. So, while accessing the potentially freed memory is dubious, the SEGV actually happens a few lines down, and a file or two over, in the qof_entity_release() function. My Bad(tm). For some reason, split-entity.e_type is NULL by this point, and I don't think the CACHE_REMOVE(str) macro appreciates that. This crash is happening on exit, when you would expect the memory to be freed. PINFO(Fixing to release split entity for type: %s, split-entity.e_type); qof_entity_release (split-entity); causes this result: Info: xaccFreeSplit(): Fixing to release split entity for type: (null) CRASH!! (because qof_entity_release doesn't have an logging statements...). and the gdb bt revealed that some g_hash_something function burped on the NULL value. Don't have time right now to recreate the bt (bedtime) but I could probably get to it again on Sunday. Is it permissible for split-entity.e_type to be NULL at this point in the game (exiting, etc.)? It's probably something I've written causing this, but when I save the Split, it's e_type is Split, and then when I exit, the e_type is NULL... Thanks, -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... signature.asc Description: This is a digitally signed message part ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: Segmentation Fault in xaccFreeSplit
Quoting Matthew Vanecek [EMAIL PROTECTED]: I'm kinda skeptical about using the contents of a freed Split to see if the Split has been freed, though. What if something else has overwritten the freed memory? Why is that particular pointer guaranteed to still be == (char *)1 if the split is run through the function again? It's not. The data could be completely bogus. It's just a debugging tool. -derek -- Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory Member, MIT Student Information Processing Board (SIPB) URL: http://web.mit.edu/warlord/PP-ASEL-IA N1NWH [EMAIL PROTECTED]PGP key available ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Segmentation Fault in xaccFreeSplit
hey, I don't know if this is just my machine, or what, but I've started getting a segmentation fault in Gnucash, gnucash-gnome2-dev branch. I'm running Fedora Core 3, updated via up2date somewhat regularly. The crash occurs when loading an existing file, or when exiting after creating a new file and adding a split. E.g., start gnucash, create empty file, add account with opening balance (Opening Balance account auto-creates). Quit, and select yesyouwanttosave. Application crashes. It also is crashing on opening an existing known good file. Now, I don't know if this is a Fedora problem or a GC problem (or maybe even a bad bit in memory), but I do know the bit of code. The code that is causing the problem is in Transaction.c in the xaccFreeSplit() function: split-memo= (char *) 1; I think this has been that way a long long time, but I thought I'd poll for opinions anyhow. I put together a small test program (source attached) that does the samae type of assignment, and sure enough it crashes. Anyhow, I'll eventually get around to rebooting, but in the meantime, is this supposed to (continue to be) a valid assignment? Much appears to be changing with newer versions of glibc, etc., WRT standards enforcement, etc. Thanks, -- Matthew Vanecek perl -e 'print $i=pack(c5,(41*2),sqrt(7056),(unpack(c,H)-2),oct(115),10);' For 93 million miles, there is nothing between the sun and my shadow except me. I'm always getting in the way of something... ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
