Question

I recently updated the Android SDK on the Jenkins machine to rev15 from rev13, and had to redo some of our custom build stuff in build.xml to fit in with the changes made in rev14. I worked this out on my workstation, and checked it in expecting everything to be peachy. Instead, the build fails with the following error:

-obfuscate:

-dex:
      [dex] Converting compiled files and external libraries into /export/home/hudson/jobs/path/to/the/file/classes.dex...
       [dx] 
       [dx] UNEXPECTED TOP-LEVEL EXCEPTION:
       [dx] java.util.zip.ZipException: error in opening zip file
       [dx]     at java.util.zip.ZipFile.open(Native Method)    
       [dx]     at java.util.zip.ZipFile.<init>(ZipFile.java:127)
       [dx]     at java.util.zip.ZipFile.<init>(ZipFile.java:143)
       [dx]     at com.android.dx.cf.direct.ClassPathOpener.processArchive(ClassPathOpener.java:206)
       [dx]     at com.android.dx.cf.direct.ClassPathOpener.processOne(ClassPathOpener.java:131)
       [dx]     at com.android.dx.cf.direct.ClassPathOpener.process(ClassPathOpener.java:109)
       [dx]     at com.android.dx.command.dexer.Main.processOne(Main.java:418)
       [dx]     at com.android.dx.command.dexer.Main.processAllFiles(Main.java:329)
       [dx]     at com.android.dx.command.dexer.Main.run(Main.java:206)
       [dx]     at com.android.dx.command.dexer.Main.main(Main.java:174)
       [dx]     at com.android.dx.command.Main.main(Main.java:95)
       [dx] 1 error; aborting

BUILD FAILED
/opt/android-sdk-linux/tools/ant/build.xml:729: The following error occurred while executing this line:
/opt/android-sdk-linux/tools/ant/build.xml:731: The following error occurred while executing this line:
/opt/android-sdk-linux/tools/ant/build.xml:743: The following error occurred while executing this line:
/opt/android-sdk-linux/tools/ant/build.xml:249: null returned: 1

I can successfully build the project by running ant as the Jenkins user directly in the Jenkins workspace directory with the same Android SDK, Ant, and JDK that Jenkins is using. I even cut-and-paste the execution line out of the Jenkins log to ensure that all the knobs and switches are set the same. So it’s something about how Jenkins is running the build that’s the problem.

I had Jenkins dump the environment as a “shell exec” step of the build, and I see that the LD_LIBRARY_PATH variable is set.

LD_LIBRARY_PATH=/u0/jdk1.6.0_29/jre/lib/i386/server:/u0/jdk1.6.0_29/jre/lib/i386:/u0/jdk1.6.0_29/jre/../lib/i386

I set this value in my terminal while running the build from the shell, and it fails in the same way as when Jenkins runs things. Ah-ha!

The problem is that I can’t figure out how to keep the LD_LIBRARY_PATH variable from getting set, or pointing at something that won’t cause this problem. It’s not set in the Jenkins user’s environment, and I can’t find anything that might be a reference to it in the Jenkins configuration. The value it set did change when I installed an updated JDK and updated the JAVA value in /etc/defaults/jenkins so it’s clearly related, but unfortunately, the behavior didn’t improve any.

I’m out of ideas. Any help?

Answer 1

The problem turned out to be that due to some configuration chicanery involved in making use of the Jenkins matrix build feature (a very nice feature, by the way) that a library was not putting its classes.jar file where the parent project was expecting to find it, causing the reported error. That was basically a “file not found” that doesn’t say so. We’re still not sure what (if anything?) the LD_LIBRARY_PATH had to do with it.

My colleague tweaked the build.xml file for the main project and the library to more forcefully agree on where output files are going to end up, and now everything works again, much to our relief.