> -----Original Message----- > From: Gavin McDonald [mailto:ga...@16degrees.com.au] > Sent: Friday, 22 February 2013 1:45 PM > To: builds@apache.org > Subject: RE: Apache build infrastructure or Oracle JVM problem: crash in > native JDK code > > I think we need to clarify some things here: > > 1. 'Jenkins Server' is generic, saying that the 'Jenkins Server' needs java > 7 > updating means nothing. > We have many Jenkins Slaves , some Linux, some Solaris., some windows, > freebsd, etc .. > Each of them has individual java versions installed. There is the system > default java and there are the many other different versions we install into > /home/jenkins/tools/java/* > > 2. The 'Jenkins Server' on which your build has been running mostly is the > 'Solaris1' slave machine. > > This 'Solaris1' slave does have an out-dated java 7 and I'll update it > shortly.
Ok, upgraded. Now solaris1 is as follows: bash-3.00# /home/hudson/tools/java/latest1.7/bin/java -version java version "1.7.0_15" Java(TM) SE Runtime Environment (build 1.7.0_15-b03) Java HotSpot(TM) Server VM (build 23.7-b01, mixed mode) HTH Gav... > > currently: > > bash-3.00$ /export/home/hudson/tools/java/latest1.7/bin/java -version > java version "1.7.0" > Java(TM) SE Runtime Environment (build 1.7.0-b147) Java HotSpot(TM) > Server VM (build 21.0-b17, mixed mode) > > 3. The many other 'jenkins slave' machines which you could have chosen to > run your builds on instead all have much more upto date versions. > > gmcdonald@juno:~$ /home/hudson/tools/java/latest1.7/bin/java -version > java version "1.7.0_04" > Java(TM) SE Runtime Environment (build 1.7.0_04-b20) Java HotSpot(TM) 64- > Bit Server VM (build 23.0-b21, mixed mode) > > etc.. > > Conclusion: Only one of our Jenkins slaves had a really old Java 7 and you > could simply choose any other slave that has more modern versions already > installed. (You can force this by tying to the 'ubuntu4' label for example) > > I'll let you know when 'solaris1' is updated if you prefer to continue with > that. > > HTH > > Gav... > > > > -----Original Message----- > > From: Martin Desruisseaux [mailto:martin.desruisse...@geomatys.fr] > > Sent: Thursday, 21 February 2013 3:53 AM > > To: builds@apache.org > > Subject: Re: Apache build infrastructure or Oracle JVM problem: crash > > in native JDK code > > > > Le 20/02/13 18:12, Jesse Glick a écrit : > > > I would merely claim that loading classes from a snapshot JAR is > > > _prone_ to triggering crashes when other factors come into play > > > which might be difficult to predict. > > I agree. We will move to a non-snapshot version when we can. The only > > issue is that we need to make a release before we can do that (unless > > we choose to keep permanently one of the snapshots). > > > > >> This snapshot JAR file is used as a plugin for other modules well > > >> after the build has been completed. > > > Well after the build of that plugin module has been completed I > > > suppose you mean. (According to your build log, the JAR is created > > > earlier in the reactor build and then loaded at the moment of the > > > crash.) > > Yes you are right, thank for clarifying. > > > > > At any rate, for many reasons it would be preferable to run on the > > > latest available version of Java (7u15 as of this writing). I do not > > > personally have admin permissions to help you there. > > Anyway, many thanks for your efforts, > > > > Martin >
