GNOME Bugzilla – Bug 364946
crash in gtk_tree_model: Adding new account, or entering a transfer, or other actions
Last modified: 2008-05-05 13:46:24 UTC
Steps to reproduce: 1. Start gnucash. 2. Select Tools->HBCI Setup 3. Click "Forward" twice. 4. Match a new ofx direct connect account to one of my existing gnucash accounts 5. Click "Forward" again. 6. Click "Apply." Stack trace: (gdb) continue Continuing. 3:2006/10/25 02-57-25:(null)(3228):provider.c: 194: Deinit done on_accountlist_select_row: Selected hbci_acc id XXXXXXXXXXXX2693; old_value (nil) Gtk-ERROR **: file gtktreemodelsort.c: line 2293 (gtk_tree_model_sort_clear_cache_helper): assertion failed: (level != NULL) aborting... Program received signal SIGABRT, Aborted. [Switching to Thread -1209211184 (LWP 3228)] 0x0027d402 in __kernel_vsyscall () (gdb) thread apply all bt
+ Trace 78205
Thread 1 (Thread -1209211184 (LWP 3228))
Other information: If a developer wants a copy of the data file that's causing the crash, send me an e-mail and I'll send it to you. (I don't want to attach my personal financial data for everyone to see.)
I found a really strange workaround for this issue. The crash seems to occur only if I try to match the ofx direct connect account to an existing gnucash account. If I create a new account rather than matching it to an existing account, then it doesn't crash. Just an FYI.
Which version of gtk/glib is this?
$ rpm -q gtk2 gtk2-2.10.4-4.fc6 $ rpm -q glib glib-1.2.10-23.fc6
Version of "glib2"? A slightly similar crash occurs in bug#351371 - well, similar in that I have no idea of what is going on, and that it's rather related to the gtk_tree_model instead of aqbanking or gnucash peculiarities. The Aqbanking-Import part ends at #28 by calling xaccAccountCommitEdit(); I don't see whether anything were wrong here. Well, just for information: Which windows with the account hierarchy were open when the crash occurred? Probably the account chooser from the HBCI setup window, and probably also one general account hierarchy tab/window.
$ rpm -q glib2 glib2-2.12.3-2.fc6 Yes, the only windows that were open were the HBCI setup window and the general account hierarchy tab/window. I guess I should mention that in the past, I managed to match a new ofx direct connect account to an existing gnucash account without any problems. I only got this crash when I tried to do it again this past week after I got a new credit card. I also upgraded from Fedora Core 5 to Fedora Core 6 this past week, so I think you might be right that there's something strange in the latest versions of glib and/or gtk.
Can you additionally check whether bug#351371#c11 occurs on your system as well, i.e. can you follow the instructions for reproducing the crash and see what happens? Thanks.
*** Bug 370344 has been marked as a duplicate of this bug. ***
Note that this supposed "duplicate" bug#370344 talks about a completely different user action - but the backtrace indeed looks strikingly similar. One more reason to this is is due to some gtk issues instead of OFX or gnucash issue. @tsang_cn: Can you report your version numbers of glib2 and gtk? That might be helpful. Thanks.
The problem as described in bug#370344 occurs when I have upgraded my system from Fedora Core 5 to Fedora Core 6. After I have saved my guncash file once, the problem does not occurs again. The version of glib2 is glib2-2.12.3-2.fc6 The version of gtk is gtk+-1.2.10-55.fc6 and gtk2-2.10.4-4.fc6 Thanks.
*** Bug 374345 has been marked as a duplicate of this bug. ***
*** Bug 376153 has been marked as a duplicate of this bug. ***
bug#376153 has the same failed assertion in gtktreemodelsort.c:2293; the user action was "add a new transaction" (it's unclear in which way the transaction was entered, though), similarly to bug#370344 . bug#351371 has a slightly different failed assertion in gtktreemodelsort.c:2419 although this might still be the same bug and these are only different gtk version numbers.
*** Bug 377265 has been marked as a duplicate of this bug. ***
gtktreemodelsort.c:2293 is also mentioned in bug 377265. at least confirming as per duplicates, feel free to move this to gtk+.
*** Bug 378143 has been marked as a duplicate of this bug. ***
*** Bug 378985 has been marked as a duplicate of this bug. ***
*** Bug 379271 has been marked as a duplicate of this bug. ***
*** Bug 380580 has been marked as a duplicate of this bug. ***
*** Bug 380682 has been marked as a duplicate of this bug. ***
*** Bug 381641 has been marked as a duplicate of this bug. ***
*** Bug 381676 has been marked as a duplicate of this bug. ***
*** Bug 383806 has been marked as a duplicate of this bug. ***
*** Bug 384881 has been marked as a duplicate of this bug. ***
Moving to GTK+.
*** Bug 385191 has been marked as a duplicate of this bug. ***
*** Bug 385549 has been marked as a duplicate of this bug. ***
*** Bug 386713 has been marked as a duplicate of this bug. ***
*** Bug 386895 has been marked as a duplicate of this bug. ***
*** Bug 387515 has been marked as a duplicate of this bug. ***
*** Bug 389549 has been marked as a duplicate of this bug. ***
Is a11y enabled in these cases? If yes, does the problem also exist if a11y is turned off? This stack trace and the traces in the duplicates I've seen don't make much sense (gtk_tree_model_sort_new_with_model() does not call the cache cleaning code, the filter's iter conversion code does not call _row_changed() nor g_assert_warning().)
*** Bug 388973 has been marked as a duplicate of this bug. ***
*** Bug 389847 has been marked as a duplicate of this bug. ***
*** Bug 391189 has been marked as a duplicate of this bug. ***
*** Bug 391685 has been marked as a duplicate of this bug. ***
*** Bug 391087 has been marked as a duplicate of this bug. ***
*** Bug 391951 has been marked as a duplicate of this bug. ***
Setting to NEEDINFO until somebody answers Kris' question from comment 31.
I reported bug #381641. I don't have a11y enabled.
(In reply to comment #31) > This stack trace and the traces in the duplicates I've seen don't make much > sense (gtk_tree_model_sort_new_with_model() does not call the cache cleaning > code, the filter's iter conversion code does not call _row_changed() nor > g_assert_warning().) I'm sorry, but I cannot provide additional information as well. We (the gnucash devs) are getting swamped by these bug-buddy reports and obviously they are all caused by the same or similar crashes, but there is (too) little additional information that we get as well. Also, none of the gnucash developers has been able to reproduce any of these crashes. The only backtrace with debugging information that I've seen was in bug#351371, but it's a different trace. @Michael Wise: Can you install the gnucash-debuginfo and gtk2-debuginfo package (if such thing exists) and/or try to install gnucash from source with --enable-debug, and see whether you can reproduce that crash? We would definitely need the stack trace with full debug info...
*** Bug 392600 has been marked as a duplicate of this bug. ***
*** Bug 392775 has been marked as a duplicate of this bug. ***
(In reply to comment #31) > the filter's iter conversion code does not call _row_changed() nor > g_assert_warning().) Well, the point of the g_assert_warning is shown clearly in the command line messages: file gtktreemodelsort.c: line 2293 (gtk_tree_model_sort_clear_cache_helper): assertion failed: (level != NULL) aborting... This function name just doesn't appear in the backtrace.
I haven't had it crash since the bug report I filed. I've gone ahead and installed the debuginfo packages just in case and I've also compiled from source and run it a little. I haven't got it to crash either. I'm running update FC6
*** Bug 393682 has been marked as a duplicate of this bug. ***
*** Bug 393691 has been marked as a duplicate of this bug. ***
*** Bug 393854 has been marked as a duplicate of this bug. ***
A somehow similar crash is in bug#398779 and it appears only if accessibility is enabled, not when it is disabled.
*** Bug 399453 has been marked as a duplicate of this bug. ***
*** Bug 371086 has been marked as a duplicate of this bug. ***
*** Bug 400618 has been marked as a duplicate of this bug. ***
*** Bug 401274 has been marked as a duplicate of this bug. ***
*** Bug 396715 has been marked as a duplicate of this bug. ***
*** Bug 401942 has been marked as a duplicate of this bug. ***
*** Bug 401963 has been marked as a duplicate of this bug. ***
*** Bug 404771 has been marked as a duplicate of this bug. ***
As far as I can see #398779 and this one are unrelated ...
*** Bug 405753 has been marked as a duplicate of this bug. ***
*** Bug 407725 has been marked as a duplicate of this bug. ***
*** Bug 407805 has been marked as a duplicate of this bug. ***
*** Bug 408443 has been marked as a duplicate of this bug. ***
*** Bug 407545 has been marked as a duplicate of this bug. ***
bug#405228 has interesting additional explanations and confirms again this crash disappears with disabled accessibility.
FYI, http://svn.gnome.org/viewcvs/gtk%2B/trunk/gtk/gtktreemodelsort.c?r1=16598&r2=16599&view=patch seems to fix a crash in my small test scenario. It still criticizes that "gtk_tree_model_sort_real_unref_node: assertion `elt->ref_count > 0' failed", but I have not build from trunk yet, but only patched 2.10.9. I suppose the solution is to be found in a sufficiently large neighborhood of that. My scenario (some things may be unnecessary, but never change a crashing system): * download http://gd.tuwien.ac.at/gnu/gnucash/test-data/huge_test_file.bz2 * enable a11n * expand all children of some account with the help of Shift+KP_Plus * Tools -> General Ledger * View -> Filter by..., Show All * <Tab><Tab> to description * enter T327 * press <Tab> to crash... PS: I cannot remember, I probably trimmed the file down a bit a while ago, so get yourself a cup of coffee...
*** Bug 409811 has been marked as a duplicate of this bug. ***
*** Bug 412445 has been marked as a duplicate of this bug. ***
Created attachment 83439 [details] 40-liner to provoke the crash OK, the current gtk+ trunk does not crash, but only print above warning. See the attachment for a small test case. No accessibility needed.
Congrats Andreas! How did you manage to find this example? :-) The testcase of comment#67 will crash on a stock opensuse10.2 system, gtk-2.10.6, and gives Gtk-ERROR **: file gtktreemodelsort.c: line 2293 (gtk_tree_model_sort_clear_cache_helper): assertion failed: (level != NULL) aborting...
*** Bug 406755 has been marked as a duplicate of this bug. ***
*** Bug 405228 has been marked as a duplicate of this bug. ***
(In reply to comment #67) > Created an attachment (id=83439) [edit] > 40-liner to provoke the crash Thanks a lot for this testcase! I still wonder how you managed to come up with it, but it really, really helps debugging :) It seems to be a nasty problem in the zero ref counting, where levels with a referenced node somewhere in their child levels are blown away. I will attach a quick and dirty fix which makes the issue disappear. I need some more time to think about a proper fix, there should be a better solution than just referencing all parent levels/nodes (however, it does make sense somewhere).
Created attachment 83502 [details] [review] quick-n-dirty patch
*** Bug 403971 has been marked as a duplicate of this bug. ***
*** Bug 413295 has been marked as a duplicate of this bug. ***
*** Bug 351371 has been marked as a duplicate of this bug. ***
Thanks a lot, Kristian, that patch helps for the moment. Great! :)
*** Bug 413776 has been marked as a duplicate of this bug. ***
*** Bug 412236 has been marked as a duplicate of this bug. ***
*** Bug 414303 has been marked as a duplicate of this bug. ***
*** Bug 414979 has been marked as a duplicate of this bug. ***
Kris, do you consider your quick-and-dirty patch a candidate for 2.10.10 ?
Not 100% sure yet. Maybe we should put it in 2.10.10, it shouldnt hurt much and we can fix it property in 2.12.
*** Bug 415148 has been marked as a duplicate of this bug. ***
Created attachment 84351 [details] [review] patch as committed On a second thought I decided that reffing the parent elements of an element actually makes a lot of sense :) I reworked the patch to look a little nicer and committed.
gtk-2-10 also needed the zero refcounting clean ups/fixes which have been in trunk for a long while already (but always hesitated to merge to 2-10), which have also been committed today. Thanks to everybody involved for the help with providing traces and testcases!
*** Bug 417198 has been marked as a duplicate of this bug. ***
*** Bug 417519 has been marked as a duplicate of this bug. ***
*** Bug 419280 has been marked as a duplicate of this bug. ***
*** Bug 419328 has been marked as a duplicate of this bug. ***
*** Bug 419453 has been marked as a duplicate of this bug. ***
*** Bug 419959 has been marked as a duplicate of this bug. ***
*** Bug 420233 has been marked as a duplicate of this bug. ***
*** Bug 421641 has been marked as a duplicate of this bug. ***
*** Bug 428788 has been marked as a duplicate of this bug. ***
Just for completeness: The patch has been committed to gtk-trunk and back-ported to gtk_2_10 branch, so that it appears in gtk-2.10.10 (released around March 15th, 2007) and all higher version of gtk+.
*** Bug 429648 has been marked as a duplicate of this bug. ***
*** Bug 431682 has been marked as a duplicate of this bug. ***
*** Bug 432817 has been marked as a duplicate of this bug. ***
*** Bug 443225 has been marked as a duplicate of this bug. ***
*** Bug 457460 has been marked as a duplicate of this bug. ***
*** Bug 460442 has been marked as a duplicate of this bug. ***
*** Bug 531091 has been marked as a duplicate of this bug. ***