After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 695240 - mortgage wizard empty table
mortgage wizard empty table
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Scheduled Transactions
2.4.x
Other Linux
: Normal normal
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
Depends on:
Blocks:
 
 
Reported: 2013-03-05 19:06 UTC by Anton Orel
Modified: 2018-06-29 23:14 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
example db related to issue #695240 (79.00 KB, application/x-gnucash)
2013-05-31 14:30 UTC, Anton Orel
Details

Description Anton Orel 2013-03-05 19:06:07 UTC
After I have completed all screens at mortgage wizard the last screen shows empty table.

And additional: right after focus leave transaction formulas in repayments screen an exception rised with something about parsing error.

After a few days of googling and my hair left my head the solution was found.

It's setting env variable LC_NUMERIC=C. I don't now reason for this but it works.
Comment 1 Anton Orel 2013-03-05 19:13:34 UTC
Linux salma 3.2.0-37-generic #58-Ubuntu SMP Thu Jan 24 15:28:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

locale
LANG=ru_RU.UTF-8
LANGUAGE=ru_RU
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=
Comment 2 Anton Orel 2013-03-06 11:23:29 UTC
I hurried to mark it as resolved. There is other problem at the moment.
My existent db raise the exception "unable to save to database".
And I don't know what to do with this.

Any help apreciated. Thank you.
Comment 3 Geert Janssens 2013-03-11 19:08:28 UTC
Can you provide more details about your set up ?

- What database format are you using ? MySQL, Postgresql, Sqlite ?
- Is there anything in the trace file ? More details regarding this file can be found here http://wiki.gnucash.org/wiki/Tracefile
Comment 4 Anton Orel 2013-03-17 17:04:42 UTC
Ok. My system info:

$uname -a
Linux salma 3.2.0-37-generic #58-Ubuntu SMP Thu Jan 24 15:28:10 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

$locale
LANG=ru_RU.UTF-8
LANGUAGE=ru_RU
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

$./bin/gnucash --version
GnuCash 2.4.11
Сборка 2013-03-17 (r22264M)

compiled with:
./configure --prefix=$HOME/gnucash  --with-html-engine=webkit --enable-compile-warnings --enable-dbi  --disable-error-on-warning

make
make install


The trace file from run the programm to complete wizard setup (new SQLite db):

* 20:58:09  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 20:58:09  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed
* 20:58:09  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 20:58:09  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed
* 20:58:09  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 20:58:09  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed
* 20:58:17  WARN <LIBDBUSMENU-GLIB> Trying to remove a child that doesn't believe we're it's parent.
* 20:58:25  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 20:58:25  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 20:58:25  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 20:58:58  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 5,00 : 1000000,00 : 0 : 0 )
* 20:58:58  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 5,00 : 1000000,00 : 0 : 0 )
* 20:58:58  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 5,00 : 1000000,00 : 0 : 0 )
* 20:58:58  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 5,00 : 1000000,00 : 0 : 0 )
* 20:58:58  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 5,00 : 1000000,00 : 0 : 0 )
Comment 5 Geert Janssens 2013-05-17 20:09:25 UTC
Sorry for the late reply.

It seems GnuCash doesn't like the date format for your locale. Can you try to explicitly specify a date format different from locale in
Edit->Preferences->Date/Time

And then regenerate the mortgage ?

What is the date format you are using currently by the way ?
Comment 6 Anton Orel 2013-05-24 05:21:02 UTC
Sorry for late response I was in vacation.

The local format for russian locale is like as as europe for example "31.04.2013".
But there is no difference and the same issue when I change the date format in preferences to any other formats.

...
* 09:14:06  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 09:15:20  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 84,00 : 1000000,00 : 0 : 0 )
* 09:15:20  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 84,00 : 1000000,00 : 0 : 0 )
* 09:15:20  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 84,00 : 1000000,00 : 0 : 0 )
* 09:15:20  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15500 / 12,00 : 84,00 : 1000000,00 : 0 : 0 )
...

Any thoughts? Thank you.
Comment 7 Geert Janssens 2013-05-24 08:04:44 UTC
Well, I stopped at the first error in comment 4:
* 20:58:09  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 20:58:09  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian
(julian_day)' failed

Those are date related. You didn't attach a complete trace file in comment 6 so I can't really tell if this specific problem still exists or not if you change to a different date format.

Then there is a second error:
* 09:15:20  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error
at ,15500 / 12,00 : 84,00 : 1000000,00 : 0 : 0 )

This one complains that a formula for your mortgage is invalid.

From your description it still isn't fully clear to me how you got into this situation. So I'll ask for some more details:
* In your original message you write that setting LC_NUMERIC=C fixes the problem. But in any of your subsequent locale details LC_NUMERIC is always set to ru_RU.UTF-8. The second error in your trace file is clearly about numeric formats, so this matters. When was LC_NUMERIC set to what while you were testing ?

To make further testing and debugging easier, can you please attach a small example file that results in the above errors in the trace file ? You will probably want to create a new file and use the mortgage wizard in there.

And let me know what LC_NUMERIC was set to when creating the file and when you get the errors. The same for date format ?

Thank you.
Comment 8 Anton Orel 2013-05-24 09:03:19 UTC
1. Issue related to dateformat errors in tracefile

I have run mortgage wizard on existent db with changed date format in preferences to english format:

