GNOME Bugzilla – Bug 478106
crash in GnuCash Finance Management: Transfer funds, exchange...
Last modified: 2018-06-29 21:50:01 UTC
What were you doing when the application crashed? Transfer funds, exchange rate=1 Distribution: Debian lenny/sid Gnome Release: 2.18.3 2007-07-03 (Debian) BugBuddy Version: 2.18.1 System: Linux 2.6.21.1-elio2 #1 SMP Sun Jun 3 23:08:27 EEST 2007 i686 X Vendor: The X.Org Foundation X Vendor Release: 10300000 Selinux: No Accessibility: Disabled GTK+ Theme: Nuvola Icon Theme: Nuvola Memory status: size: 69554176 vsize: 69554176 resident: 40128512 share: 15753216 rss: 40128512 rss_rlim: 4294967295 CPU usage: start_time: 1190136585 rtime: 3026 utime: 2917 stime: 109 cutime:17 cstime: 0 timeout: 0 it_real_value: 0 frequency: 100 Backtrace was generated from '/opt/gnucash/bin/gnucash' Using host libthread_db library "/lib/i686/cmov/libthread_db.so.1". [Thread debugging using libthread_db enabled] [New Thread -1231419728 (LWP 6033)] [New Thread -1253090416 (LWP 6043)] 0xffffe410 in __kernel_vsyscall ()
+ Trace 163802
Thread 1 (Thread -1231419728 (LWP 6033))
----------- .xsession-errors --------------------- ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 ** Message: drive = 0 ** Message: volume = 0 "/opt/gnucash/bin/gnucash": not in executable format: File format not recognized --------------------------------------------------
That is a really good stacktrace! Is this crash reproducible for you? If it is, may you attach a minimal example or step-by-step guide so that we can reproduce it? We wondered why `to' in frame #5 is NULL, coming directly from xaccTransGetCurrency. Where does that transaction come from? Did you enter it manually, is it qif- or hbci-imported? Did you log-replay it? Thanks in advance!
I am sorry! I cannot reproduce this. I was entering some expense in a split, and for some reason I found myself in the exchange rate dialog, although I thought that should not have been the case (but this could have been my wrong feeling). I do not remember exactly what was the sequence, and the straight case I have tried do not reproduce the error.
Doesn't this strack trace mean we should add some argument sanity checking into gnc_xfer_dialog_response_cb() ?
Is this still a problem?
I can easily add a one-liner sanity check to the dialog to prevent the crash. I'll go ahead and commit that. I wouldn't know how to reproduce the actual problem though (if it is still possible), which is that somehow the transaction didn't have a commodity.
Committed as r18065. Setting target to 2.3.0. As far as how to reproduce it, I can tell from the stack trace that the user was editing an existing transaction rather than a brand new one (in frame 9, trans != blank_trans). The user was on the "blank" row in that transaction (in frame 9, split=0x0). This is the row where you would enter an additional split. Changes had been made to the row, otherwise gnc_split_register_handle_exchange() would not be called. So the user must have entered something. The user's final action was to press Enter on the row. Somehow at that point the transaction did not have a currency. I have no idea how to reproduce that or whether it was even an existing problem with the transaction before it was even edited in the register. At least the crash is prevented.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=478106. Please update any external references or bookmarks.