Created attachment 373379 [details] Stacktrace when trying to open Net Worth Linechart I use Finance::Quote to obtain stock prices. The prices that end up in the price database tend to be quite accurate. E.g. bad_value = 268 + 5055320467865/8425534113108 This is a number that causes trouble in Gnucash: * 'Net worth linechart' crashes with: Throw to key `numerical-overflow' with args `("/" "Numerical overflow" #f #f)' more details in an attachment. * Net Assets field in 'Accounts' tab fails to show any value, it just shows: Net Assets: zł (zł is a polish currency) Repro: 1. Add 1 unit of stock X 2. Set price of X in price editor to bad_value 3.1 Look at 'Accounts tab OR 3.2 Open 'Net worth linechart' and set 'price source' to 'nearest in time' so that bad_value is used for calculations which results in a crash.
Thank you for your bug report! This is likely to be bug 797233 which is fixed in 3.6 onwards. Please try a newer build.
I updated Gnucash to 3.6 but it still doesn't work. Note that the bug happens only when price for X is set to bad_value in dollars (than it's converted to zł). The current value of USD/PLN in my price database is 3.9823.
The pricedb entry for 268 + 5055320467865/8425534113108 is unreasonably precise; best modify the entry to 268.60 instead. I don't think there's mechanism to scrub these numbers.
Well, that's what I end up doing but manual fixing is a lot of toil. Also, that defeats the purpose of automatic price lookup by Finance::Quote. IMHO it doesn't sound too good if GUI allows you to enter values which end up crashing the backend? A possible workaround would be to change the precision of values looked up by Finance::Quote but I'm not aware of such option.
Chris, regardless of the precision there's an unhandled overflow exception in GncNumeric. We need to address that, all exceptions must be handled by C++ because an unhandled exception calls exit(). The problem that got fixed was the creation of prices with max-precision fractions from Finance::Quote, but it's still conceivable that such a price could be created with a normal transaction, especially in crypto currencies or mutual funds with 10^-9 SCUs. In light of that perhaps the no-round multiplication in pricedb's convert_balance is unwise.
