GnuCash will freeze up for several seconds when clicking on either the "taxable", "tax included," or "tax table" cell of a new invoice on two different computers, one Lubuntu and the other Windows. The Windows computer will often crash during the freeze. The freeze happens almost every time I click on these things. on Lubuntu, I've built 3.8 from source, attempted to build with debug symbols (cmake -DCMAKE_BUILD_TYPE=Debug), and have paused the program during the freeze to grab a stack trace (though I don't think GDB is loading the sources, however). That output can be found here: https://pastebin.com/YFsdA48J Windows trace file "gnucash.trace.JA1HG0.log" after a crash like this: https://pastebin.com/PpUEKw59 Lubuntu is GnuCash 3.8 / Build ID: 3.8b+(2019-12-29) Windows is the 3.8 downloadable installer from the website. I've also pasted all of my trace files from the Windows system here ( https://pastebin.com/FJYQH1Z9 ). Many of them are from this same crash, though some of them may be from other different crashes. I've set the priority to major, as this kind of freeze and crash happens frequently.
Please attach your stack trace and the one log to this bug. The stack trace indicates that GnuCash is sitting in the event loop awaiting input. You might be able to get a more informative stack trace by letting GnuCash crash. That may or may not indicate what's causing the hang. The Windows log file indicates that you're out of memory, but it's rather sparse. You can get (a lot) more detail by starting GnuCash with the --debug option.
I've produced a new stack trace & log, using the --debug option, for both Lubuntu and Windows. I haven't had a crash on Linux in a while, but I was able to break the program and grab a backtrace during a stall. The log for Windows here, I was able to start GnuCash and get it to freeze up right away. Task Manager showed GnuCash using 100% CPU and like 700mb of memory during the stall, and then it came back to life for just a couple seconds and promptly crashed. For reference, When GnuCash is just idling happily on program load, it uses about 100mb with a few account/invoice/etc tabs open. I will attach these now.
Created attachment 373586 [details] A new stack trace via GDB
Created attachment 373587 [details] An auto-generated trace file on Linux, no crash just a freeze and exit, using --debug arg
Created attachment 373588 [details] An auto-generated trace file on Windows, with freeze and crash, using --debug arg
The stack trace shows gtk drawing a popup editor from the register. Install the gtk and glib debug symbols and try again. I don't know anything about lubuntu's packaging. Real ubuntu has -dbg packages for both in Xenial; later releases have switched to a separate distribution server for symbols, see https://wiki.ubuntu.com/Debug%20Symbol%20Packages. On the other hand the Linux log file indicates a total elapsed time of 21 seconds from program launch to program shut down and the Windows one is only 37 seconds. Not much of a hang. The windows log indicates the crash might be in qof_query_run_internal. You can get it to print the query it's running by adding --log qof.query=debug. That should also add ENTER and LEAVE messages that can confirm that the crash is actually there or if that's merely the last logging statement that it encountered.
I have tried to reproduce on a Windows 7 system and on a Fedora 31 system (Plasma desktop). Both are very snappy, I don't experience any delays. That makes it much harder to debug unfortunately :( To get some context: - how much RAM do you have available on the systems you are testing this on ? - how "big" is your book as in, how many customers, how many invoices (estimates) ?
I wonder if some may be related to bug 797290 - reproduced on invoice editor in new-ish book only.
(In reply to Geert Janssens from comment #7) > I have tried to reproduce on a Windows 7 system and on a Fedora 31 system > (Plasma desktop). Both are very snappy, I don't experience any delays. > > That makes it much harder to debug unfortunately :( > > To get some context: > - how much RAM do you have available on the systems you are testing this on ? > - how "big" is your book as in, how many customers, how many invoices > (estimates) ? RAM on the Linux desktop is 8gb with AMD quad-core Phenom II X4 965. Windows is a 4gb pentium G2020T dual-core @ 2.5ghz. 234 Customers, 314 invoices. (In reply to John Ralls from comment #6) > The stack trace shows gtk drawing a popup editor from the register. Install > the gtk and glib debug symbols and try again. I don't know anything about > lubuntu's packaging. Real ubuntu has -dbg packages for both in Xenial; later > releases have switched to a separate distribution server for symbols, see > https://wiki.ubuntu.com/Debug%20Symbol%20Packages. > > On the other hand the Linux log file indicates a total elapsed time of 21 > seconds from program launch to program shut down and the Windows one is only > 37 seconds. Not much of a hang. > > The windows log indicates the crash might be in qof_query_run_internal. You > can get it to print the query it's running by adding --log qof.query=debug. > That should also add ENTER and LEAVE messages that can confirm that the > crash is actually there or if that's merely the last logging statement that > it encountered. I'm not seeing any available debug packages for glib or gtk (eg, `apt-cache search . | grep gtk -i | grep dbg -i`) That sounds like the total number of seconds the program was open. The hang on linux can vary from zero to several seconds. On Windows, it is usually around 10 seconds. For now I'll just focus on the Windows system, as that is where the crash happens. I'll invoke a crash on Windows again with the --log qof.query=debug argument momentarily.(In reply to Christopher Lam from comment #8) > I wonder if some may be related to bug 797290 - reproduced on invoice editor > in new-ish book only. I'll see if I can reproduce that bug as well and report back when I make my next log upload.
Created attachment 373589 [details] An auto-generated trace file on Windows, with freeze and crash with --debug --log qof.query=debug
The freeze (and often subsequent crash) most often happens when clicking the drop down for tax table, less often with the other tax check-boxes, and so far never with any other cell there. It seems to happen *mostly* on an invoice (whether new or existing) line entry that is in-progress (as opposed to an entry that was entered previously and is being modified) Sometimes it un-freezes when I click a different cell and wait a second. If I don't click off of it and let it crash, the memory usage skyrockets. From 100mb on average load all the way up to 1.3gb just this last time I invoked a crash. Clearly there's some run-away loop that's hogging up memory until it crashes, as pointed out previously. I followed the steps mentioned in bug 797290 (duplicate of Bug 797290) precisely, and I was not able to invoke a crash.
Sorry, this fell through the cracks. There's a clue in the stack trace after all, but it might be more related to bug 797290 than to this one. The clue is that gnc_item_edit_update is running. That's run from an idle event that's queued either by gnc_item_edit_configure or check_popup_height_is_true. That in turn is fired by a size-allocate signal emitted by gtk_widget_show that's called by gnc_item_edit_update. check_popup_height_is_true queues gnc_item_edit_update if the popup's allocation is different from the stored one, and when the list is empty the allocation is 1 and the stored allocation is 0, causing a nice loop that spins up the CPU usage. That's the runaway loop, but I don't yet see where it would leak memory. Still, breaking the loop will certainly help a lot. This stops that but it's a bit hackish: --- a/gnucash/register/register-gnome/combocell-gnome.c +++ b/gnucash/register/register-gnome/combocell-gnome.c @@ -916,7 +916,7 @@ popup_get_height (G_GNUC_UNUSED GtkWidget* widget, { gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrollwin), GTK_POLICY_AUTOMATIC, GTK_POLICY_NEVER); - return height; + return height ? height : 1; } gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrollwin), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC); Bob Fewell, what do you think of it?
Looking at this...
From what I can see, this prevents the popup_get_height from being called multiple times if there are no entries in the list which is a good thing. I have tried it and can see no obvious reasons not to do it but it may be a good idea to add a note advising why it is there. In the context of this bug, from the trace file I can see there were 2 tax tables and on Chris's bug797290 there are 3 income accounts but if there was a book with no accounts this would also help here. In all the testing I have done on my Linux VM, there has never been a crash or it becoming unresponsive. There is some thing else going on with the invoice page I have noticed, with the description field active, click in the notes field and type some text, now click on the description field and type some more which appears in the notes field.
Wouldn't it be more clever to disable the drop-down arrow if the number of elements is zero?
I am not sure, I did think of something similar in that it prevented the popup if the list was empty but I think that would require extra code to retrieve the list count from the popup. Also, from a user point of view which is better... You click on the popup button, arrow changes but no list indicating nothing in list. You click on the popup button and nothing happens. There is no button to click on, what do you do. Maybe the list should never be empty, there should be a dummy entry or dummy list with one entry of "Nothing found".
OK, after some testing the following should work... Add a new function to item_edit to set the button sensitivity based on the number of items in the list. The entry is still valid and you can add some text with the usual dialog appearing about new entry, do you want to create it. Have a try and see if there are any problems. --- a/gnucash/register/register-gnome/combocell-gnome.c +++ b/gnucash/register/register-gnome/combocell-gnome.c @@ -916,7 +916,8 @@ popup_get_height (G_GNUC_UNUSED GtkWidget* widget, { gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrollwin), GTK_POLICY_AUTOMATIC, GTK_POLICY_NEVER); - return height; + return height ? height : 1; } gtk_scrolled_window_set_policy (GTK_SCROLLED_WINDOW (scrollwin), GTK_POLICY_AUTOMATIC, GTK_POLICY_AUTOMATIC); @@ -999,6 +1000,9 @@ gnc_combo_cell_enter (BasicCell* bcell, gnc_item_list_select (box->item_list, bcell->value); unblock_list_signals (cell); + gnc_item_edit_set_button_sensitive (box->item_edit, + gnc_item_list_num_entries (box->item_list)); + combo_connect_signals (cell); *cursor_position = -1; diff --git a/gnucash/register/register-gnome/gnucash-item-edit.c b/gnucash/register/register-gnome/gnucash-item-edit.c index 3ea0de310..d8b69b55b 100644 --- a/gnucash/register/register-gnome/gnucash-item-edit.c +++ b/gnucash/register/register-gnome/gnucash-item-edit.c @@ -945,6 +945,13 @@ gnc_item_edit_destroying (GtkWidget *item_edit, gpointer data) continue; } +void +gnc_item_edit_set_button_sensitive (GncItemEdit *item_edit, gboolean sensitive) +{ + gtk_widget_set_sensitive (GTK_WIDGET(item_edit->popup_toggle.tbutton), + sensitive); +} + static void check_popup_height_is_true (GtkWidget *widget, GdkRectangle *allocation, diff --git a/gnucash/register/register-gnome/gnucash-item-edit.h b/gnucash/register/register-gnome/gnucash-item-edit.h index 185f3e325..ab489d880 100644 --- a/gnucash/register/register-gnome/gnucash-item-edit.h +++ b/gnucash/register/register-gnome/gnucash-item-edit.h @@ -166,6 +166,7 @@ gint gnc_item_edit_get_margin (GncItemEdit *item_edit, Sides side); gint gnc_item_edit_get_padding_border (GncItemEdit *item_edit, Sides side); gint gnc_item_edit_get_button_width (GncItemEdit *item_edit); +void gnc_item_edit_set_button_sensitive (GncItemEdit *item_edit, gboolean sensitive); GType gnc_item_edit_tb_get_type (void); GtkWidget *gnc_item_edit_tb_new (GnucashSheet *sheet); --
Created attachment 374040 [details] Suggested patch OK, that last update was maybe too much so here is the patch.
For me this works well. With this patch we don't even need to modify the "return height" line. Because jralls likes clarity, the combocell-gnome.c would be: --- modified gnucash/register/register-gnome/combocell-gnome.c @@ -999,6 +999,9 @@ gnc_combo_cell_enter (BasicCell* bcell, gnc_item_list_select (box->item_list, bcell->value); unblock_list_signals (cell); + if (gnc_item_list_num_entries (box->item_list) == 0) + gnc_item_edit_set_button_sensitive (box->item_edit, FALSE); + combo_connect_signals (cell); *cursor_position = -1; ---
(In reply to Christopher Lam from comment #19) > For me this works well. With this patch we don't even need to modify the > "return height" line. Because jralls likes clarity, the combocell-gnome.c > would be: > > > --- > modified gnucash/register/register-gnome/combocell-gnome.c > @@ -999,6 +999,9 @@ gnc_combo_cell_enter (BasicCell* bcell, > gnc_item_list_select (box->item_list, bcell->value); > unblock_list_signals (cell); > > + if (gnc_item_list_num_entries (box->item_list) == 0) > + gnc_item_edit_set_button_sensitive (box->item_edit, FALSE); > + > combo_connect_signals (cell); > > *cursor_position = -1; > --- Not only is that no more clear than Bob's version, it's wrong because it fails to enable the button when the list has entries.
Comment on attachment 374040 [details] Suggested patch Why does gnc_item_edit_set_button_sensitive need to be public instead of static inline?
Created attachment 374041 [details] Suggested patch It doesn't, just the first thing that came to mind. It can all be done in combocell-gnome.c, updated the patch. I still think it worth while adding your change and maybe be worth adding a comment for both changes.
Wrapping gtk_widget_set_sensitive with a function that declared its intent was fine, it just shouldn't have been exposed as public. The new patch is fine too. Go ahead and push.
*** Bug 797290 has been marked as a duplicate of this bug. ***
OK have pushed the changes to maint and will be in he next release 4.5 Should we close this as reported some time ago?
https://github.com/Gnucash/gnucash/commit/48698395e223fa9d157e8f961a29e91876946f87
There's still edge cases e.g. - create a completely empty book - create 1 customer, create 1 invoice - invoice's Income dropdown is disabled as expected (thanks bob) - switch to accounts tab, create Income account - switch to invoice tab, select the newly created Income account - switch to accounts tab, delete Income account - switch to invocie tab, and the Income dropdown is empty but enabled with height equivalent to 1 account.
p.s. feel free to ignore comment #27 -- this is sufficiently obscure and harmless
