Hello, After digging to see why gnucash fails the tests (as I use it daily and wouldn't like to see it go away...), I found these:
On Sat, Sep 27, 2003 at 04:03:19PM -0500, Steve Langasek wrote: > Quite so. Red Hat is a build environment where 'make check' succeeds, > though the bug is latent. Debian i386 is a build environment where > 'make check' succeeds, though the bug is latent. On other Debian > architectures, the bug causes a build failure, due to differences in the > output of the PRNG. Eliminating the randomness, it's probably possible > to construct valid test input that fails on all platforms, Red Hat > included. So either the test itself is wrong for allowing these input > values, or there's a bug in gnucash. Playing with the random generator has shown this to be true. Introducing additional calls to it (i.e. extracting more values, at random places) has generated both successfull runs (with 400 tests) and failures after 130 tests. > > Note that at any point, this bug could be effectively downgraded by > removing the call to 'make check' from debian/rules, if it was decided > that the impact of this bug on the program's viability is not > significant. That's a decision for the maintainer to make, however; > it's certainly justified to be wary of *any* failures where financial > software is concerned. The test that fails is doing the following: for N number of times create a random query of up to 4 terms, which are (randomly) combined using operators from the set QUERY_AND, QUERY_OR, QUERY_NAND, QUERY_NOR, QUERY_XOR. transform the query to another format and back, and check to see that we have the same query. Now the 244 test (in the original setup) that fails has 4 terms combined such that in the end the query, broken down in its internal form has more than 5000 sub-terms. Other tests that fail also have an big number of sub-terms (>4000, etc.). However, there were also queries with 4 terms, but which broken down amounted to a small number of subterms, that succeeded. Reducing the maximum number of terms in the test from 4 to 3 has allowed me to run > 120,000 iterations of the test (at which point I ran out of memory, the test program was using 400MB). I'd say that if we are not making searches in gnucash using 4 or more terms combined strangely, and gnucash itself does not construct such queries, it *could* be ok - e.g. no data or functionality loss. However, this is clearly a bug in gnucash - they should either fix the transformations of queries with big numbers or limit the maximum number of terms allowed. Hopefully this info will be of use to someone. Regards, Iustin Pop
signature.asc
Description: Digital signature
