[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Bug#192101: We need gnucash in stable



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

Attachment: signature.asc
Description: Digital signature


Reply to: