GNOME Bugzilla – Bug 125600
Scheduled Transaction Editor Crash with Weekly Transaction
Last modified: 2018-06-29 20:38:23 UTC
The Scheduled Transaction Editor crashes consistently when entering a weekly transaction. Create New transaction, set frequency to weekly, then every 4 weeks Now choosing Monday will crash the application (other days seem to be ok!) I'm using version 1.8.7 (guile 1.6.4)
Thanks for the bug report. Without a stack trace from the crash it's very hard to determine what caused the crash. Please see http://bugzilla.gnome.org/getting-traces.cgi for more information about getting a useful stack trace. Also, what optimization flags are you compiling with?
Hi - things have moved on a little, but i'm still getting the same bug. I'm now running 1.8.8 (from freshrpms.net) on Fedora Core 1, but trying to create the 4 weekly transaction on a Monday still hangs the application. i've attached the stack trace from running gdb on the guile process of the hung app Attaching to program: /usr/bin/guile, process 20653 <snip> (gdb) thread apply all bt
+ Trace 42558
Thread 1 (Thread -1084641152 (LWP 20653))
Is this any use to you? Cheers, Steve
Unfortunately, no. I'll reopen and let a maintainer take a look at this.
I can't reproduce. That stack trace seems to be for the wrong thread, or something. Does this happen for a specific data file, or can you reproduce on a new/empty data file?
Does seem to be related to the data file. I've just tried in a brand new empty file it goes in ok - i've been trying to add this scheduled transaction for several months (and versions!) to my accounts file with no joy. In this time I have succesfully added (and removed) other scheduled transactions without problem. Any idea what the problem could be with the datafile or what I can do to try to find out?
Yes and no. I have been able to reproduce since yesterday. It seems [somewhat] transient. I can't tell if it's necessarily data-related [any more so than normal] or runtime related [corrupted memory/state, &c.] I'll dig into it in a couple of weeks, but I am able to reproduce locally.
Grr. I both am- and am-not able to reproduce. This has got to be corrupted memory, based both on the intermittent aspect, as well as the destroyed backtraces I saw when I was able to reproduce. I'm going to both automatically and manually aduit memory usage in the affected code, which is going to take some time.
Steve, it also occurs to me that this might be more reproducible on my end with your data file ... if you can consistenly reproduce it with that datafile, then I should be able to do the same, which would help a lot in tracking the issue down. Would you be willing to send me your data file in private correspondance?
no problem - i'll remove anything that's personal let me know where you want me to send it to...
Please send to the email address in the "assigned to" field of this bug. As well, please make sure that you can still reproduce the problem after modifying the data file -- if you can't, the data file's not useful.
*** Bug 107006 has been marked as a duplicate of this bug. ***
*** Bug 106212 has been marked as a duplicate of this bug. ***
*** Bug 115905 has been marked as a duplicate of this bug. ***
*** Bug 108886 has been marked as a duplicate of this bug. ***
Found and fixed a stupid memory-corruption issue ... it'll be in CVS in a while.
*** Bug 134433 has been marked as a duplicate of this bug. ***
*** Bug 136397 has been marked as a duplicate of this bug. ***
Fixed in 2004.03.08 commit on 1.8-branch and HEAD. jsled--. valgrind++.
*** Bug 144399 has been marked as a duplicate of this bug. ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=125600. Please update any external references or bookmarks.