Corrupted zip file detected in javac

[Eric Zundel Ayers]

I’ve gotten two reports of this problem in the last week or so and was wondering Has anyone seen this kind of issue before?

We are using 1.1.0-pre9 with the two ANTLR patches that just got landed into 1.1.0

                   [1/3] Compiling 33 zinc sources in 1 target (siren/src/main/java:lib).[error] /Users/zundel/Development/java/siren/src/main/java/com/squareup/siren/server/csi/CsiModule.java:10: cannot access com.squareup.monitoring.graphite.GraphiteMetricsForwarder
                       [error]   bad class file: /Users/zundel/Development/java/.pants.d/compile/zinc/252d64521cf9/monitoring.src.main.java.lib/current/z.jar(com/squareup/monitoring/graphite/GraphiteMetricsForwarder.class)
                       [error]     unable to access file: corrupted zip file
                       [error]     Please remove or make sure it appears in the correct subdirectory of the classpath.
                       [error] import com.squareup.monitoring.graphite.GraphiteMetricsForwarder;
                       [error] Compile failed at Aug 28, 2016 11:26:27 AM [4.029s]

                   compile(siren/src/main/java:lib) failed: Zinc compile failed.
FAILURE: Compilation failure: Failed jobs: compile(siren/src/main/java:lib)

07:26:27 00:16   [complete]
               FAILURE

I’ve not heard of reports of this at Square before. Our CI builder seems to be running just fine. This problem occurs when I try to re-use the artifacts created in CI on our laptops.

Bumping cache_key_gen_version in pants.ini works around the problem.

​

[Eric Zundel Ayers]

I strongly suspect one of these changes:

https://rbcommons.com/s/twitter/r/4152/  - Refactor classpath consolidation into a separate task.

https://rbcommons.com/s/twitter/r/4184/ -  Performance fix for consolidated class path

This problem cropped up after we moved from 1.1.0-rc9 to the latest version.

[Stu Hood]

It looks to be related to usage of:

$ ./pants help-advanced compile.zinc | grep -A2 'compile-zinc-use-classpath-jars'

--[no-]compile-zinc-use-classpath-jars (default: False)

    Use jar files on the compile_classpath. Note: Using this option degrades

    incremental compile between targets.

--

@stuhood

[Eric Zundel Ayers]

Yes, we use that flag.  

[Mateo Rodriguez]

Is the bug triggering during a 'bundle' call? I believe the consolidate_classpath task is still tightly coupled to bundle and should only run during that goal.

That task jars up any loose files left on the classpath during bundle. If that lib in the trace is a Square java_library I would have thought it would be a jar already.

Had that task run earlier in that trace?

[Nick Howard]

I'm not sure how the consolidate classpath changes would affect the `z.jar`s. Consolidate classpath creates jars with names like `output-0.jar` in the consolidate classpath tasks' workdir.

Have you looked at the malformed z.jar to see what kind of problem it has?

--

Nick

[Eric Zundel Ayers]

No, its not associated with a bundle. The jar file in question is getting bundled up on our CI machine and written into the cache. It continues to run fine from other machines in the cache (served by NFS). We also serve up a copy of the file over HTTP,  I should compare the two copies to make sure it isn't getting corrupted there for some reason because our CI builder can use it just fine.  

Thanks for the suggestions