www-builds mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Gavin McDonald" <ga...@16degrees.com.au>
Subject RE: Apache build infrastructure or Oracle JVM problem: crash in native JDK code
Date Fri, 22 Feb 2013 03:14:45 GMT
I think we need to clarify some things here:

1.   'Jenkins Server' is generic, saying that the 'Jenkins Server' needs java 7 updating means
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

This 'Solaris1' slave does have an out-dated java 7 and I'll update it shortly.


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)


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.



> -----Original Message-----
> From: Martin Desruisseaux [mailto:martin.desruisseaux@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

View raw message