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. >>> >> >> >
