Bug#738789: libhamcrest-java: FTBFS: bad class file: hamcrest-core-1.3.jar(org/hamcrest/Description.class)

[tony mancill]

On 03/25/2014 04:07 PM, Emmanuel Bourg wrote:
> This issue is really intriguing. When the build fails
> hamcrest-core-1.3.jar is not corrupted (verified with zip --test) and
> the compiled Description.class file is always the same (the md5sum is
> constant in all cases).
> 
> The random aspect of this bug leads me to think it's a kind of race
> condition between the part of the build that writes the jar and the part
> that reads it, but everything is executed sequentially so I'm not sure
> how this could actually happen.
> 
> On Googling the error message I found this interesting bit in a python
> script used by Assembla to build Ant projects:
> 
> http://subversion.assembla.com/svn/sivanea/trunk/src/buildscripts/antmake.py
> 
> # Experience has shown that occasionally an ant build will cause an error
> # like the following:
> '''
> [javac] DellDXConnector.java:14: cannot access
> com.perfectsearchcorp.feed.Connector
> [javac] bad class file:
> com/perfectsearchcorp/feed/Connector.class(com/perfectsearchcorp/feed:Connector.class)
> [javac] unable to access file: corrupted zip file
> [javac] Please remove or make sure it appears in the correct
> subdirectory of the classpath.
> [javac] import com.perfectsearchcorp.feed.Connector;
> [javac]                                  ^
> '''
> # This error appears to be caused by a bug in how either ant or java itself
> # manages file handles for zip files on some platforms -- I think java is
> # sometimes opening the file for read before the handle for write is fully
> # released and flushed.
> 
> 
> So it may be either an Ant bug (but I reviewed the jar task code and the
> files seem to be properly closed) or a JVM bug on Linux.
> 
> A simple workaround would be to mount the directory containing the
> hamcrest-core classes into the classpath instead of using the generated jar.

Just for curiosity (and because it recently came up with another
package, although I don't currently remember which one), I tried
building in a single processor, single core virtual machine, and wasn't
able to observe a failure in 25 consecutive builds.

For grins, I went back and renabled all of the tests for c3p0, which was
consistently hanging during builds, and have been able to build it three
times so far without any hangs.

Both of these lend support to the hypothesis of this being a race - more
specifically, a race that can occur when the JDK/JVM takes advantage of
multiple threads of execution.  (Or as Emmanuel said, a JVM bug on
Linux.)  Hmmm....

tony


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 880 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-java-maintainers/attachments/20140325/bf3ba07a/attachment.sig>