Excellent! I'll look forward to build scripts with that fixed. I got
tired of failed builds during my recent debug activity - with logging
suppressing the problem I was dependent on editing in System.err.printf
calls and rebuilding.
Patricia
On 9/27/2010 3:40 AM, Jonathan Costers wrote:
I think I identified the cause of the issue:
PreferredListgen, ClassDep and JarWrapper classes are executed during the
build, but the<java> task does not have the attribute "fork" set to "true".
The Ant documentation for<java> mentions that sometimes strange things can
happen without using fork=true ... So they recommend setting it if that
happens.
I tried doing that over the weekend, and let the build run for 200
consecutive times, using a bash script with a for loop.
I didn't see a single VM crash anymore.
2010/9/25 Jonathan Costers<[email protected]>
2010/9/25 Patricia Shanahan<[email protected]>
On 9/25/2010 6:15 AM, Jonathan Costers wrote:
Not sure if I follow you ... Debug the VM?
The crash report clearly shows what is causing the VM to crash, or am I
missing something? :-)
I think what you may be missing is the wide range of different backgrounds
of River developers. What is immediately clear to you is not necessarily
clear to me, probably because you know some things, or have experience, that
I lack.
Please state your conclusions from the crash report.
My apologies ..
I thought the snippet I pasted in my previous email explained, I'm sorry.
My conclusion is that the VM crash for which you posted the report is
happening during execution of the JarWrapper class, which is used during the
build, for creating the tools wrapper jars (classdep.jar,
preferredlistgen.jar, etc.).
*
C [libc.so.6+0x1106ef]
C [libzip.so+0x4578] ZIP_GetEntry+0xc8
C [libzip.so+0x361f] Java_java_util_zip_ZipFile_getEntry+0xff
J java.util.zip.ZipFile.getEntry(JLjava/lang/String;Z)J
J
java.util.zip.ZipFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
J
java.util.jar.JarFile.getEntry(Ljava/lang/String;)Ljava/util/zip/ZipEntry;
j
java.util.jar.JarFile.getJarEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry;+2
j java.util.jar.JarFile.getManEntry()Ljava/util/jar/JarEntry;+11
j
java.util.jar.JarFile.getManifestFromReference()Ljava/util/jar/Manifest;+27
j java.util.jar.JarFile.getManifest()Ljava/util/jar/Manifest;+1
------
j com.sun.jini.tool.JarWrapper.
getMainClass(Ljava/util/jar/JarFile;)Ljava/lang/String;+1
j
com.sun.jini.tool.JarWrapper.process(Lcom/sun/jini/tool/JarWrapper$SourceJarURL;Lcom/sun/jini/tool/JarWrapper$PreferredListReader;)V+132
j com.sun.jini.tool.JarWrapper.wrap()V+19
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;Ljava/util/List;)V+17
j
com.sun.jini.tool.JarWrapper.wrap(Ljava/lang/String;Ljava/lang/String;[Ljava/lang/String;Ljava/lang/String;ZLjava/util/jar/Manifest;)V+9
j com.sun.jini.tool.JarWrapper.main([Ljava/lang/String;)V+379
*
------
The reason why it is crashing, I am not sure yet.
But it may be related to the way the Ant build is calling these classes.
I'm doing some testing right now to be sure
As far as I know, no sequence error ... the build works fine 95% of the
time.
And no, no assumptions abt state either.
I'm suspecting something in the JarWrapper code is causing this to happen
in
some cicumstances.
