GNOME Bugzilla – Bug 632346
FAILURE Accounts trees match test-dbi-stuff.c:62
Last modified: 2018-06-29 22:45:57 UTC
Created attachment 172534 [details] output of make check there are numerous assertion failures and CRIT messages SVN r19666 on Ubuntu 10.10
Created attachment 173243 [details] Untarred and egrepped on (Entering|CRIT) to show the "real" errors and where they happened, and make it readable in the browser. All but a few (along with a meg(!) of WARN messages) are in backend/xml/test.
The failure that Juergen refers to in the summary occurs in backend/dbi/test after the last CRIT message in the grepped check.log.
What version of libdbi is installed on your system ? The last CRIT errors: CRIT <gnc.engine> xaccSplitSetAmount: assertion `gnc_numeric_check(amt) == GNC_ERROR_OK' failed remind me of a compiler optimization bug that also happened with libdbi 0.8.3x on Mandriva 2010.0 and Fedora 12/13/14. See bug 611936 for more details. It was reported upstream in the Fedora bugtracker also, and has been fixed there.
libdbi 0.8.3 (In reply to comment #3) > What version of libdbi is installed on your system ? > > The last CRIT errors: > CRIT <gnc.engine> xaccSplitSetAmount: assertion `gnc_numeric_check(amt) == > GNC_ERROR_OK' failed > remind me of a compiler optimization bug that also happened with libdbi 0.8.3x > on Mandriva 2010.0 and Fedora 12/13/14. > > See bug 611936 for more details. It was reported upstream in the Fedora > bugtracker also, and has been fixed there.
Ok, in that case this bug is most likely the same issue as bug 611936. The best thing to do IMO is to report a bug in Ubuntu's bug tracker. You can add references to bug 611936 here in Gnome's bugzilla and to bug https://bugzilla.redhat.com/show_bug.cgi?id=629964 in Fedora's bugtracker to illustrate the problem and how it can be fixed. *** This bug has been marked as a duplicate of bug 611936 ***
It's only partly to do with 611936, I got mostly the same results on Debian. The xaccSplitSetAmount: assertion `gnc_numeric_check(amt) == GNC_ERROR_OK' failed messages are in fact the same as 611936, but that's only 4 errors out of 1.2 megabytes of output. Of the megabytes of errors in the xml backend, some were from actual problems in the code, and some from the test files not having been kept up to date. Those are mostly fixed, but there are a few left that stem from a misguided testing strategy. Those aren't so important, so they can stay for now. Aside from the gnc_numeric_check() errors, the CRIT errors in the dbi backend are from Phil adding a GDate column to the database and doing a g_return_if_fail if it's NULL, but then setting the value to NULL in the test file. Again, a low priority problem that can stay for now. I'm still seeing test errors in business/business-core, which I'll work on tomorrow, and I'd like the dbi backend test to be a lot quieter by default. It's darned hard to see the problems amongst the torrent of debug noise. Once I have the business-core errors sorted so that we have a clean make check, I'll downgrade this ticket to minor, but keep it open to remind us that there are still some testing issues that need to be cleaned up.
As of r19755 I'm getting a nice clean make test. All tests pass, and I've examined all of the "CRIT" and "WARN" messages and I'm satisfied that they're artifacts of testing, not real problems. That isn't going to address the problem with libdbi on Fedora, which, as noted in 611936, isn't a Gnucash problem. Could you please try it out and tell me if you have any errors other than the 4 gtk_numeric ones?
Created attachment 173863 [details] output of make check
Hi John, this looks much better now!! The remaining warnings I get now are of type: (process:28736): gnc.module-WARNING **: Module '../../../src/gnc-module/test/misc-mods/.libs/libgncmod_futuremodsys.so' requires newer module system - is this a problem of my system or of Gnucash? I still get the failure from the account tree mismatch, the numeric values are wrong. I don't understand how I could work around this. - I assume, this failure indicates, that some values would get lost, if I stored my data with the dbi-backend. Is this correct?
Neither, it's part of the test. There is no futuremodsys. Numeric values thing seems to be a Fedora-12/13 problem. Your best bet for now is probably to build libdbi from source, being sure to include -fno-fast-math in your CFLAGS. See Bug 611936 for our troubleshooting of this problem.
For clarity, the numeric values thing is resolved in Fedora 12,13 and 14. So it's no longer a Fedora problem. Apparently though other distros are hitting the same problem and have to fix it as well. (Note that Juergen indicates he is using Ubuntu 10.10 in his original report message).
As suggested in comment 5, bug "gnucash 2.3 with sqlite retrieves all numbers as zero" reported to Ubuntu bugtracker https://bugs.launchpad.net/ubuntu/+source/libdbi-drivers/+bug/673307
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=632346. Please update any external references or bookmarks.