GNOME Bugzilla – Bug 739852
Hang at File|Quit after opening budget report
Last modified: 2018-06-29 23:36:02 UTC
Operating system: Windows 7 Home Premium SP1, 64-bit, with 4GB RAM To reproduce in the simplest fashion: Start gnuCash, create a new file with standard accounts and choose XML backend. Then attempt to view a "Report|Budget|Budget report". You will see a simple error stating no budget exists. Now try to exit gnuCash via File|Quit. The program will simply hang and become non-responsive. Encountered this bug while trying to use gnuCash in a production environment with multiple accounts. Every time I open a Budget Report, even if I close it, I can no longer exit gnuCash without it hanging on exit. Attached is the tracelog of the simplest environment described above along with the basic standard account structure. I can safely open the budget itself and make edits and then close and quit gnuCash without any problems. The budget and budget reports both are extremely slow to respond on my system. I then confirmed the same behavior on a different system running Windows 7 32-bit. On one system, I have Symantec Endpoint Protection (SEP) anti-virus v12.1.2100.2093 installed (Win7 x64) but not on the Win7 32-bit system. In both cases I have the account files stored on a synchronized folder (Google Drive) but the problem persists if I save the files instead to my Desktop (not synchronized).
Tracefile too large so uploaded and shared on Google Drive at https://drive.google.com/file/d/0B2z5DS4jiR8tNl91dEFWQmVITU0/view?usp=sharing
Should also specify - this is gnuCash v2.6.4-2
Thanks for the bug report. This particular bug has already been reported into our bug tracking system, but please feel free to report any further bugs you find. *** This bug has been marked as a duplicate of bug 738477 ***
Thank you. I suspected as much but was unable to find the reported bug or any of the other duplicates I see. I searched for "hang quit" and "crash quit". I see the original report is "freeze on exit". Anyway to keep some of these synonyms so that searches bring up the appropriate bug? I guess the problem is I searched for "open" bugs.
I don't know of any way to get bugzilla to search for what you mean instead of exact terms, nor to get users to use a particular set of terms. There's a "keywords" field that would allow tagging, but that requires someone to use it and then requires that users know to search on it, and what to search for, when looking for duplicates. One trick is to search in comments rather than summary, because people are more likely to use synonyms as they discuss the problem. You'll get more false positives that way but as long as the list isn't too long you can review each one to see if it is close to your problem. Another is to pick a different search algorithm than "contains all of the strings"; "any of the words" with a list of possible synonyms will improve the likelihood of a match. Bug 738477 is definitely an open bug, though bugzilla doesn't use that term. Open means that its status is in the set (Unconfirmed New Assigned NeedInfo); closed means its in (Resolved Verified).
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=739852. Please update any external references or bookmarks.