GNOME Bugzilla – Bug 376298
Price Editor Window Contents Corrupted After Manually Adding a Price
Last modified: 2018-06-29 21:16:23 UTC
Please describe the problem: After a manual price addition is done the priced editor throws groups of the 3 error messages (see below), and the window fills with many partially rendered repetitions of the same line. Move the mouse pointer within the window causes more triplets of errors. The errors appear, presumably on stderr, in the xterm window that gnucash was launched into the background from (gnucash &). Mac OS X 10.4.8 (PPC) Steps to reproduce: 1. Launch gnucash from xterm (gnucash &). 2. Open the Price Editor. Select a instance of a stock price. Click Add. Do a manual price entry, tabbing through the fields, and using the short-cut keys to set the date. Hit enter to commit the record. Actual results: The price editor window fills with partially rendered lines, and groups of the the 3 error messages below appear in the xterm window. Moving the mouse cursor anywhere in the price editor window cause more of the same errors to be thrown. Error Messages: (gnucash:25596): Gtk-CRITICAL **: gtk_tree_model_filter_get_value: assertion `GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed (gnucash:25596): GLib-GObject-CRITICAL **: g_object_set_property: assertion `G_IS_VALUE (value)' failed (gnucash:25596): GLib-GObject-CRITICAL **: g_value_unset: assertion `G_IS_VALUE (value)' failed Expected results: The display not to be corrupted, and no errors in the xterm window :-) Does this happen every time? Yes. Other information: Closing and re-opening the price editor puts everything back to normal. The price entered is present, and there is now evidence of data corruption. but if another price is entered, the problem recurs.
Created attachment 76757 [details] Screen Capture of Corrupted Price Editor Window
I can confirm the same for gnucash 2.0.1, 2.0.2 and 2.0.4 on a Linux system running Gentoo Linux. This problem started to show after an upgrade of the system, therefore I would think it might be some incompatibility between Gtk+ (or other library) versions. I am using gtk+-2.10.6, the previous version that worked with gnucash was 2.6.7, but I cannot switch back to really check if this is the reason. Beda Kosata p.s.- please let me know if you need more information about my system.
I can confirm the exact same problem for gnucash 2.0.1 on Ubuntu Linux 6.10 (Edgy Eft). Suggestions?
Downgrading GTK+ to 2.8.20 (instead of 2.10.6) solved the problem for me.
I see the same thing after upgrading Gtk+ to 2.10.9 from 2.6.10 on MacOSX. Gtk+ 2.10.10 also fails. This is with GnuCash SVN version 15707 with no local mods.
This is fixed in r15788 and is awaiting backport to 2.0.
(In reply to comment #6) > This is fixed in r15788 and is awaiting backport to 2.0. (If it's confirmed and fixed, please don't leave it UNCONFIRMED). I've experienced this today with svn/trunk@15951 / 2.1.
Well, I backported r15788 as r15958 into 2.0, so that change will be in 2.0.6 But you're saying this bug ISN'T fixed?
(In reply to comment #8) > Well, I backported r15788 as r15958 into 2.0, so that change will be in 2.0.6 > > But you're saying this bug ISN'T fixed? I saw very similar behavior. The dialog didn't reflect the values I entered. Logged: * 13:23:27 CRIT <Gtk> gtk_tree_model_row_has_child_toggled: assertion `path != NULL' failed * 13:24:16 CRIT <Gtk> gtk_tree_model_filter_get_value: assertion `GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed * 13:24:16 CRIT <GLib-GObject> g_object_set_property: assertion `G_IS_VALUE (value)' failed * 13:24:16 CRIT <GLib-GObject> g_value_unset: assertion `G_IS_VALUE (value)' failed * 13:24:16 CRIT <Gtk> gtk_tree_model_filter_get_value: assertion `GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed * 13:24:16 CRIT <GLib-GObject> g_object_set_property: assertion `G_IS_VALUE (value)' failed * 13:24:16 CRIT <GLib-GObject> g_value_unset: assertion `G_IS_VALUE (value)' failed [...~530 triples like these...] * 13:24:23 CRIT <Gtk> gtk_tree_model_filter_get_value: assertion `GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed * 13:24:23 CRIT <GLib-GObject> g_object_set_property: assertion `G_IS_VALUE (value)' failed * 13:24:23 CRIT <GLib-GObject> g_value_unset: assertion `G_IS_VALUE (value)' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:24 CRIT <Gtk> gtk_tree_model_filter_real_unref_node: assertion `filter->priv->stamp == iter->stamp' failed * 13:24:40 CRIT <gnc.engine> xaccAccountGetFullName: assertion `GNC_IS_ACCOUNT(account)' failed * 13:24:45 CRIT <gnc.engine> gnc_account_is_root: assertion `GNC_IS_ACCOUNT(account)' failed After closing and re-opening the editor, the prices I'd entered were there.
Created attachment 87306 [details] Test file to demonstrate the problem I don't think this bug is entirely fixed. It works most of the time, but tonight while trying to figure out why getting online quotes didn't work (which was entirely my problem), I saw this happen again. If I open the attached file in GnuCash svn version 16023 using gtk2 version 2.10.11 and glib 2.12.11 I see very similar behavior. To see it open the price editor, expand the NYSE and MMM outline levels and tell it to download price quotes. After it is done the price editor window is totally hosed, but if you close it and open it again everything is ok. The terminal logs lots of error sequences like * 01:07:55 CRIT <Gtk> gtk_tree_model_filter_get_value: assertion `GTK_TREE_MODEL_FILTER (model)->priv->stamp == iter->stamp' failed * 01:07:55 CRIT <GLib-GObject> g_object_set_property: assertion `G_IS_VALUE (value)' failed * 01:07:55 CRIT <GLib-GObject> g_value_unset: assertion `G_IS_VALUE (value)' failed Let me know if you need more information.
This is still not entirely fixed although I haven't seen it as often recently. To reproduce it in R17236 follow these steps: ------- Create new file with simple checkbook and investment accounts Change the commodity of the Stock account to a newly created stock (AMEX/WDGT - Widgets). Open the price editor Add a price of $10 for WDGT yesterday Expand the tree to show this new price and select it Click Add to add a new price of 11 for today -------- I was using glib2 2.16.3 and gtk2 2.12.9 but I don't know if that matters.
Created attachment 114359 [details] [review] Proposed patch (but see comment 12) This patch fixes the problem for me, so please give it a try. Basically I saw no reason to call gtk_tree_model_row_has_child_toggled() on any but the most immediate parent. I do not pretend to understand GTK well, so if this is bad practice then I wouldn't know better. So I hope someone who knows their stuff can review this patch. Later on in this function, I also wondered why the stamp for this model was being changed just after creating a bunch of iterators for the signals being issued. Seems weird to pass out iterators and immediately invalidate them by changing the model's stamp. Can someone confirm whether this is bad practice? If so, I can attach a fix for that too (I already played with this).
I also wonder why the stamp needs to be changed at all in this function. Since we are only adding a row, all existing iterators can remain valid.
To answer my own questions: Re comment 13: The stamp must change because the iterators are based on indices into price and commodity db lists that have changed. So all iterators (except the one for the new row) need to be invalidated by updating the model. Re comment 12: I still believe the stamp should be changed before issuing the signals. Iterators are supposed to at least remain until a signal is issued, and here we see a routine that invalidates them right after issuing signals. I've made some progress on a more complete patch that also addresses bug 593640, so I hope to be commit it soon.
That should have read: "Re comment 13: The stamp must change because the iterators are based on indices into price and commodity db lists that have changed. So all iterators (except the one for the new row) need to be invalidated by updating the STAMP."
Fix committed as r17441. Requesting backport for 2.2.
Applied to branches/2.2 as r17580 for inclusion in GnuCash 2.2.7. Thanks a lot!
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=376298. Please update any external references or bookmarks.