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

Previous Next

Full log

View this message in rfc822 format

From: help-debbugs <at> gnu.org (GNU bug Tracking System)
To: Björn Höfling
 <bjoern.hoefling <at> bjoernhoefling.de>
Cc: tracker <at> debbugs.gnu.org
Subject: bug#46780: closed (java-snappy: Test failure on ci.guix.gnu.org)
Date: Sat, 27 Feb 2021 23:30:02 +0000

[Message part 1 (text/plain, inline)]

Your message dated Sun, 28 Feb 2021 00:29:27 +0100
with message-id <20210228002927.0d14cc92 <at> alma-ubu>
and subject line Re: bug#46780: java-snappy: Test failure on ci.guix.gnu.org
has caused the debbugs.gnu.org bug report #46780,
regarding java-snappy: Test failure on ci.guix.gnu.org
to be marked as done.

(If you believe you have received this mail in error, please contact
help-debbugs <at> gnu.org.)


-- 
46780: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=46780
GNU Bug Tracking System
Contact help-debbugs <at> gnu.org with problems

[Message part 2 (message/rfc822, inline)]

From: Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>
To: <bug-guix <at> gnu.org>
Subject: java-snappy: Test failure on ci.guix.gnu.org
Date: Thu, 25 Feb 2021 21:52:45 +0100

[Message part 3 (text/plain, inline)]

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

[Message part 4 (application/pgp-signature, inline)]

[Message part 5 (message/rfc822, inline)]

From: Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de>
To: zimoun <zimon.toutoune <at> gmail.com>
Cc: 46780-done <at> debbugs.gnu.org
Subject: Re: bug#46780: java-snappy: Test failure on ci.guix.gnu.org
Date: Sun, 28 Feb 2021 00:29:27 +0100

[Message part 6 (text/plain, inline)]

On Sat, 27 Feb 2021 14:58:47 +0100
Björn Höfling <bjoern.hoefling <at> bjoernhoefling.de> wrote:

> On Fri, 26 Feb 2021 23:08:42 +0100
> zimoun <zimon.toutoune <at> gmail.com> wrote:
> 
> > What about adding a phase just before the test?  For example in this
> > build.xml file fix the max memory to 20G if it is greater.  

Thanks for the idea.

I first tested it with maxmemory="1M" and this fails with a OOM-error
on my pc, thus I knew this setting is really honored.

Now I set it to 2G and sent a patch under commit:

23dcf4339d1dc102b2c509a151734f4caff793bd

And it works now on Berlin:

https://ci.guix.gnu.org/build/361691/details

Closing.

Björn

PS: While looking at the Cuirass logs, I remembered the other
memory-problem we head, it was with java-kafka-clients:

https://ci.guix.gnu.org/build/361612/details
https://debbugs.gnu.org/cgi/bugreport.cgi?bug=40554

At first sight, we could try the same trick here. I will investigate
this in the next week, if not someone else is quicker.

[Message part 7 (application/pgp-signature, inline)]

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.