GNOME Bugzilla – Bug 702880
Register2: Crash when editing Scheduled Transaction
Last modified: 2018-06-29 23:16:57 UTC
To trigger the crash do the following: 1. When the Since Last Run Assistant runs check the Review Created Transactions box. 2. Allow the Since last Run assistant to create a transaction and click OK 3. In the Search register showing the created transaction, right click on a non-editable area of a created transaction and select Schedule... 4. Change something in the transaction description field. Press the Enter key. Then Click OK. 5 GnuCash pops up a message that the transaction has been changed. Select OK Then GnuCash crashes.
This is happening in release 2.5.2 in Windows 7 64 bit
I forgot to clarify that after step 3 GnuCash opened the linked scheduled transaction for editing in the Scheduled Transaction editor and step 4 is executed in the Scheduled Transaction editor.
This is still happening in Release 2.5.3 in Windows 7 64 bit. I have found that it is dependent on an issue that I am not sure how to describe, but I will try. When I right mouse click on a transaction while pointing to an editable field, that field usually gets a highlight with the row background turning red and the actual text in that box turning white on a blue background. Then I can click again on the text which then reverts to black on beige with the text editing pipe symbol somewhere inside the string. Then I can change that text string. If I switch to another program and return, the entire row is white on a blue background. In either case, then I can tab to the next field and edit it. If I tab into an editable box, the entire string remains white on a blue background. To keep the existing string and modify it, I must make the text black on beige with the pipe symbol by doing something like hitting a right or left arrow key. If I right mouse click on a box in a red row where the text is white on a blue background, I get a drop-down menu with options Cut,Copy, Paste, Delete, Select All, Input Methods and Insert Unicode Character. To get to the expected right click menu I need to make sure that I right click in an area that does not have white text on a blue background with a red background in the rest of the row. All of the above seems to be true for edits in most register views. While all of that is initially somewhat awkward, after some practice it gets easy to work with. That is not my concern for this particular bug report. Now I start from the scheduled transactions Search Results view and right click a transaction then select Schedule... to edit the scheduled transaction that was used to create that particular transaction. Then in the scheduled Transaction editor view, if I make a change and tab after, I eventually get the prompt to discard cancel or record changes. Clicking on any of the three choices seems to work as expected. That also is true if I hit an enter key twice after editing a field. If, while in that scheduled transaction edit session, after changing some text, I then hit an Enter key once then right mouse click on OK, I get a prompt that 'The current template transaction has been changed. Would you like to record the changes?' with the choices yes and no. If I click No, the editor abandons the changes and closes, releasing the focus back to the main window. If I click on Yes, GnuCash crashes. The crash seems to only happen when Yes is selected from that particular prompt.
I still get this crash when clicking yes in the 'The current template transaction has been changed. Would you like to record the changes?' prompt in scheduled transaction edits if all open registers are set to Register2 view. There may be different behavior if I have edited the 'Notes' field than if I have edited the 'memo' field of a split line. It seems like some actions are more likely than others to bring up that dreaded prompt.
Created attachment 249505 [details] Trace file after crash Trace file after a crash triggered by clicking Yes to the dreaded prompt
It would sure be helpful if you could get a stack trace: http://wiki.gnucash.org/wiki/Windows#Debugging_with_gdb
so the trace that I attached was not the right one?
(In reply to comment #7) > so the trace that I attached was not the right one? I wouldn't go that far. Our name for it is a bit confusing, but it's a log of all of the diagnostic messages that Gnucash prints out. A stack trace shows a list of the functions that lead up to the crash, which is a much more precise diagnostic tool. MacOSX makes one automatically; for everything else you have to crash it in a debugger and then give the "backtrace" command.
Created attachment 249986 [details] gdb fails message Following the instructions provided I installed gdb and tried it with GnuCash 2.4.13. It crashed before it got GnuCash started. The CMD screen listing is attached. I guess I cannot do it that way. Is there something else I can try?
When editing transactions in Release 2.5.4 as installed in Windows 7 64 bit the behavior of either of the keyboard enter keys has changed to only toggle the focus of the highlighted field between a red background behind blue text or blue background. It no longer triggers the accept edits prompt with the three choices, even after multiple keystrokes. However, using the Enter button on menubar triggers the prompt to discard, cancel or record similar to release 2.4.13 and earlier. When editing Scheduled transactions either of the enter keys also now only toggle the highlighted field as in regular transaction edits. Again, the Enter button on the menubar triggers the prompt to discard, cancel or record as expected. Once that prompt is acted on and closed, then the OK button simply closes the edit window. However, if the scheduled transaction has been changed but not been processed by using the menubar enter button, and then the OK button is pressed, the 'Scheduled transaction is changed would you like to record the changes?' prompt appears with only two choices, yes or no. Clicking No closes the edit session abandoning the changes. Clicking Yes sometimes crashes Gnucash. There is no option to cancel the OK button click from the sx edit session and try something else, such as using the menubar enter button to process the edit without risking a crash. For completeness, tabbing through either type of edit session eventually triggers the prompt to discard, cancel or record. If the scheduled transaction has been edited and the cancel button is clicked, then clicking yes abandons the edit and closes the edit session. Clicking No leaves the edit session open. That behavior is acceptable to me. If I recall, there used to be a preference setting whether using 'Enter' would accept a transaction edit. Now there is a setting to choose whether using 'Enter' moves to a blank transaction or moves down one row without explaining what happen if already in the last row of the transaction. There is no distinction about whether 'Enter' refers to the button on the menubar or one of the 'Enter' keys on the keyboard. In any case, that preference has been unchecked during all of the above tests. I have not repeated trying gdb, I just assumed it would fail again. Would MinGw or Codelite work for a casual user, or do I need to know what I am doing?
Most of comment #10 sounds like a new bug. Am I missing how it's related? > Would MinGw or Codelite work for a casual user, or do I need to know what I > am doing? MinGW gives *me* fits. Dunno what Codelite is, but MinGW is known to not work well with some other environments -- Cygwin being the one most often cited. You're very likely to have a learning curve to climb either way. Here's another idea that might help narrow down where the crash is occurring. Run Gnucash it a window with --log gnc.gui.sx=debug and attach the resulting gnucash.trace after making it crash.
Perhaps it is a new bug because the 'enter' keyboard key behavior has changed. I put it here because the same user action (attempting to accept a scheduled transaction edit by mouse clicking OK followed by yes) is still triggering a crash failure. Now that I have returned to 2.4.13 I see that using either the 'enter' button on the menubar or using the 'enter' keyboard keys automatically commits the change without going through the confirmation step. This is fewer keystrokes (or mouse clicks) than the new behavior, and it does not irretrievably push the user down a path he did not intend to follow. If it is possible to match this behavior in the register2 style it would save a few mouse clicks. The 'enter' setting box in the preferences is unchecked and uses the same wording in release 2.4.13. The flyover prompt does include the word key after the word enter, but it does not distinguish whether it is referring to keyboard keys or the menubar button with the same name, or either. Regarding Codelite, it seems to be a GUI for MinGW which I found in my initial research on GDB. I can only learn so many things in one day before my head starts to hurt, so I need to ration my playtime with this stuff. Next time I play with 2.5.4 I will try --log gnc.gui.sx=debug. Can I just edit my Windows shortcut for starting GnuCash to add that to the command line?
>Can I just edit my Windows shortcut for starting GnuCash to add that to the > command line? I think so. It won't hurt to try. ;-) As for what's possible with the new register code, I don't know. That's all Bob Fewell's work, and I've added him as a CC on this bug in the hope that he'll join in.
Created attachment 254627 [details] trace file after crash on 09-10-2013
If I follow steps 1 through 3 of the procedure outlined in comment 0 using release 2.5.5, then mouseclick on the OK button then mouseclick on Yes to accept the edit, GnuCash still crashes. However, if I first tab through until the transaction changed prompt appears and I accept the edit, then mouseclick on OK and mouseclick yes to accept the edit, the Scheduled transaction editor closes without crashing. That was with --log gnc.gui.sx=debug appended to the command line. Now I will attach the gnucash.trace file
Replicated in OSX with 2.5.5. Here's the important part of the backtrace: 0 libgncmod-gnome-utils.dylib 0x003659eb gnc_tree_model_split_reg_update_query + 126 (gnc-tree-model-split-reg.c:1056) 1 libgncmod-ledger-core.dylib 0x0003068f gnc_ledger_display2_refresh + 349 (gnc-ledger-display2.c:983) 2 libglib-2.0.0.dylib 0x02e97c0e g_idle_dispatch + 71 (gmain.c:5205) 3 libglib-2.0.0.dylib 0x02e95521 g_main_dispatch + 399 (gmain.c:3054) 4 libglib-2.0.0.dylib 0x02e9619a g_main_context_dispatch + 41 (gmain.c:3633) 5 libglib-2.0.0.dylib 0x02e96379 g_main_context_iterate + 466 (gmain.c:3703) 6 libglib-2.0.0.dylib 0x02e967ab g_main_loop_run + 476 (gmain.c:3894)
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=702880. Please continue processing the bug there and please update any external references or bookmarks.