bug-guix
[Top][All Lists]
Advanced

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

bug#46780: java-snappy: Test failure on ci.guix.gnu.org


From: Björn Höfling
Subject: bug#46780: java-snappy: Test failure on ci.guix.gnu.org
Date: Thu, 25 Feb 2021 21:52:45 +0100

java-snappy fails as a dependency of several Java evaluations, for
example:

http://ci.guix.gnu.org/eval/120281?status=failed
http://ci.guix.gnu.org/build/359649/log/raw

These failures exist only on ci.guix.gnu.org, but locally it build
perfectly, even with --rounds=100!

Why? Because our buildmachine has too much memory :-) [And I can
remember, we once had that for another package, I just can't remember
again which one].

What should we do about it? Just disable the test, or something more
complicated?

Analysis:

To analyze, I let it once fail with the -K switch to have the directory

/tmp/guix-build-java-snappy-1.1.7.drv-0/

available. Enter the environment with

$ guix environment java-snappy
$ cd /tmp/guix-build-java-snappy-1.1.7.drv-0/
$ source ./environment-variables
$ cd source
$ ant check
--> everything is fine.  

Then increase the memory used by junit: Edit the build.xml file, add a
huge "maxmemory" property like this :

<junit maxmemory="30G" printsummary="true" ...

Either have enough RAM or add some extra swap space, then run again:

$ ant check

It fails. The junit logs can be found in

src/test/test-reports/TEST-org.xerial.snappy.pool.CachingBufferPoolTest.txt

Testsuite: org.xerial.snappy.pool.CachingBufferPoolTest
Tests run: 4, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 7.363 sec

Testcase: testDirectByteBuffers took 0.002 sec
Testcase: testSoftReferences took 7.353 sec
        FAILED
count: 2048
junit.framework.AssertionFailedError: count: 2048
        at 
org.xerial.snappy.pool.CachingBufferPoolTest.testSoftReferences(Unknown
Source)

Testcase: testArrays took 0 sec
Testcase: testAdjustSize took 0 sec

If you look at the test case source code, it tries to allocate about
20GB and hopes that this fails. It just does not fail on huge machines...

Björn

Attachment: pgpiPqOL0v0pB.pgp
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]