GNOME Bugzilla – Bug 351371
Crash on Ok in "Transfer" dialog
Last modified: 2018-06-29 21:11:23 UTC
Distribution: Unknown Package: GnuCash Severity: blocker Version: GNOME2.12.2 2.0.1 Gnome-Distributor: SUSE Synopsis: Crash during HBCI online transaction Bugzilla-Product: GnuCash Bugzilla-Component: AqBanking Import Bugzilla-Version: 2.0.1 BugBuddy-GnomeVersion: 2.0 (2.12.0) Description: Description of the crash: GnuCash just crashes Steps to reproduce the crash: 1. start an online transaction using hbci 2. 3. Expected Results: crash How often does this happen? always Additional Information: Debugging Information: Backtrace was generated from '/usr/local/bin/gnucash' Using host libthread_db library "/lib/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1231726928 (LWP 25213)] 0xb7f80410 in __kernel_vsyscall ()
+ Trace 70454
Thread 1 (Thread -1231726928 (LWP 25213))
------- Bug created by bug-buddy at 2006-08-14 21:46 -------
There was a similar crash reported on gnucash-de, see summary here https://lists.gnucash.org/pipermail/gnucash-de/2006-August/004277.html and full stack trace here https://lists.gnucash.org/pipermail/gnucash-de/2006-August/004252.html ; the stack trace is similar in that it crashes below gnc_xfer_dialog_run_until_done(), so in terms of the involved HBCI, this is rather similar. The actual failed assertion is different, though. Can you please compare the other details to the email on gnucash-de? In particular, which security medium is this? Which version of suse, aqbanking, gwenhywfar, glib2, gtk2, (if chipcard: version of libchipcard), and which messages did you see on the command line? In the HBCI Einzelüberweisung, do you have *any* non-ascii characters (German umlauts), e.g. in the Zahlungsempfänger, Verwendungszweck, Name des Auftraggebers?
OK, I'll try to collect the required information. openSuSE 10.1 aqbanking-2.2.0-0.oc2pus.1 gwenhywfar-2.3.1-0.oc2pus.1 glib2-2.12.0-4.1 gtk2-2.8.10-50 medium: key-file I did not start gnucash via console, so I cannot give you the result. Strange thing: The transaction gets commited even though gnucash crashes and I was not asked for my PIN. Only gnucash does not store a transaction as I see today syncing my account.
Ah, I forgot to mention: There are no umlauts at all in the respective transaction.
Thanks for the info. *sigh* The aqbanking version is different from the gnucash-de report, so it is very likely not related to the aqbanking itself, and also there are no known issues with this up-to-date aqbanking/gwenhywfar versions. The glib2 version is very new, though -- did you update this yourself? The stock suse-10.1 only has glib2-2.8.5. It would be interesting to hear whether this crash occurs also with the older glib2-2.8.x, although that's probably too difficult for you to check. As for comment#2, "The transaction gets commited": This happens because aqbanking stores the transaction in ~/.banking/backends/aqhbci/... before this crash occurs. It is being committed to the bank server upon your next HBCI action, for example your next transaction statement download. As for the console messages: You said this crash occurs every time (is this true?). Could you try to have this crash one more time, but start gnucash from the command line? Simply type "gnucash" on a Terminal. Then, right before you click "Ok" in the "Buchen" ("Transfer") dialog, please check which messages have already been shown. Then click "Ok" which will crash. Then check again which messages are newly added at the console, and then please post them here. The other bugreport showed one particular failed assertion on the console: https://lists.gnucash.org/pipermail/gnucash-de/2006-August/004215.html
I did as you told me. That's the result: (gnucash:6302): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() Gtk-ERROR **: file gtktreemodelsort.c: line 2419 (gtk_tree_model_sort_clear_cache_helper): assertion failed: (level != NULL) aborting... Seems to be the same as next door.
Created attachment 70955 [details] [review] patch that maybe fixes this problem If the error is due to non-ascii characters from aqbanking's ~/.banking/settings.conf *or* ~/.banking/backends/aqhbci/settings.conf, then this patch will remove all invalid utf8 characters from the respective data.
*sigh* After some very long email discussion, we've pinned down the cause of the "Pango-WARNING" and fixed it (it was probably due to some aqbanking non-utf8 string), but unfortunately the failed assertion in gtk_tree_model_sort_clear_cache_helper() still occurs and gnucash crashes. Again the version numbers in question: Suse 10.1; aqbanking-2.2.0-0.oc2pus.1, gwenhywfar-2.3.1-0.oc2pus.1 (both the newest); glib2-2.12.0-4.1 (probably manually updated), gtk2-2.8.10-50, (stock suse10.1 version); gnucash-2.0.1. The other bugreport on gnucash-de has Debian, aqbanking 2.0.0, gwenhywfar 2.3.0, glib2 2.10.3-3, gtk2 2.8.18-1, gnucash 2.0.0 and there the crash also occurs although the Pango-WARNING has been fixed. In this report, Johannes was able to provide a more detailed back trace with various variables being printed: Gtk-ERROR **: file gtktreemodelsort.c: line 2419 (gtk_tree_model_sort_clear_cache_helper): assertion failed: (level != NULL) aborting... Program received signal SIGABRT, Aborted.
+ Trace 70504
Thread NaN (LWP 13146)
$4 = {dialog = 0x86a2978, amount_edit = 0x8496258, date_entry = 0x863c8d0, num_entry = 0x85c96a0, description_entry = 0x85c9740, memo_entry = 0x865c030, conv_forward = 0x865ecf0, conv_reverse = 0x865ee00, from_window = 0x863d400, from_tree_view = 0x84e3340, from_commodity = 0x84d4250, to_window = 0x863d388, to_tree_view = 0x84e3258, to_commodity = 0x84d4250, qf = 0x87a0400, quickfill = XFER_DIALOG_FROM, desc_start_selection = 0, desc_end_selection = 0, desc_cursor_position = 0, desc_didquickfill = 0, transferinfo_label = 0x861bf00, from_transfer_label = 0x865b338, to_transfer_label = 0x865b5e0, from_currency_label = 0x865b448, to_currency_label = 0x865e828, from_show_button = 0x81911e0, to_show_button = 0x8191258, curr_xfer_table = 0x865a4e0, price_edit = 0x8496320, to_amount_edit = 0x84963e8, price_radio = 0x81912d0, amount_radio = 0x8191348, tips = 0x86aac18, book = 0x84d4680, pricedb = 0x8499180, exch_rate = 0x0, transaction_cb = 0xb6830280 <gnc_hbci_dialog_xfer_cb>, transaction_user_data = 0x835d900}
Created attachment 70969 [details] Full back trace from comment#7
Since the problem also occurs in the "manual" transaction dialog it seems not to be related to aqbanking. I just tried the most recent SVN version which still has got this error.
With the help of Christian I found out a new fact: The crash only happens if I try to assign the transaction to categories such that the money goes from an activa account to an expenses/income account (don't know the correct translations for the german Erträge/Aufwendungen). Maybe that could help to track down the cause.
Re comment#10: Steps to reproduce: 1. Click Actions -> Transfer... 2. At the left side account selection, select an Asset account, e.g. Assets:Checking Account 3. At the right side account selection, activate the checkbox "show income/expense", then select an Expense account 4. Insert some values for Description and value 5. Press "ok". Crash should occur with the above back trace.
I can't reproduce this with the instructions in comment #11. I'm thinking this might have been fixed by r14709. Unless I hear otherwise, I plan on resolving this bug as fixed. NEEDINFO for now.
The bug still occurs in release r14933. Maybe it depends on the translation used by me (german). Christian, do you know more about that possibility?
No, I don't think this depends on the translation... but you can check for yourself: LANG=C gnucash and see whether it still crashes (I'd guess it does). Eventually we're stuck here because we cannot reproduce the problem. Maybe this all goes away when you update to gtk-2.10.x ?
You're right, Christian, it also happens with LANG=C. At the moment there is no gtk-2.10 available for openSuSE 10.1. I'll see what happens with 10.2 if my new laptop arrives. ;)
bug#364946 looks similarly weird and related to the gtk_tree_model as well.
Any news WRT GTK+ 2.10.x?
GTK+ 2.10.6-13: Same problem: Gtk-ERROR **: file gtktreemodelsort.c: line 2293 (gtk_tree_model_sort_clear_cache_helper): assertion failed: (level != NULL) aborting...
*** Bug 402524 has been marked as a duplicate of this bug. ***
If these gtk_tree_model_sort issues are really related to accessibility, then the version numbers of gail and atk are probably much more important. On a stock opensuse10.2 we have gail-1.9.3-17, atk-1.12.3-15, gtk2-2.10.6-24.2 and this crash does not occur.
The main bug#364946 now has an easy testcase to reproduce it, so this bug will be soon closed as a duplicate of the other one, which in turn will hopefully be fixed soon.
The soon for this bug is now :) Thanks for the good stack! *** This bug has been marked as a duplicate of 364946 ***
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=351371. Please update any external references or bookmarks.