$tailf /tmp/gnucash.trace 
* 12:21:39  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=21 tm_year=-599 tm_min=30 tm_sec=0 tm_isdst=-1 for string=1301-04-12 21:30:00
* 12:21:39  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime 
* 12:21:39  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=21 tm_year=-599 tm_min=30 tm_sec=0 tm_isdst=-1 for string=1301-04-12 21:30:00
* 12:21:39  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime 
* 12:21:39  WARN <qof.engine> [gnc_iso8601_to_timespec_gmt()]  mktime failed to handle daylight saving: tm_hour=21 tm_year=-599 tm_min=30 tm_sec=0 tm_isdst=-1 for string=1301-04-12 21:30:00
* 12:21:39  CRIT <qof.engine> [gnc_iso8601_to_timespec_gmt()]  unable to recover from buggy mktime 
* 12:21:50  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:21:50  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:21:50  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:22:25  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15150 / 12,00 : 84,00 : 100000,00 : 0 : 0 )
* 12:22:25  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15150 / 12,00 : 84,00 : 100000,00 : 0 : 0 )
...same output here....
* 12:22:30  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 12:22:30  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed
* 12:22:30  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 12:22:30  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed


2. Issue related to mortgage wizard incorrect work

I have created new db with locale:

$locale
LANG=ru_RU.UTF-8
LANGUAGE=ru_RU
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=

And the tracefile:

* 12:28:10  CRIT <GLib> g_hash_table_foreach: assertion `version == hash_table->version' failed
* 12:28:10  CRIT <GLib> g_hash_table_foreach: assertion `version == hash_table->version' failed
* 12:28:10  CRIT <GLib> g_hash_table_foreach: assertion `version == hash_table->version' failed
* 12:28:10  CRIT <GLib> g_hash_table_foreach: assertion `version == hash_table->version' failed
* 12:29:09  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:29:09  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:29:09  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:30:24  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15000 / 12,00 : 12,00 : 100,00 : 0 : 0 )
* 12:30:24  CRIT <gnc.engine.sx> [ld_rev_recalc_schedule()] pmt Parsing error at ,15000 / 12,00 : 12,00 : 100,00 : 0 : 0 )
...same output here...


Starting gnucash with changed LC_NUMERIC=C on NEW and EXISTENT db fixes problem with mortgage wizard but date format errors is still exist anyway:

* 12:44:09  WARN <gnc.app-utils.sx> instance not found!
* 12:44:11  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 12:44:11  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed
* 12:44:16  WARN <LIBDBUSMENU-GLIB> Trying to remove a child that doesn't believe we're it's parent.
* 12:44:20  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:44:20  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:44:20  WARN <Gtk> GtkSpinButton: setting an adjustment with non-zero page size is deprecated
* 12:45:42  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 12:45:42  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed
* 12:45:42  CRIT <GLib> g_date_get_julian: assertion `g_date_valid (d)' failed
* 12:45:42  CRIT <GLib> g_date_new_julian: assertion `g_date_valid_julian (julian_day)' failed


I have noticed that with my default locale in mortgage wizard interest rate uses comma but when LC_NUMERIC is changed to C it uses dot as separator. Maybe is it the main issue?
Comment 9 Geert Janssens 2013-05-31 13:36:39 UTC
The different decimal separator is certainly one problem that surfaces here. The second one is list of date errors which you consistently seem to get.

Can you attach the sqlite db you created for this test ? That way I can play with it locally as well.
Comment 10 Anton Orel 2013-05-31 14:30:38 UTC
Created attachment 245745 [details]
example db related to issue #695240
Comment 11 Geert Janssens 2014-09-18 14:53:31 UTC
After a long hiatus I am revisiting this bug.

From my current investigation it looks like the parsing errors are due to the fact that the Russian locale is using two different number formats:
Monetary numbers are formatted as 1 000.00
While other numbers are formatted as 1 000,00

This is a situation that GnuCash was not designed for. So before I go rewriting all this: is it indeed correct that these number formats are different in the Russian locale or is this a locale bug ?
Comment 12 Geert Janssens 2014-09-21 21:09:48 UTC
Actually, I have rewritten the relevant code in GnuCash anyway. If one part of the code assumes the monetary format is used, other parts should supply the information using monetary format. That is regardless of whether or not the monetary and numeric format are different or not.

So this bug will be fixed in the upcoming 2.6.4 release.
Comment 13 Anton Orel 2014-09-22 05:10:42 UTC
(In reply to comment #12)
> So this bug will be fixed in the upcoming 2.6.4 release.

Glad to hear. Thank you for the great product.
Comment 14 Geert Janssens 2014-09-22 11:17:31 UTC
Anton, just to satisfy my curiosity. Can you tell me how numbers are normally formatted in Russian ?

Do you use a different notation for ordinary numbers (such as sizes, weights, ...) as for displaying money ?
Comment 15 Anton Orel 2014-09-22 16:33:00 UTC
(In reply to comment #14)
> Anton, just to satisfy my curiosity. Can you tell me how numbers are normally
> formatted in Russian ?
> 
> Do you use a different notation for ordinary numbers (such as sizes, weights,
> ...) as for displaying money ?

Have a look at file below. It's russian i18n for rails.
https://github.com/yaroslav/russian/blob/master/lib/russian/locale/actionview.yml

Nothing a special. The numbers have comma as separator, but currency has dot. Delimiter is space for thousands.

I hope it helps to clarify.
Comment 16 Geert Janssens 2014-09-22 16:59:45 UTC
Yes. Thanks.

This is the first language I have encountered that uses different separators for numbers and currencies. Also note that on my Windows XP test box this is not so. Windows XP thinks both use a comma. Perhaps this was changed more recently. Anyway just a curiosity.
Comment 17 John Ralls 2017-09-24 22:49:43 UTC
Reassign version to 2.4.x so that individual 2.4 versions can be retired.
Comment 18 John Ralls 2018-06-29 23:14:04 UTC
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=695240. Please update any external references or bookmarks.