GNOME Bugzilla – Bug 651981
Console error message on restarting GnuCash after renaming accounts/modifying account hierarchy while a report is open (but no crash)
Last modified: 2018-06-29 22:58:44 UTC
As crazy as it may sound, opening my gnucash file gives me an error, While opening a _verbatim_ copy works: $ cp budget.gnucash budget.gnucash.other $ gnucash budget.gnucash ERROR: In procedure read: ERROR: Unknown # object: #\< $ gnucash budget.gnucash.other - ALL FINE - There's no dot-file in the directory containing those files. Version of gnucash: GnuCash 2.2.9 Built 2010-03-23 from r17949M
I tried on another machine where I was able to open the datafile but with an error message from Guile. After that (after closing the file) I was unable to reopen it again, having the problem described here. The error message is described in bug #651982 https://bugzilla.gnome.org/show_bug.cgi?id=651982
Removing ~/.gnucash/books/budget.gnucash fixed this issue for me, on both machines. Can't tell if that book was there on the second machine at time of opening the file for the first time. But I do see the file getting back afterwards (when everything works). It may have to do with the fact that I recently changed some account names and hierarchy (parents).
*** Bug 651982 has been marked as a duplicate of this bug. ***
Sorry for the long inactivity on this report. By any chance did somebody know what the content of this obnoxious file ~/.gnucash/books/budget.gnucash was? Is that problem still reproducible with any recent 2.4.x version or 2.5.x version?
The one I have now looks like this: [Top] BookGuid=1c0063e68dce6ebc969e6570e5ecb3b8 WindowCount=1 [Window 1] PageCount=12 FirstPage=1 PageOrder=7;1;2;3;4;5;6;8;9;10;11;12; WindowPosition=0;25; WindowGeometry=1280;726; WindowMaximized=true ToolbarVisible=true SummarybarVisible=true StatusbarVisible=true ... It does contain some account names later on. I tried perturbating some of those names but couldn't reproduce the problem with gnucash 2.4.10
I wouldn't expect changing account names to cause this kind of bug. Internally GnuCash refers to account by an internal ID number (called a GUID). This number doesn't change when you alter an account's name. From the trace in the bug duplicate and some previous experience I could imagine this scenario: - in your open book you have a net worth bar chart open - this bar chart is calculated based on a list of accounts - you do something that causes one of these accounts to get a different guid - you save and close GnuCash in this state - next time you open your data file, GnuCash will attempt to regenerate the bar chart, but fails because it can't find the account associated to the old guid You mentioned you were modifying the account hierarchy at the time. Do you remember if you deleted/recreated some accounts while doing so ? Just renaming the account or changing an account's parent using the account edit dialog probably don't matter. Finally some general info: the file in .gnucash/books/budget.gnucash is probably no longer in use when you are running GnuCash 2.4.10. The extension for files in the books directory changed with the release of 2.4.0. If your data file is still called budget.gnucash, then the associated metafile in the books directory will be called budget.gnucash.gcm.
I have just ran a test myself on GnuCash 2.4.11. I have created a minimal book a basic set of accounts. Then - create a total of 3 asset accounts with some transactions. - open a net worth bar chart - for this chart, change the default account selection such that only two asset accounts are selected (the other type accounts don't matter for this example, but can still be selected). - now switch from the report tab to the main account hierarchy tab and delete one of the accounts that was selected for the bar chart - save and quit - start GnuCash again with this data file This will result in the following error trace: In unknown file: ?: 9 [#<procedure #f ()>] In /usr/share/gnucash/scm/report.scm: ... 676: 10 (set! html (gnc:report-render-html report #t)) 676: 11* [gnc:report-render-html # #t] 639: 12 (if (and (not #) (gnc:report-ctext report)) (gnc:report-ctext report) ...) 647: 13 (let ((template #) (doc #f)) (set! doc (if template # #f)) doc) 650: 14* (set! doc (if template (let* (# # # ...) (if # # ...) ...) ...)) 650: 15* (if template (let* (# # # ...) (if # # ...) ...) ...) 651: 16 (let* (# # # #) (if # # #) (gnc:report-set-ctext! report html) ...) 653: 17* [#<procedure #f #> #] In /usr/share/gnucash/guile-modules/gnucash/report/standard-reports/net-barchart.scm: 426: 18 [net-renderer # #f] ... 151: 19 (let* (# # # # ...) (define # #) (define # #) ...) 187: 20* [gnc:decompose-accountlist (# # #f # ...)] In /usr/share/gnucash/scm/report-utilities.scm: 85: 21 [map #<procedure #f (x)> ((2 2 0 ...) (4 4 12 ...) (10 10) ...)] In unknown file: ?: 22* [#<procedure #f (x)> (2 2 0 1 15 16 17 11 5 ...)] In /usr/share/gnucash/scm/report-utilities.scm: 85: 23* [cons 2 ... 87: 24* [gnc:filter-accountlist-type (2 0 1 15 ...) (# # #f # ...)] 75: 25 [filter #<procedure #f (a)> (# # #f # ...)] In unknown file: ?: 26* [#<procedure #f (a)> #f] In /usr/share/gnucash/scm/report-utilities.scm: 76: 27* [member ... 76: 28* [xaccAccountGetType #f] /usr/share/gnucash/scm/report-utilities.scm:76:21: In procedure xaccAccountGetType in expression (xaccAccountGetType a): /usr/share/gnucash/scm/report-utilities.scm:76:21: Wrong type argument in position 1: #f But contrary to the original report, GnuCash 2.4.11 doesn't crash on me anymore. It will successfully open the datafile and even the report. GnuCash prunes the missing account from the report automatically (but generates the trace). Better even: restarting GnuCash once more (even without saving anything), no more trace file is being produced. I have to recreate the above conditions manually again to get another error trace. I believe this bug can be considered sufficiently fixed, unless we want to catch the error and inform the user in human language instead of a trace file. In any case, this does not warrant a critical severity anymore.
Created attachment 243843 [details] Sample gnucash book to illustrate the bug
Created attachment 243844 [details] Sample gnucash book metadata file to illustrate the bug
I have attached my minimal data file and associated metadata file so you can more easily reproduce the test yourself. The combination of these two simulates the situation where a net worth bar chart was still open with an account selected that has just been deleted. To set this up: - copy the metadata file to your .gnucash/books directory - open the gnucash data file => this should give the same trace file as I added in comment 7. If you want to run the test again, you'll have to copy the metadata file to .gnucash/books again. This file is automatically overwritten each time the corresponding datafile is closed by gnucash. And for completeness: I get the same result with the most recent gnucash trunk (2.5.1+). Can you also try this experiment and report your findings ?
Ok, if it doesn't crash anymore it isn't a CRITICAL bug.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=651981. Please continue processing the bug there and please update any external references or bookmarks.