You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@buildr.apache.org by Martin Grotzke <ma...@javakaffee.de> on 2009/07/30 14:00:02 UTC
segfaults with java 6
Hi,
I just want to address the issue, that with java 6 there can occur
segfaults from time to time. The advice ([1]) is to go back to java 5 or
to use jruby. Both solution are not ideal IMHO. java 5 might not be an
option as there are already projects that require java 6, and jruby is
not ideal as it has longer startup times of buildr. Therefore, from my
point of view, running buildr "natively" is the best option and if it's
required with java 6.
For new users this might be an issue that causes a loss of trust in
buildr and the stable build.
Do you also think that this issue should be addressed and eliminated?
Are you aware of any reasons that might cause the segmentation faults?
I have also a concrete example (from one of my colleagues) with a
segmentation fault. That's a part from the build output:
$ buildr clean; buildr -t
...
Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 +0200 2009 (/home/philip/projects/final-folder/buildfile). Last successful test run: <EARLY TIME>.
** Invoke ff:core:test (first_time)
** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
** Invoke ff:core:test:compile (first_time)
** Invoke ff:core:compile (not_needed)
** Invoke ff:core:test:resources (first_time)
** Execute ff:core:test:resources
** Invoke /home/philip/projects/final-folder/core/target/test/resources (first_time)
** Execute /home/philip/projects/final-folder/core/target/test/resources
Segmentation fault
This is caused by the invocation of just buildr (without any task), if
buildr is invoked with a task (e.g. build, compile or test) there's no
segementation fault.
This are the versions of buildr, ruby and java:
Java: 1.6.0_14
Ruby: 1.8.7
Buildr: 1.3.4
If that's also the case for other users, a first workaround might be not
to promote the invocation of just "buildr", but instead say that "buildr
build" should be run.
What do you think?
Thanx && cheers,
Martin
[1] http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
Re: segfaults with java 6
Posted by Martin Grotzke <ma...@javakaffee.de>.
On Mon, 2009-08-03 at 11:36 -0500, Daniel Spiewak wrote:
> > Also the troubleshooting guide should describe what can be done if rjb
> > once is messed up: one should remove and reinstall rjb with the correct
> > JAVA_HOME env variable set.
> > (An interesting observation: even if the troubleshooting guide explains
> > what's the reason for segfaults both a colleage and I didn't get it
> > really (or just didn't read it carefully enough) and didn't get what has
> > to be done to fix the segfault.)
>
>
> The segfault is essentially the processor's colorful way of saying "symbol
> referencing error" (or NoSuchMethodException in Java-land). At least, it is
> in this case. RJB was compiled against a header file for a library (the
> JVM) which changed between compile-time and runtime. When this happens,
> some code paths will be referencing library symbols which do not exist, or
> which have different signatures. In either case, the usual result is a
> segfault.
Hehe, again a very good explanation :) But after one of your prior
emails on this my colleague and I read the troubleshooting again and
suddenly got it :)
>
> As discussed earlier, there is also a non-version-switch-related segfault
> which seems to occur in weird places. This is most likely a bug somewhere
> in RJB. The only way to track this down is to compile the RJB native code
> with debug symbols enabled. Then, run `gdb $RUBY_HOME/bin/ruby
> $BUILDR_HOME/_buildr` and enter the "run" command at the resulting prompt (I
> think it's "run" anyway, it's been a while). GDB will automatically stop
> exactly where the segfault will occur. You can use the "list" and "print"
> commands to dig around ("help" shows available options). These sorts of
> segfaults are usually more the equivalent of Java's NullPointerException,
> but not always. Watch out for 0-valued pointers or array indexes well out
> of bounds. Oh, if you want better tooling than GDB, you might be able to
> use Eclipse CDT's debugger to step through, but I've never done it that way.
Ok, thanx for this step by step guide, I'll tell my colleague what he
shall do when he's able to reproduce it with a simple example :)
>
> Bon chance!
On verra...
(that was google.translate('de', 'fr', 'man wird sehen')) :)
Cheers,
Martin
>
> Daniel
Re: segfaults with java 6
Posted by Daniel Spiewak <dj...@gmail.com>.
> Also the troubleshooting guide should describe what can be done if rjb
> once is messed up: one should remove and reinstall rjb with the correct
> JAVA_HOME env variable set.
> (An interesting observation: even if the troubleshooting guide explains
> what's the reason for segfaults both a colleage and I didn't get it
> really (or just didn't read it carefully enough) and didn't get what has
> to be done to fix the segfault.)
The segfault is essentially the processor's colorful way of saying "symbol
referencing error" (or NoSuchMethodException in Java-land). At least, it is
in this case. RJB was compiled against a header file for a library (the
JVM) which changed between compile-time and runtime. When this happens,
some code paths will be referencing library symbols which do not exist, or
which have different signatures. In either case, the usual result is a
segfault.
As discussed earlier, there is also a non-version-switch-related segfault
which seems to occur in weird places. This is most likely a bug somewhere
in RJB. The only way to track this down is to compile the RJB native code
with debug symbols enabled. Then, run `gdb $RUBY_HOME/bin/ruby
$BUILDR_HOME/_buildr` and enter the "run" command at the resulting prompt (I
think it's "run" anyway, it's been a while). GDB will automatically stop
exactly where the segfault will occur. You can use the "list" and "print"
commands to dig around ("help" shows available options). These sorts of
segfaults are usually more the equivalent of Java's NullPointerException,
but not always. Watch out for 0-valued pointers or array indexes well out
of bounds. Oh, if you want better tooling than GDB, you might be able to
use Eclipse CDT's debugger to step through, but I've never done it that way.
Bon chance!
Daniel
Re: segfaults with java 6
Posted by Martin Grotzke <ma...@javakaffee.de>.
I thought again about this switching-jdks issue, and it's not as
essential as I thought before. Even if the projects later run on
different jvms in production, the developer itself could build the
java-1.4 compatible project with the 1.6 jdk, if the source and target
arguments are correctly set for javac.
Only the continuous integration server should build/test the projects
using the "real" target jdk, but in this case one or two seconds more
for startup are not an issue.
So I'd suggest that the setup/install guide points out that for the
installation of buildr/rjb the JAVA_HOME has to be set to the JAVA_HOME
that's used later for building the project.
Also the troubleshooting guide should describe what can be done if rjb
once is messed up: one should remove and reinstall rjb with the correct
JAVA_HOME env variable set.
(An interesting observation: even if the troubleshooting guide explains
what's the reason for segfaults both a colleage and I didn't get it
really (or just didn't read it carefully enough) and didn't get what has
to be done to fix the segfault.)
Do you agree with these changes? Shall I do any of them?
Cheers,
Martin
On Sun, 2009-08-02 at 18:00 -0500, Daniel Spiewak wrote:
> If switching between JDK versions is an essential feature, then really your
> only option at present is to use JRuby. It's actually a pretty good way to
> use Buildr, just as good in every respect except for startup time (~2
> seconds as opposed to ~50ms). If you're using a modern Sun VM (>=1.6.0_10)
> then the startup time could be even less than 1 sec (at least in my tests).
>
> Hopefully, either I or someone else will get a chance to implement a
> socket-based Ruby-Java bridge, but until then... :-S
>
> Daniel
>
> On Sun, Aug 2, 2009 at 8:12 AM, Martin Grotzke <martin.grotzke@javakaffee.de
> > wrote:
>
> > On Sat, 2009-08-01 at 23:14 -0500, Daniel Spiewak wrote:
> > > Minor versions should be ok, though I would be careful going between
> > 1.6.0
> > > and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly not sure
> > > that switching between JDKs is a particularly common use-case. It's
> > really
> > > annoying that RJB is like this, but I don't see any other way as long as
> > the
> > > bridge is using JNI under the surface.
> > In our company this is a common use case, as lots of developers are
> > working on several projects that use different jvm versions - depending
> > on the client, app server, project infrastructure etc.
> >
> > >
> > > Another (possibly better) option would be to run Java in a sub-process
> > > spawned by Ruby with socket communication between the two. This would
> > > prevent incompatibility mismatch and cut the tight coupling to JVM
> > > installations. The main downside to this is that no one has done
> > anything
> > > like this (to my knowledge), so it's not a pre-existing (stable) solution
> > > like RJB. The immediate advantage to such a solution though is that it
> > > would allow us to finally support Buildr on MRI with Java 6 on Mac.
> > Puh, sound rather robust but also as if this would require huge amounts
> > of work.
> >
> > Now I also addressed this in the rjb forum:
> > http://rubyforge.org/forum/forum.php?thread_id=45030&forum_id=8190
> >
> > Cheers,
> > Martin
> >
> >
> > >
> > > Daniel
> > >
> > > On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke <
> > martin.grotzke@javakaffee.de
> > > > wrote:
> > >
> > > > D'oh, no good news. What about switching between minor versions, e.g.
> > > > from 1.6.0_03 to 1.6.0_14?
> > > >
> > > > Wouldn't it be good to be able to have several rjb versions running in
> > > > parallel, and to switch them with s.th. like alternatives? (the rjb
> > > > version then would have to include the used/linked jdk version, s.th.
> > > > like <rjbversion-jdkversion>).
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > >
> > > > On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
> > > > > Yes, it does.
> > > > >
> > > > > Daniel
> > > > >
> > > > > On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <
> > > > martin.grotzke@javakaffee.de
> > > > > > wrote:
> > > > >
> > > > > > Does this mean, that when one switches the current jvm (e.g. from
> > 1.5
> > > > to
> > > > > > 1.6) one would have to reinstall rjb, so that it uses the correct
> > jdk
> > > > > > header files?
> > > > > >
> > > > > > Cheers,
> > > > > > Martin
> > > > > >
> > > > > >
> > > > > > On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
> > > > > > > If it makes you feel any better, the problem is with RJB and not
> > > > Buildr
> > > > > > > itself. However, that doesn't change anything about user
> > > > perception...
> > > > > > >
> > > > > > > To be honest, I'm with you on this one. I would much rather run
> > > > Buildr
> > > > > > > under MRI, or really *any* Ruby implementation other than JRuby.
> > > > Don't
> > > > > > get
> > > > > > > me wrong, I love the JRuby project, but a tool like Buildr lives
> > and
> > > > dies
> > > > > > by
> > > > > > > startup time, an area where JRuby does very poorly. One option
> > which
> > > > > > might
> > > > > > > work on Mac OS X (one which I haven't tried) is to use SoyLatte
> > 32bit
> > > > (
> > > > > > >
> > > > > >
> > > >
> > http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> > > > > > ).
> > > > > > > Note that if you take this route, you will need to do more than
> > just
> > > > set
> > > > > > > JAVA_HOME and the PATH, you will need to actually symlink
> > > > > > >
> > > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
> > > > > > to
> > > > > > > the correct directory within SoyLatte, and then
> > > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK
> > to
> > > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte.
> > Crazy
> > > > > > Apple
> > > > > > > VM layout...
> > > > > > >
> > > > > > > As for running Buildr with Java 6 on other platforms, like Linux
> > or
> > > > > > Windows,
> > > > > > > I've actually had a lot more success along those lines. To be
> > > > honest,
> > > > > > I've
> > > > > > > never had it segfault on Windows, and on Linux only when RJB has
> > been
> > > > > > > incorrectly compiled/linked. So, the main trouble is Mac, and as
> > the
> > > > > > > "Common Problems and Solutions" document states, the trouble is
> > 32bit
> > > > MRI
> > > > > > > mixing with 64bit Java. The only possible solution I can see
> > here is
> > > > to
> > > > > > > create an entirely new Ruby-Java bridge based on sockets.
> > Obviously,
> > > > > > this
> > > > > > > isn't a viable option (unless someone wants to volunteer?).
> > > > > > >
> > > > > > > So, that brings us back to square one. I don't know what else to
> > say
> > > > at
> > > > > > > this point, we really have tried a lot of different solutions to
> > this
> > > > > > > problem, none of which have worked terribly well.
> > > > > > >
> > > > > > > Daniel
> > > > > > >
> > > > > > > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> > > > > > > martin.grotzke@javakaffee.de> wrote:
> > > > > > >
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > I just want to address the issue, that with java 6 there can
> > occur
> > > > > > > > segfaults from time to time. The advice ([1]) is to go back to
> > java
> > > > 5
> > > > > > or
> > > > > > > > to use jruby. Both solution are not ideal IMHO. java 5 might
> > not be
> > > > an
> > > > > > > > option as there are already projects that require java 6, and
> > jruby
> > > > is
> > > > > > > > not ideal as it has longer startup times of buildr. Therefore,
> > from
> > > > my
> > > > > > > > point of view, running buildr "natively" is the best option and
> > if
> > > > it's
> > > > > > > > required with java 6.
> > > > > > > >
> > > > > > > > For new users this might be an issue that causes a loss of
> > trust in
> > > > > > > > buildr and the stable build.
> > > > > > > >
> > > > > > > > Do you also think that this issue should be addressed and
> > > > eliminated?
> > > > > > > >
> > > > > > > > Are you aware of any reasons that might cause the segmentation
> > > > faults?
> > > > > > > >
> > > > > > > > I have also a concrete example (from one of my colleagues) with
> > a
> > > > > > > > segmentation fault. That's a part from the build output:
> > > > > > > >
> > > > > > > > $ buildr clean; buildr -t
> > > > > > > > ...
> > > > > > > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26
> > > > +0200
> > > > > > 2009
> > > > > > > > (/home/philip/projects/final-folder/buildfile). Last successful
> > > > test
> > > > > > run:
> > > > > > > > <EARLY TIME>.
> > > > > > > > ** Invoke ff:core:test (first_time)
> > > > > > > > ** Invoke /home/philip/projects/final-folder/buildfile
> > (not_needed)
> > > > > > > > ** Invoke ff:core:test:compile (first_time)
> > > > > > > > ** Invoke ff:core:compile (not_needed)
> > > > > > > > ** Invoke ff:core:test:resources (first_time)
> > > > > > > > ** Execute ff:core:test:resources
> > > > > > > > ** Invoke
> > > > /home/philip/projects/final-folder/core/target/test/resources
> > > > > > > > (first_time)
> > > > > > > > ** Execute
> > > > > > /home/philip/projects/final-folder/core/target/test/resources
> > > > > > > > Segmentation fault
> > > > > > > >
> > > > > > > > This is caused by the invocation of just buildr (without any
> > task),
> > > > if
> > > > > > > > buildr is invoked with a task (e.g. build, compile or test)
> > there's
> > > > no
> > > > > > > > segementation fault.
> > > > > > > >
> > > > > > > > This are the versions of buildr, ruby and java:
> > > > > > > > Java: 1.6.0_14
> > > > > > > > Ruby: 1.8.7
> > > > > > > > Buildr: 1.3.4
> > > > > > > >
> > > > > > > > If that's also the case for other users, a first workaround
> > might
> > > > be
> > > > > > not
> > > > > > > > to promote the invocation of just "buildr", but instead say
> > that
> > > > > > "buildr
> > > > > > > > build" should be run.
> > > > > > > >
> > > > > > > > What do you think?
> > > > > > > >
> > > > > > > > Thanx && cheers,
> > > > > > > > Martin
> > > > > > > >
> > > > > > > >
> > > > > > > > [1]
> > > > > > > >
> > > > > >
> > > >
> > http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > >
> > > >
> >
Re: segfaults with java 6
Posted by Tal Rotbart <re...@gmail.com>.
Hi Peter,
The easiest way would be:
jruby --ng -S buildr
(after starting the ng server using jruby --ng-server)
I'll put it in the wiki.
Regards,
Tal Rotbart
On Mon, Aug 3, 2009 at 10:34 PM, peter schröder<ps...@blau.de> wrote:
> Hi Tal,
>
> how exactly do you start buildr using jruby --ng ?
>
> could you put this stuff in the buildr wiki?
>
> i saw some commit-messages with nailgun in the buildr addon-trunk what about
> dat?
>
> kind regards,
> peter
>
> Am 03.08.2009 um 12:27 schrieb Tal Rotbart:
>
>> May I suggest using JRuby with Nailgun when running Buildr.
>> Nailgun keeps a JVM running and thus using it with Buildr results in
>> nearly no startup time.
>> Nailgun is bundled with Jruby these days.
>>
>> Regs,
>> Tal
>>
>> On Mon, Aug 3, 2009 at 9:00 AM, Daniel Spiewak<dj...@gmail.com> wrote:
>>>
>>> If switching between JDK versions is an essential feature, then really
>>> your
>>> only option at present is to use JRuby. It's actually a pretty good way
>>> to
>>> use Buildr, just as good in every respect except for startup time (~2
>>> seconds as opposed to ~50ms). If you're using a modern Sun VM
>>> (>=1.6.0_10)
>>> then the startup time could be even less than 1 sec (at least in my
>>> tests).
>>>
>>> Hopefully, either I or someone else will get a chance to implement a
>>> socket-based Ruby-Java bridge, but until then... :-S
>>>
>>> Daniel
>>>
>>> On Sun, Aug 2, 2009 at 8:12 AM, Martin Grotzke
>>> <martin.grotzke@javakaffee.de
>>>>
>>>> wrote:
>>>
>>>> On Sat, 2009-08-01 at 23:14 -0500, Daniel Spiewak wrote:
>>>>>
>>>>> Minor versions should be ok, though I would be careful going between
>>>>
>>>> 1.6.0
>>>>>
>>>>> and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly not
>>>>> sure
>>>>> that switching between JDKs is a particularly common use-case. It's
>>>>
>>>> really
>>>>>
>>>>> annoying that RJB is like this, but I don't see any other way as long
>>>>> as
>>>>
>>>> the
>>>>>
>>>>> bridge is using JNI under the surface.
>>>>
>>>> In our company this is a common use case, as lots of developers are
>>>> working on several projects that use different jvm versions - depending
>>>> on the client, app server, project infrastructure etc.
>>>>
>>>>>
>>>>> Another (possibly better) option would be to run Java in a sub-process
>>>>> spawned by Ruby with socket communication between the two. This would
>>>>> prevent incompatibility mismatch and cut the tight coupling to JVM
>>>>> installations. The main downside to this is that no one has done
>>>>
>>>> anything
>>>>>
>>>>> like this (to my knowledge), so it's not a pre-existing (stable)
>>>>> solution
>>>>> like RJB. The immediate advantage to such a solution though is that it
>>>>> would allow us to finally support Buildr on MRI with Java 6 on Mac.
>>>>
>>>> Puh, sound rather robust but also as if this would require huge amounts
>>>> of work.
>>>>
>>>> Now I also addressed this in the rjb forum:
>>>> http://rubyforge.org/forum/forum.php?thread_id=45030&forum_id=8190
>>>>
>>>> Cheers,
>>>> Martin
>>>>
>>>>
>>>>>
>>>>> Daniel
>>>>>
>>>>> On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke <
>>>>
>>>> martin.grotzke@javakaffee.de
>>>>>>
>>>>>> wrote:
>>>>>
>>>>>> D'oh, no good news. What about switching between minor versions, e.g.
>>>>>> from 1.6.0_03 to 1.6.0_14?
>>>>>>
>>>>>> Wouldn't it be good to be able to have several rjb versions running in
>>>>>> parallel, and to switch them with s.th. like alternatives? (the rjb
>>>>>> version then would have to include the used/linked jdk version, s.th.
>>>>>> like <rjbversion-jdkversion>).
>>>>>>
>>>>>> Cheers,
>>>>>> Martin
>>>>>>
>>>>>>
>>>>>> On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
>>>>>>>
>>>>>>> Yes, it does.
>>>>>>>
>>>>>>> Daniel
>>>>>>>
>>>>>>> On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <
>>>>>>
>>>>>> martin.grotzke@javakaffee.de
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>
>>>>>>>> Does this mean, that when one switches the current jvm (e.g. from
>>>>
>>>> 1.5
>>>>>>
>>>>>> to
>>>>>>>>
>>>>>>>> 1.6) one would have to reinstall rjb, so that it uses the correct
>>>>
>>>> jdk
>>>>>>>>
>>>>>>>> header files?
>>>>>>>>
>>>>>>>> Cheers,
>>>>>>>> Martin
>>>>>>>>
>>>>>>>>
>>>>>>>> On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
>>>>>>>>>
>>>>>>>>> If it makes you feel any better, the problem is with RJB and not
>>>>>>
>>>>>> Buildr
>>>>>>>>>
>>>>>>>>> itself. However, that doesn't change anything about user
>>>>>>
>>>>>> perception...
>>>>>>>>>
>>>>>>>>> To be honest, I'm with you on this one. I would much rather run
>>>>>>
>>>>>> Buildr
>>>>>>>>>
>>>>>>>>> under MRI, or really *any* Ruby implementation other than JRuby.
>>>>>>
>>>>>> Don't
>>>>>>>>
>>>>>>>> get
>>>>>>>>>
>>>>>>>>> me wrong, I love the JRuby project, but a tool like Buildr lives
>>>>
>>>> and
>>>>>>
>>>>>> dies
>>>>>>>>
>>>>>>>> by
>>>>>>>>>
>>>>>>>>> startup time, an area where JRuby does very poorly. One option
>>>>
>>>> which
>>>>>>>>
>>>>>>>> might
>>>>>>>>>
>>>>>>>>> work on Mac OS X (one which I haven't tried) is to use SoyLatte
>>>>
>>>> 32bit
>>>>>>
>>>>>> (
>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
>>>>>>>>
>>>>>>>> ).
>>>>>>>>>
>>>>>>>>> Note that if you take this route, you will need to do more than
>>>>
>>>> just
>>>>>>
>>>>>> set
>>>>>>>>>
>>>>>>>>> JAVA_HOME and the PATH, you will need to actually symlink
>>>>>>>>>
>>>>>>
>>>>>> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
>>>>>>>>
>>>>>>>> to
>>>>>>>>>
>>>>>>>>> the correct directory within SoyLatte, and then
>>>>>>>>> /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK
>>>>
>>>> to
>>>>>>>>>
>>>>>>>>> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte.
>>>>
>>>> Crazy
>>>>>>>>
>>>>>>>> Apple
>>>>>>>>>
>>>>>>>>> VM layout...
>>>>>>>>>
>>>>>>>>> As for running Buildr with Java 6 on other platforms, like Linux
>>>>
>>>> or
>>>>>>>>
>>>>>>>> Windows,
>>>>>>>>>
>>>>>>>>> I've actually had a lot more success along those lines. To be
>>>>>>
>>>>>> honest,
>>>>>>>>
>>>>>>>> I've
>>>>>>>>>
>>>>>>>>> never had it segfault on Windows, and on Linux only when RJB has
>>>>
>>>> been
>>>>>>>>>
>>>>>>>>> incorrectly compiled/linked. So, the main trouble is Mac, and as
>>>>
>>>> the
>>>>>>>>>
>>>>>>>>> "Common Problems and Solutions" document states, the trouble is
>>>>
>>>> 32bit
>>>>>>
>>>>>> MRI
>>>>>>>>>
>>>>>>>>> mixing with 64bit Java. The only possible solution I can see
>>>>
>>>> here is
>>>>>>
>>>>>> to
>>>>>>>>>
>>>>>>>>> create an entirely new Ruby-Java bridge based on sockets.
>>>>
>>>> Obviously,
>>>>>>>>
>>>>>>>> this
>>>>>>>>>
>>>>>>>>> isn't a viable option (unless someone wants to volunteer?).
>>>>>>>>>
>>>>>>>>> So, that brings us back to square one. I don't know what else to
>>>>
>>>> say
>>>>>>
>>>>>> at
>>>>>>>>>
>>>>>>>>> this point, we really have tried a lot of different solutions to
>>>>
>>>> this
>>>>>>>>>
>>>>>>>>> problem, none of which have worked terribly well.
>>>>>>>>>
>>>>>>>>> Daniel
>>>>>>>>>
>>>>>>>>> On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
>>>>>>>>> martin.grotzke@javakaffee.de> wrote:
>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I just want to address the issue, that with java 6 there can
>>>>
>>>> occur
>>>>>>>>>>
>>>>>>>>>> segfaults from time to time. The advice ([1]) is to go back to
>>>>
>>>> java
>>>>>>
>>>>>> 5
>>>>>>>>
>>>>>>>> or
>>>>>>>>>>
>>>>>>>>>> to use jruby. Both solution are not ideal IMHO. java 5 might
>>>>
>>>> not be
>>>>>>
>>>>>> an
>>>>>>>>>>
>>>>>>>>>> option as there are already projects that require java 6, and
>>>>
>>>> jruby
>>>>>>
>>>>>> is
>>>>>>>>>>
>>>>>>>>>> not ideal as it has longer startup times of buildr. Therefore,
>>>>
>>>> from
>>>>>>
>>>>>> my
>>>>>>>>>>
>>>>>>>>>> point of view, running buildr "natively" is the best option and
>>>>
>>>> if
>>>>>>
>>>>>> it's
>>>>>>>>>>
>>>>>>>>>> required with java 6.
>>>>>>>>>>
>>>>>>>>>> For new users this might be an issue that causes a loss of
>>>>
>>>> trust in
>>>>>>>>>>
>>>>>>>>>> buildr and the stable build.
>>>>>>>>>>
>>>>>>>>>> Do you also think that this issue should be addressed and
>>>>>>
>>>>>> eliminated?
>>>>>>>>>>
>>>>>>>>>> Are you aware of any reasons that might cause the segmentation
>>>>>>
>>>>>> faults?
>>>>>>>>>>
>>>>>>>>>> I have also a concrete example (from one of my colleagues) with
>>>>
>>>> a
>>>>>>>>>>
>>>>>>>>>> segmentation fault. That's a part from the build output:
>>>>>>>>>>
>>>>>>>>>> $ buildr clean; buildr -t
>>>>>>>>>> ...
>>>>>>>>>> Testing needed. Latest prerequisite change: Do Jul 30 10:59:26
>>>>>>
>>>>>> +0200
>>>>>>>>
>>>>>>>> 2009
>>>>>>>>>>
>>>>>>>>>> (/home/philip/projects/final-folder/buildfile). Last successful
>>>>>>
>>>>>> test
>>>>>>>>
>>>>>>>> run:
>>>>>>>>>>
>>>>>>>>>> <EARLY TIME>.
>>>>>>>>>> ** Invoke ff:core:test (first_time)
>>>>>>>>>> ** Invoke /home/philip/projects/final-folder/buildfile
>>>>
>>>> (not_needed)
>>>>>>>>>>
>>>>>>>>>> ** Invoke ff:core:test:compile (first_time)
>>>>>>>>>> ** Invoke ff:core:compile (not_needed)
>>>>>>>>>> ** Invoke ff:core:test:resources (first_time)
>>>>>>>>>> ** Execute ff:core:test:resources
>>>>>>>>>> ** Invoke
>>>>>>
>>>>>> /home/philip/projects/final-folder/core/target/test/resources
>>>>>>>>>>
>>>>>>>>>> (first_time)
>>>>>>>>>> ** Execute
>>>>>>>>
>>>>>>>> /home/philip/projects/final-folder/core/target/test/resources
>>>>>>>>>>
>>>>>>>>>> Segmentation fault
>>>>>>>>>>
>>>>>>>>>> This is caused by the invocation of just buildr (without any
>>>>
>>>> task),
>>>>>>
>>>>>> if
>>>>>>>>>>
>>>>>>>>>> buildr is invoked with a task (e.g. build, compile or test)
>>>>
>>>> there's
>>>>>>
>>>>>> no
>>>>>>>>>>
>>>>>>>>>> segementation fault.
>>>>>>>>>>
>>>>>>>>>> This are the versions of buildr, ruby and java:
>>>>>>>>>> Java: 1.6.0_14
>>>>>>>>>> Ruby: 1.8.7
>>>>>>>>>> Buildr: 1.3.4
>>>>>>>>>>
>>>>>>>>>> If that's also the case for other users, a first workaround
>>>>
>>>> might
>>>>>>
>>>>>> be
>>>>>>>>
>>>>>>>> not
>>>>>>>>>>
>>>>>>>>>> to promote the invocation of just "buildr", but instead say
>>>>
>>>> that
>>>>>>>>
>>>>>>>> "buildr
>>>>>>>>>>
>>>>>>>>>> build" should be run.
>>>>>>>>>>
>>>>>>>>>> What do you think?
>>>>>>>>>>
>>>>>>>>>> Thanx && cheers,
>>>>>>>>>> Martin
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> [1]
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>
>>>>>>
>>>>
>>>
>
> _________________________________
> Peter Schröder
> IT
>
> blau: +49 (0) 178 139 1035
> fax: +49 (0) 40 288 071 - 71
> mail: ps@blau.de
>
> blau Mobilfunk GmbH
> Schulterblatt 124
> D-20357 Hamburg
>
> Sitz: Hamburg
> HRB 80531 Amtsgericht Hamburg
> Geschäftsführer: Dirk Freise, Martin Ostermayer, Thorsten Rehling
>
>
Re: segfaults with java 6
Posted by peter schröder <ps...@blau.de>.
Hi Tal,
how exactly do you start buildr using jruby --ng ?
could you put this stuff in the buildr wiki?
i saw some commit-messages with nailgun in the buildr addon-trunk what
about dat?
kind regards,
peter
Am 03.08.2009 um 12:27 schrieb Tal Rotbart:
> May I suggest using JRuby with Nailgun when running Buildr.
> Nailgun keeps a JVM running and thus using it with Buildr results in
> nearly no startup time.
> Nailgun is bundled with Jruby these days.
>
> Regs,
> Tal
>
> On Mon, Aug 3, 2009 at 9:00 AM, Daniel Spiewak<dj...@gmail.com>
> wrote:
>> If switching between JDK versions is an essential feature, then
>> really your
>> only option at present is to use JRuby. It's actually a pretty
>> good way to
>> use Buildr, just as good in every respect except for startup time (~2
>> seconds as opposed to ~50ms). If you're using a modern Sun VM
>> (>=1.6.0_10)
>> then the startup time could be even less than 1 sec (at least in my
>> tests).
>>
>> Hopefully, either I or someone else will get a chance to implement a
>> socket-based Ruby-Java bridge, but until then... :-S
>>
>> Daniel
>>
>> On Sun, Aug 2, 2009 at 8:12 AM, Martin Grotzke <martin.grotzke@javakaffee.de
>>> wrote:
>>
>>> On Sat, 2009-08-01 at 23:14 -0500, Daniel Spiewak wrote:
>>>> Minor versions should be ok, though I would be careful going
>>>> between
>>> 1.6.0
>>>> and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly
>>>> not sure
>>>> that switching between JDKs is a particularly common use-case.
>>>> It's
>>> really
>>>> annoying that RJB is like this, but I don't see any other way as
>>>> long as
>>> the
>>>> bridge is using JNI under the surface.
>>> In our company this is a common use case, as lots of developers are
>>> working on several projects that use different jvm versions -
>>> depending
>>> on the client, app server, project infrastructure etc.
>>>
>>>>
>>>> Another (possibly better) option would be to run Java in a sub-
>>>> process
>>>> spawned by Ruby with socket communication between the two. This
>>>> would
>>>> prevent incompatibility mismatch and cut the tight coupling to JVM
>>>> installations. The main downside to this is that no one has done
>>> anything
>>>> like this (to my knowledge), so it's not a pre-existing (stable)
>>>> solution
>>>> like RJB. The immediate advantage to such a solution though is
>>>> that it
>>>> would allow us to finally support Buildr on MRI with Java 6 on Mac.
>>> Puh, sound rather robust but also as if this would require huge
>>> amounts
>>> of work.
>>>
>>> Now I also addressed this in the rjb forum:
>>> http://rubyforge.org/forum/forum.php?thread_id=45030&forum_id=8190
>>>
>>> Cheers,
>>> Martin
>>>
>>>
>>>>
>>>> Daniel
>>>>
>>>> On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke <
>>> martin.grotzke@javakaffee.de
>>>>> wrote:
>>>>
>>>>> D'oh, no good news. What about switching between minor versions,
>>>>> e.g.
>>>>> from 1.6.0_03 to 1.6.0_14?
>>>>>
>>>>> Wouldn't it be good to be able to have several rjb versions
>>>>> running in
>>>>> parallel, and to switch them with s.th. like alternatives? (the
>>>>> rjb
>>>>> version then would have to include the used/linked jdk version,
>>>>> s.th.
>>>>> like <rjbversion-jdkversion>).
>>>>>
>>>>> Cheers,
>>>>> Martin
>>>>>
>>>>>
>>>>> On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
>>>>>> Yes, it does.
>>>>>>
>>>>>> Daniel
>>>>>>
>>>>>> On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <
>>>>> martin.grotzke@javakaffee.de
>>>>>>> wrote:
>>>>>>
>>>>>>> Does this mean, that when one switches the current jvm (e.g.
>>>>>>> from
>>> 1.5
>>>>> to
>>>>>>> 1.6) one would have to reinstall rjb, so that it uses the
>>>>>>> correct
>>> jdk
>>>>>>> header files?
>>>>>>>
>>>>>>> Cheers,
>>>>>>> Martin
>>>>>>>
>>>>>>>
>>>>>>> On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
>>>>>>>> If it makes you feel any better, the problem is with RJB and
>>>>>>>> not
>>>>> Buildr
>>>>>>>> itself. However, that doesn't change anything about user
>>>>> perception...
>>>>>>>>
>>>>>>>> To be honest, I'm with you on this one. I would much rather
>>>>>>>> run
>>>>> Buildr
>>>>>>>> under MRI, or really *any* Ruby implementation other than
>>>>>>>> JRuby.
>>>>> Don't
>>>>>>> get
>>>>>>>> me wrong, I love the JRuby project, but a tool like Buildr
>>>>>>>> lives
>>> and
>>>>> dies
>>>>>>> by
>>>>>>>> startup time, an area where JRuby does very poorly. One option
>>> which
>>>>>>> might
>>>>>>>> work on Mac OS X (one which I haven't tried) is to use SoyLatte
>>> 32bit
>>>>> (
>>>>>>>>
>>>>>>>
>>>>>
>>> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
>>>>>>> ).
>>>>>>>> Note that if you take this route, you will need to do more than
>>> just
>>>>> set
>>>>>>>> JAVA_HOME and the PATH, you will need to actually symlink
>>>>>>>>
>>>>> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/
>>>>> Libraries
>>>>>>> to
>>>>>>>> the correct directory within SoyLatte, and then
>>>>>>>> /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK
>>> to
>>>>>>>> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte.
>>> Crazy
>>>>>>> Apple
>>>>>>>> VM layout...
>>>>>>>>
>>>>>>>> As for running Buildr with Java 6 on other platforms, like
>>>>>>>> Linux
>>> or
>>>>>>> Windows,
>>>>>>>> I've actually had a lot more success along those lines. To be
>>>>> honest,
>>>>>>> I've
>>>>>>>> never had it segfault on Windows, and on Linux only when RJB
>>>>>>>> has
>>> been
>>>>>>>> incorrectly compiled/linked. So, the main trouble is Mac,
>>>>>>>> and as
>>> the
>>>>>>>> "Common Problems and Solutions" document states, the trouble is
>>> 32bit
>>>>> MRI
>>>>>>>> mixing with 64bit Java. The only possible solution I can see
>>> here is
>>>>> to
>>>>>>>> create an entirely new Ruby-Java bridge based on sockets.
>>> Obviously,
>>>>>>> this
>>>>>>>> isn't a viable option (unless someone wants to volunteer?).
>>>>>>>>
>>>>>>>> So, that brings us back to square one. I don't know what
>>>>>>>> else to
>>> say
>>>>> at
>>>>>>>> this point, we really have tried a lot of different solutions
>>>>>>>> to
>>> this
>>>>>>>> problem, none of which have worked terribly well.
>>>>>>>>
>>>>>>>> Daniel
>>>>>>>>
>>>>>>>> On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
>>>>>>>> martin.grotzke@javakaffee.de> wrote:
>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I just want to address the issue, that with java 6 there can
>>> occur
>>>>>>>>> segfaults from time to time. The advice ([1]) is to go back to
>>> java
>>>>> 5
>>>>>>> or
>>>>>>>>> to use jruby. Both solution are not ideal IMHO. java 5 might
>>> not be
>>>>> an
>>>>>>>>> option as there are already projects that require java 6, and
>>> jruby
>>>>> is
>>>>>>>>> not ideal as it has longer startup times of buildr. Therefore,
>>> from
>>>>> my
>>>>>>>>> point of view, running buildr "natively" is the best option
>>>>>>>>> and
>>> if
>>>>> it's
>>>>>>>>> required with java 6.
>>>>>>>>>
>>>>>>>>> For new users this might be an issue that causes a loss of
>>> trust in
>>>>>>>>> buildr and the stable build.
>>>>>>>>>
>>>>>>>>> Do you also think that this issue should be addressed and
>>>>> eliminated?
>>>>>>>>>
>>>>>>>>> Are you aware of any reasons that might cause the segmentation
>>>>> faults?
>>>>>>>>>
>>>>>>>>> I have also a concrete example (from one of my colleagues)
>>>>>>>>> with
>>> a
>>>>>>>>> segmentation fault. That's a part from the build output:
>>>>>>>>>
>>>>>>>>> $ buildr clean; buildr -t
>>>>>>>>> ...
>>>>>>>>> Testing needed. Latest prerequisite change: Do Jul 30 10:59:26
>>>>> +0200
>>>>>>> 2009
>>>>>>>>> (/home/philip/projects/final-folder/buildfile). Last
>>>>>>>>> successful
>>>>> test
>>>>>>> run:
>>>>>>>>> <EARLY TIME>.
>>>>>>>>> ** Invoke ff:core:test (first_time)
>>>>>>>>> ** Invoke /home/philip/projects/final-folder/buildfile
>>> (not_needed)
>>>>>>>>> ** Invoke ff:core:test:compile (first_time)
>>>>>>>>> ** Invoke ff:core:compile (not_needed)
>>>>>>>>> ** Invoke ff:core:test:resources (first_time)
>>>>>>>>> ** Execute ff:core:test:resources
>>>>>>>>> ** Invoke
>>>>> /home/philip/projects/final-folder/core/target/test/resources
>>>>>>>>> (first_time)
>>>>>>>>> ** Execute
>>>>>>> /home/philip/projects/final-folder/core/target/test/resources
>>>>>>>>> Segmentation fault
>>>>>>>>>
>>>>>>>>> This is caused by the invocation of just buildr (without any
>>> task),
>>>>> if
>>>>>>>>> buildr is invoked with a task (e.g. build, compile or test)
>>> there's
>>>>> no
>>>>>>>>> segementation fault.
>>>>>>>>>
>>>>>>>>> This are the versions of buildr, ruby and java:
>>>>>>>>> Java: 1.6.0_14
>>>>>>>>> Ruby: 1.8.7
>>>>>>>>> Buildr: 1.3.4
>>>>>>>>>
>>>>>>>>> If that's also the case for other users, a first workaround
>>> might
>>>>> be
>>>>>>> not
>>>>>>>>> to promote the invocation of just "buildr", but instead say
>>> that
>>>>>>> "buildr
>>>>>>>>> build" should be run.
>>>>>>>>>
>>>>>>>>> What do you think?
>>>>>>>>>
>>>>>>>>> Thanx && cheers,
>>>>>>>>> Martin
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> [1]
>>>>>>>>>
>>>>>>>
>>>>>
>>> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>
>>>>>
>>>
>>
_________________________________
Peter Schröder
IT
blau: +49 (0) 178 139 1035
fax: +49 (0) 40 288 071 - 71
mail: ps@blau.de
blau Mobilfunk GmbH
Schulterblatt 124
D-20357 Hamburg
Sitz: Hamburg
HRB 80531 Amtsgericht Hamburg
Geschäftsführer: Dirk Freise, Martin Ostermayer, Thorsten Rehling
Re: segfaults with java 6
Posted by Tal Rotbart <re...@gmail.com>.
May I suggest using JRuby with Nailgun when running Buildr.
Nailgun keeps a JVM running and thus using it with Buildr results in
nearly no startup time.
Nailgun is bundled with Jruby these days.
Regs,
Tal
On Mon, Aug 3, 2009 at 9:00 AM, Daniel Spiewak<dj...@gmail.com> wrote:
> If switching between JDK versions is an essential feature, then really your
> only option at present is to use JRuby. It's actually a pretty good way to
> use Buildr, just as good in every respect except for startup time (~2
> seconds as opposed to ~50ms). If you're using a modern Sun VM (>=1.6.0_10)
> then the startup time could be even less than 1 sec (at least in my tests).
>
> Hopefully, either I or someone else will get a chance to implement a
> socket-based Ruby-Java bridge, but until then... :-S
>
> Daniel
>
> On Sun, Aug 2, 2009 at 8:12 AM, Martin Grotzke <martin.grotzke@javakaffee.de
>> wrote:
>
>> On Sat, 2009-08-01 at 23:14 -0500, Daniel Spiewak wrote:
>> > Minor versions should be ok, though I would be careful going between
>> 1.6.0
>> > and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly not sure
>> > that switching between JDKs is a particularly common use-case. It's
>> really
>> > annoying that RJB is like this, but I don't see any other way as long as
>> the
>> > bridge is using JNI under the surface.
>> In our company this is a common use case, as lots of developers are
>> working on several projects that use different jvm versions - depending
>> on the client, app server, project infrastructure etc.
>>
>> >
>> > Another (possibly better) option would be to run Java in a sub-process
>> > spawned by Ruby with socket communication between the two. This would
>> > prevent incompatibility mismatch and cut the tight coupling to JVM
>> > installations. The main downside to this is that no one has done
>> anything
>> > like this (to my knowledge), so it's not a pre-existing (stable) solution
>> > like RJB. The immediate advantage to such a solution though is that it
>> > would allow us to finally support Buildr on MRI with Java 6 on Mac.
>> Puh, sound rather robust but also as if this would require huge amounts
>> of work.
>>
>> Now I also addressed this in the rjb forum:
>> http://rubyforge.org/forum/forum.php?thread_id=45030&forum_id=8190
>>
>> Cheers,
>> Martin
>>
>>
>> >
>> > Daniel
>> >
>> > On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke <
>> martin.grotzke@javakaffee.de
>> > > wrote:
>> >
>> > > D'oh, no good news. What about switching between minor versions, e.g.
>> > > from 1.6.0_03 to 1.6.0_14?
>> > >
>> > > Wouldn't it be good to be able to have several rjb versions running in
>> > > parallel, and to switch them with s.th. like alternatives? (the rjb
>> > > version then would have to include the used/linked jdk version, s.th.
>> > > like <rjbversion-jdkversion>).
>> > >
>> > > Cheers,
>> > > Martin
>> > >
>> > >
>> > > On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
>> > > > Yes, it does.
>> > > >
>> > > > Daniel
>> > > >
>> > > > On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <
>> > > martin.grotzke@javakaffee.de
>> > > > > wrote:
>> > > >
>> > > > > Does this mean, that when one switches the current jvm (e.g. from
>> 1.5
>> > > to
>> > > > > 1.6) one would have to reinstall rjb, so that it uses the correct
>> jdk
>> > > > > header files?
>> > > > >
>> > > > > Cheers,
>> > > > > Martin
>> > > > >
>> > > > >
>> > > > > On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
>> > > > > > If it makes you feel any better, the problem is with RJB and not
>> > > Buildr
>> > > > > > itself. However, that doesn't change anything about user
>> > > perception...
>> > > > > >
>> > > > > > To be honest, I'm with you on this one. I would much rather run
>> > > Buildr
>> > > > > > under MRI, or really *any* Ruby implementation other than JRuby.
>> > > Don't
>> > > > > get
>> > > > > > me wrong, I love the JRuby project, but a tool like Buildr lives
>> and
>> > > dies
>> > > > > by
>> > > > > > startup time, an area where JRuby does very poorly. One option
>> which
>> > > > > might
>> > > > > > work on Mac OS X (one which I haven't tried) is to use SoyLatte
>> 32bit
>> > > (
>> > > > > >
>> > > > >
>> > >
>> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
>> > > > > ).
>> > > > > > Note that if you take this route, you will need to do more than
>> just
>> > > set
>> > > > > > JAVA_HOME and the PATH, you will need to actually symlink
>> > > > > >
>> > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
>> > > > > to
>> > > > > > the correct directory within SoyLatte, and then
>> > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK
>> to
>> > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte.
>> Crazy
>> > > > > Apple
>> > > > > > VM layout...
>> > > > > >
>> > > > > > As for running Buildr with Java 6 on other platforms, like Linux
>> or
>> > > > > Windows,
>> > > > > > I've actually had a lot more success along those lines. To be
>> > > honest,
>> > > > > I've
>> > > > > > never had it segfault on Windows, and on Linux only when RJB has
>> been
>> > > > > > incorrectly compiled/linked. So, the main trouble is Mac, and as
>> the
>> > > > > > "Common Problems and Solutions" document states, the trouble is
>> 32bit
>> > > MRI
>> > > > > > mixing with 64bit Java. The only possible solution I can see
>> here is
>> > > to
>> > > > > > create an entirely new Ruby-Java bridge based on sockets.
>> Obviously,
>> > > > > this
>> > > > > > isn't a viable option (unless someone wants to volunteer?).
>> > > > > >
>> > > > > > So, that brings us back to square one. I don't know what else to
>> say
>> > > at
>> > > > > > this point, we really have tried a lot of different solutions to
>> this
>> > > > > > problem, none of which have worked terribly well.
>> > > > > >
>> > > > > > Daniel
>> > > > > >
>> > > > > > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
>> > > > > > martin.grotzke@javakaffee.de> wrote:
>> > > > > >
>> > > > > > > Hi,
>> > > > > > >
>> > > > > > > I just want to address the issue, that with java 6 there can
>> occur
>> > > > > > > segfaults from time to time. The advice ([1]) is to go back to
>> java
>> > > 5
>> > > > > or
>> > > > > > > to use jruby. Both solution are not ideal IMHO. java 5 might
>> not be
>> > > an
>> > > > > > > option as there are already projects that require java 6, and
>> jruby
>> > > is
>> > > > > > > not ideal as it has longer startup times of buildr. Therefore,
>> from
>> > > my
>> > > > > > > point of view, running buildr "natively" is the best option and
>> if
>> > > it's
>> > > > > > > required with java 6.
>> > > > > > >
>> > > > > > > For new users this might be an issue that causes a loss of
>> trust in
>> > > > > > > buildr and the stable build.
>> > > > > > >
>> > > > > > > Do you also think that this issue should be addressed and
>> > > eliminated?
>> > > > > > >
>> > > > > > > Are you aware of any reasons that might cause the segmentation
>> > > faults?
>> > > > > > >
>> > > > > > > I have also a concrete example (from one of my colleagues) with
>> a
>> > > > > > > segmentation fault. That's a part from the build output:
>> > > > > > >
>> > > > > > > $ buildr clean; buildr -t
>> > > > > > > ...
>> > > > > > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26
>> > > +0200
>> > > > > 2009
>> > > > > > > (/home/philip/projects/final-folder/buildfile). Last successful
>> > > test
>> > > > > run:
>> > > > > > > <EARLY TIME>.
>> > > > > > > ** Invoke ff:core:test (first_time)
>> > > > > > > ** Invoke /home/philip/projects/final-folder/buildfile
>> (not_needed)
>> > > > > > > ** Invoke ff:core:test:compile (first_time)
>> > > > > > > ** Invoke ff:core:compile (not_needed)
>> > > > > > > ** Invoke ff:core:test:resources (first_time)
>> > > > > > > ** Execute ff:core:test:resources
>> > > > > > > ** Invoke
>> > > /home/philip/projects/final-folder/core/target/test/resources
>> > > > > > > (first_time)
>> > > > > > > ** Execute
>> > > > > /home/philip/projects/final-folder/core/target/test/resources
>> > > > > > > Segmentation fault
>> > > > > > >
>> > > > > > > This is caused by the invocation of just buildr (without any
>> task),
>> > > if
>> > > > > > > buildr is invoked with a task (e.g. build, compile or test)
>> there's
>> > > no
>> > > > > > > segementation fault.
>> > > > > > >
>> > > > > > > This are the versions of buildr, ruby and java:
>> > > > > > > Java: 1.6.0_14
>> > > > > > > Ruby: 1.8.7
>> > > > > > > Buildr: 1.3.4
>> > > > > > >
>> > > > > > > If that's also the case for other users, a first workaround
>> might
>> > > be
>> > > > > not
>> > > > > > > to promote the invocation of just "buildr", but instead say
>> that
>> > > > > "buildr
>> > > > > > > build" should be run.
>> > > > > > >
>> > > > > > > What do you think?
>> > > > > > >
>> > > > > > > Thanx && cheers,
>> > > > > > > Martin
>> > > > > > >
>> > > > > > >
>> > > > > > > [1]
>> > > > > > >
>> > > > >
>> > >
>> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
>> > > > > > >
>> > > > > > >
>> > > > > > >
>> > > > >
>> > >
>>
>
Re: segfaults with java 6
Posted by Daniel Spiewak <dj...@gmail.com>.
If switching between JDK versions is an essential feature, then really your
only option at present is to use JRuby. It's actually a pretty good way to
use Buildr, just as good in every respect except for startup time (~2
seconds as opposed to ~50ms). If you're using a modern Sun VM (>=1.6.0_10)
then the startup time could be even less than 1 sec (at least in my tests).
Hopefully, either I or someone else will get a chance to implement a
socket-based Ruby-Java bridge, but until then... :-S
Daniel
On Sun, Aug 2, 2009 at 8:12 AM, Martin Grotzke <martin.grotzke@javakaffee.de
> wrote:
> On Sat, 2009-08-01 at 23:14 -0500, Daniel Spiewak wrote:
> > Minor versions should be ok, though I would be careful going between
> 1.6.0
> > and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly not sure
> > that switching between JDKs is a particularly common use-case. It's
> really
> > annoying that RJB is like this, but I don't see any other way as long as
> the
> > bridge is using JNI under the surface.
> In our company this is a common use case, as lots of developers are
> working on several projects that use different jvm versions - depending
> on the client, app server, project infrastructure etc.
>
> >
> > Another (possibly better) option would be to run Java in a sub-process
> > spawned by Ruby with socket communication between the two. This would
> > prevent incompatibility mismatch and cut the tight coupling to JVM
> > installations. The main downside to this is that no one has done
> anything
> > like this (to my knowledge), so it's not a pre-existing (stable) solution
> > like RJB. The immediate advantage to such a solution though is that it
> > would allow us to finally support Buildr on MRI with Java 6 on Mac.
> Puh, sound rather robust but also as if this would require huge amounts
> of work.
>
> Now I also addressed this in the rjb forum:
> http://rubyforge.org/forum/forum.php?thread_id=45030&forum_id=8190
>
> Cheers,
> Martin
>
>
> >
> > Daniel
> >
> > On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke <
> martin.grotzke@javakaffee.de
> > > wrote:
> >
> > > D'oh, no good news. What about switching between minor versions, e.g.
> > > from 1.6.0_03 to 1.6.0_14?
> > >
> > > Wouldn't it be good to be able to have several rjb versions running in
> > > parallel, and to switch them with s.th. like alternatives? (the rjb
> > > version then would have to include the used/linked jdk version, s.th.
> > > like <rjbversion-jdkversion>).
> > >
> > > Cheers,
> > > Martin
> > >
> > >
> > > On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
> > > > Yes, it does.
> > > >
> > > > Daniel
> > > >
> > > > On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <
> > > martin.grotzke@javakaffee.de
> > > > > wrote:
> > > >
> > > > > Does this mean, that when one switches the current jvm (e.g. from
> 1.5
> > > to
> > > > > 1.6) one would have to reinstall rjb, so that it uses the correct
> jdk
> > > > > header files?
> > > > >
> > > > > Cheers,
> > > > > Martin
> > > > >
> > > > >
> > > > > On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
> > > > > > If it makes you feel any better, the problem is with RJB and not
> > > Buildr
> > > > > > itself. However, that doesn't change anything about user
> > > perception...
> > > > > >
> > > > > > To be honest, I'm with you on this one. I would much rather run
> > > Buildr
> > > > > > under MRI, or really *any* Ruby implementation other than JRuby.
> > > Don't
> > > > > get
> > > > > > me wrong, I love the JRuby project, but a tool like Buildr lives
> and
> > > dies
> > > > > by
> > > > > > startup time, an area where JRuby does very poorly. One option
> which
> > > > > might
> > > > > > work on Mac OS X (one which I haven't tried) is to use SoyLatte
> 32bit
> > > (
> > > > > >
> > > > >
> > >
> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> > > > > ).
> > > > > > Note that if you take this route, you will need to do more than
> just
> > > set
> > > > > > JAVA_HOME and the PATH, you will need to actually symlink
> > > > > >
> > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
> > > > > to
> > > > > > the correct directory within SoyLatte, and then
> > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK
> to
> > > > > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte.
> Crazy
> > > > > Apple
> > > > > > VM layout...
> > > > > >
> > > > > > As for running Buildr with Java 6 on other platforms, like Linux
> or
> > > > > Windows,
> > > > > > I've actually had a lot more success along those lines. To be
> > > honest,
> > > > > I've
> > > > > > never had it segfault on Windows, and on Linux only when RJB has
> been
> > > > > > incorrectly compiled/linked. So, the main trouble is Mac, and as
> the
> > > > > > "Common Problems and Solutions" document states, the trouble is
> 32bit
> > > MRI
> > > > > > mixing with 64bit Java. The only possible solution I can see
> here is
> > > to
> > > > > > create an entirely new Ruby-Java bridge based on sockets.
> Obviously,
> > > > > this
> > > > > > isn't a viable option (unless someone wants to volunteer?).
> > > > > >
> > > > > > So, that brings us back to square one. I don't know what else to
> say
> > > at
> > > > > > this point, we really have tried a lot of different solutions to
> this
> > > > > > problem, none of which have worked terribly well.
> > > > > >
> > > > > > Daniel
> > > > > >
> > > > > > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> > > > > > martin.grotzke@javakaffee.de> wrote:
> > > > > >
> > > > > > > Hi,
> > > > > > >
> > > > > > > I just want to address the issue, that with java 6 there can
> occur
> > > > > > > segfaults from time to time. The advice ([1]) is to go back to
> java
> > > 5
> > > > > or
> > > > > > > to use jruby. Both solution are not ideal IMHO. java 5 might
> not be
> > > an
> > > > > > > option as there are already projects that require java 6, and
> jruby
> > > is
> > > > > > > not ideal as it has longer startup times of buildr. Therefore,
> from
> > > my
> > > > > > > point of view, running buildr "natively" is the best option and
> if
> > > it's
> > > > > > > required with java 6.
> > > > > > >
> > > > > > > For new users this might be an issue that causes a loss of
> trust in
> > > > > > > buildr and the stable build.
> > > > > > >
> > > > > > > Do you also think that this issue should be addressed and
> > > eliminated?
> > > > > > >
> > > > > > > Are you aware of any reasons that might cause the segmentation
> > > faults?
> > > > > > >
> > > > > > > I have also a concrete example (from one of my colleagues) with
> a
> > > > > > > segmentation fault. That's a part from the build output:
> > > > > > >
> > > > > > > $ buildr clean; buildr -t
> > > > > > > ...
> > > > > > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26
> > > +0200
> > > > > 2009
> > > > > > > (/home/philip/projects/final-folder/buildfile). Last successful
> > > test
> > > > > run:
> > > > > > > <EARLY TIME>.
> > > > > > > ** Invoke ff:core:test (first_time)
> > > > > > > ** Invoke /home/philip/projects/final-folder/buildfile
> (not_needed)
> > > > > > > ** Invoke ff:core:test:compile (first_time)
> > > > > > > ** Invoke ff:core:compile (not_needed)
> > > > > > > ** Invoke ff:core:test:resources (first_time)
> > > > > > > ** Execute ff:core:test:resources
> > > > > > > ** Invoke
> > > /home/philip/projects/final-folder/core/target/test/resources
> > > > > > > (first_time)
> > > > > > > ** Execute
> > > > > /home/philip/projects/final-folder/core/target/test/resources
> > > > > > > Segmentation fault
> > > > > > >
> > > > > > > This is caused by the invocation of just buildr (without any
> task),
> > > if
> > > > > > > buildr is invoked with a task (e.g. build, compile or test)
> there's
> > > no
> > > > > > > segementation fault.
> > > > > > >
> > > > > > > This are the versions of buildr, ruby and java:
> > > > > > > Java: 1.6.0_14
> > > > > > > Ruby: 1.8.7
> > > > > > > Buildr: 1.3.4
> > > > > > >
> > > > > > > If that's also the case for other users, a first workaround
> might
> > > be
> > > > > not
> > > > > > > to promote the invocation of just "buildr", but instead say
> that
> > > > > "buildr
> > > > > > > build" should be run.
> > > > > > >
> > > > > > > What do you think?
> > > > > > >
> > > > > > > Thanx && cheers,
> > > > > > > Martin
> > > > > > >
> > > > > > >
> > > > > > > [1]
> > > > > > >
> > > > >
> > >
> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> > > > > > >
> > > > > > >
> > > > > > >
> > > > >
> > >
>
Re: segfaults with java 6
Posted by Martin Grotzke <ma...@javakaffee.de>.
On Sat, 2009-08-01 at 23:14 -0500, Daniel Spiewak wrote:
> Minor versions should be ok, though I would be careful going between 1.6.0
> and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly not sure
> that switching between JDKs is a particularly common use-case. It's really
> annoying that RJB is like this, but I don't see any other way as long as the
> bridge is using JNI under the surface.
In our company this is a common use case, as lots of developers are
working on several projects that use different jvm versions - depending
on the client, app server, project infrastructure etc.
>
> Another (possibly better) option would be to run Java in a sub-process
> spawned by Ruby with socket communication between the two. This would
> prevent incompatibility mismatch and cut the tight coupling to JVM
> installations. The main downside to this is that no one has done anything
> like this (to my knowledge), so it's not a pre-existing (stable) solution
> like RJB. The immediate advantage to such a solution though is that it
> would allow us to finally support Buildr on MRI with Java 6 on Mac.
Puh, sound rather robust but also as if this would require huge amounts
of work.
Now I also addressed this in the rjb forum:
http://rubyforge.org/forum/forum.php?thread_id=45030&forum_id=8190
Cheers,
Martin
>
> Daniel
>
> On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke <martin.grotzke@javakaffee.de
> > wrote:
>
> > D'oh, no good news. What about switching between minor versions, e.g.
> > from 1.6.0_03 to 1.6.0_14?
> >
> > Wouldn't it be good to be able to have several rjb versions running in
> > parallel, and to switch them with s.th. like alternatives? (the rjb
> > version then would have to include the used/linked jdk version, s.th.
> > like <rjbversion-jdkversion>).
> >
> > Cheers,
> > Martin
> >
> >
> > On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
> > > Yes, it does.
> > >
> > > Daniel
> > >
> > > On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <
> > martin.grotzke@javakaffee.de
> > > > wrote:
> > >
> > > > Does this mean, that when one switches the current jvm (e.g. from 1.5
> > to
> > > > 1.6) one would have to reinstall rjb, so that it uses the correct jdk
> > > > header files?
> > > >
> > > > Cheers,
> > > > Martin
> > > >
> > > >
> > > > On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
> > > > > If it makes you feel any better, the problem is with RJB and not
> > Buildr
> > > > > itself. However, that doesn't change anything about user
> > perception...
> > > > >
> > > > > To be honest, I'm with you on this one. I would much rather run
> > Buildr
> > > > > under MRI, or really *any* Ruby implementation other than JRuby.
> > Don't
> > > > get
> > > > > me wrong, I love the JRuby project, but a tool like Buildr lives and
> > dies
> > > > by
> > > > > startup time, an area where JRuby does very poorly. One option which
> > > > might
> > > > > work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit
> > (
> > > > >
> > > >
> > http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> > > > ).
> > > > > Note that if you take this route, you will need to do more than just
> > set
> > > > > JAVA_HOME and the PATH, you will need to actually symlink
> > > > >
> > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
> > > > to
> > > > > the correct directory within SoyLatte, and then
> > > > > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
> > > > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy
> > > > Apple
> > > > > VM layout...
> > > > >
> > > > > As for running Buildr with Java 6 on other platforms, like Linux or
> > > > Windows,
> > > > > I've actually had a lot more success along those lines. To be
> > honest,
> > > > I've
> > > > > never had it segfault on Windows, and on Linux only when RJB has been
> > > > > incorrectly compiled/linked. So, the main trouble is Mac, and as the
> > > > > "Common Problems and Solutions" document states, the trouble is 32bit
> > MRI
> > > > > mixing with 64bit Java. The only possible solution I can see here is
> > to
> > > > > create an entirely new Ruby-Java bridge based on sockets. Obviously,
> > > > this
> > > > > isn't a viable option (unless someone wants to volunteer?).
> > > > >
> > > > > So, that brings us back to square one. I don't know what else to say
> > at
> > > > > this point, we really have tried a lot of different solutions to this
> > > > > problem, none of which have worked terribly well.
> > > > >
> > > > > Daniel
> > > > >
> > > > > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> > > > > martin.grotzke@javakaffee.de> wrote:
> > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I just want to address the issue, that with java 6 there can occur
> > > > > > segfaults from time to time. The advice ([1]) is to go back to java
> > 5
> > > > or
> > > > > > to use jruby. Both solution are not ideal IMHO. java 5 might not be
> > an
> > > > > > option as there are already projects that require java 6, and jruby
> > is
> > > > > > not ideal as it has longer startup times of buildr. Therefore, from
> > my
> > > > > > point of view, running buildr "natively" is the best option and if
> > it's
> > > > > > required with java 6.
> > > > > >
> > > > > > For new users this might be an issue that causes a loss of trust in
> > > > > > buildr and the stable build.
> > > > > >
> > > > > > Do you also think that this issue should be addressed and
> > eliminated?
> > > > > >
> > > > > > Are you aware of any reasons that might cause the segmentation
> > faults?
> > > > > >
> > > > > > I have also a concrete example (from one of my colleagues) with a
> > > > > > segmentation fault. That's a part from the build output:
> > > > > >
> > > > > > $ buildr clean; buildr -t
> > > > > > ...
> > > > > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26
> > +0200
> > > > 2009
> > > > > > (/home/philip/projects/final-folder/buildfile). Last successful
> > test
> > > > run:
> > > > > > <EARLY TIME>.
> > > > > > ** Invoke ff:core:test (first_time)
> > > > > > ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> > > > > > ** Invoke ff:core:test:compile (first_time)
> > > > > > ** Invoke ff:core:compile (not_needed)
> > > > > > ** Invoke ff:core:test:resources (first_time)
> > > > > > ** Execute ff:core:test:resources
> > > > > > ** Invoke
> > /home/philip/projects/final-folder/core/target/test/resources
> > > > > > (first_time)
> > > > > > ** Execute
> > > > /home/philip/projects/final-folder/core/target/test/resources
> > > > > > Segmentation fault
> > > > > >
> > > > > > This is caused by the invocation of just buildr (without any task),
> > if
> > > > > > buildr is invoked with a task (e.g. build, compile or test) there's
> > no
> > > > > > segementation fault.
> > > > > >
> > > > > > This are the versions of buildr, ruby and java:
> > > > > > Java: 1.6.0_14
> > > > > > Ruby: 1.8.7
> > > > > > Buildr: 1.3.4
> > > > > >
> > > > > > If that's also the case for other users, a first workaround might
> > be
> > > > not
> > > > > > to promote the invocation of just "buildr", but instead say that
> > > > "buildr
> > > > > > build" should be run.
> > > > > >
> > > > > > What do you think?
> > > > > >
> > > > > > Thanx && cheers,
> > > > > > Martin
> > > > > >
> > > > > >
> > > > > > [1]
> > > > > >
> > > >
> > http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> > > > > >
> > > > > >
> > > > > >
> > > >
> >
Re: segfaults with java 6
Posted by Daniel Spiewak <dj...@gmail.com>.
Minor versions should be ok, though I would be careful going between 1.6.0
and 1.6.0_10 (or _03 and _14 as in your example). I'm honestly not sure
that switching between JDKs is a particularly common use-case. It's really
annoying that RJB is like this, but I don't see any other way as long as the
bridge is using JNI under the surface.
Another (possibly better) option would be to run Java in a sub-process
spawned by Ruby with socket communication between the two. This would
prevent incompatibility mismatch and cut the tight coupling to JVM
installations. The main downside to this is that no one has done anything
like this (to my knowledge), so it's not a pre-existing (stable) solution
like RJB. The immediate advantage to such a solution though is that it
would allow us to finally support Buildr on MRI with Java 6 on Mac.
Daniel
On Sat, Aug 1, 2009 at 6:35 PM, Martin Grotzke <martin.grotzke@javakaffee.de
> wrote:
> D'oh, no good news. What about switching between minor versions, e.g.
> from 1.6.0_03 to 1.6.0_14?
>
> Wouldn't it be good to be able to have several rjb versions running in
> parallel, and to switch them with s.th. like alternatives? (the rjb
> version then would have to include the used/linked jdk version, s.th.
> like <rjbversion-jdkversion>).
>
> Cheers,
> Martin
>
>
> On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
> > Yes, it does.
> >
> > Daniel
> >
> > On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <
> martin.grotzke@javakaffee.de
> > > wrote:
> >
> > > Does this mean, that when one switches the current jvm (e.g. from 1.5
> to
> > > 1.6) one would have to reinstall rjb, so that it uses the correct jdk
> > > header files?
> > >
> > > Cheers,
> > > Martin
> > >
> > >
> > > On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
> > > > If it makes you feel any better, the problem is with RJB and not
> Buildr
> > > > itself. However, that doesn't change anything about user
> perception...
> > > >
> > > > To be honest, I'm with you on this one. I would much rather run
> Buildr
> > > > under MRI, or really *any* Ruby implementation other than JRuby.
> Don't
> > > get
> > > > me wrong, I love the JRuby project, but a tool like Buildr lives and
> dies
> > > by
> > > > startup time, an area where JRuby does very poorly. One option which
> > > might
> > > > work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit
> (
> > > >
> > >
> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> > > ).
> > > > Note that if you take this route, you will need to do more than just
> set
> > > > JAVA_HOME and the PATH, you will need to actually symlink
> > > >
> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
> > > to
> > > > the correct directory within SoyLatte, and then
> > > > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
> > > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy
> > > Apple
> > > > VM layout...
> > > >
> > > > As for running Buildr with Java 6 on other platforms, like Linux or
> > > Windows,
> > > > I've actually had a lot more success along those lines. To be
> honest,
> > > I've
> > > > never had it segfault on Windows, and on Linux only when RJB has been
> > > > incorrectly compiled/linked. So, the main trouble is Mac, and as the
> > > > "Common Problems and Solutions" document states, the trouble is 32bit
> MRI
> > > > mixing with 64bit Java. The only possible solution I can see here is
> to
> > > > create an entirely new Ruby-Java bridge based on sockets. Obviously,
> > > this
> > > > isn't a viable option (unless someone wants to volunteer?).
> > > >
> > > > So, that brings us back to square one. I don't know what else to say
> at
> > > > this point, we really have tried a lot of different solutions to this
> > > > problem, none of which have worked terribly well.
> > > >
> > > > Daniel
> > > >
> > > > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> > > > martin.grotzke@javakaffee.de> wrote:
> > > >
> > > > > Hi,
> > > > >
> > > > > I just want to address the issue, that with java 6 there can occur
> > > > > segfaults from time to time. The advice ([1]) is to go back to java
> 5
> > > or
> > > > > to use jruby. Both solution are not ideal IMHO. java 5 might not be
> an
> > > > > option as there are already projects that require java 6, and jruby
> is
> > > > > not ideal as it has longer startup times of buildr. Therefore, from
> my
> > > > > point of view, running buildr "natively" is the best option and if
> it's
> > > > > required with java 6.
> > > > >
> > > > > For new users this might be an issue that causes a loss of trust in
> > > > > buildr and the stable build.
> > > > >
> > > > > Do you also think that this issue should be addressed and
> eliminated?
> > > > >
> > > > > Are you aware of any reasons that might cause the segmentation
> faults?
> > > > >
> > > > > I have also a concrete example (from one of my colleagues) with a
> > > > > segmentation fault. That's a part from the build output:
> > > > >
> > > > > $ buildr clean; buildr -t
> > > > > ...
> > > > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26
> +0200
> > > 2009
> > > > > (/home/philip/projects/final-folder/buildfile). Last successful
> test
> > > run:
> > > > > <EARLY TIME>.
> > > > > ** Invoke ff:core:test (first_time)
> > > > > ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> > > > > ** Invoke ff:core:test:compile (first_time)
> > > > > ** Invoke ff:core:compile (not_needed)
> > > > > ** Invoke ff:core:test:resources (first_time)
> > > > > ** Execute ff:core:test:resources
> > > > > ** Invoke
> /home/philip/projects/final-folder/core/target/test/resources
> > > > > (first_time)
> > > > > ** Execute
> > > /home/philip/projects/final-folder/core/target/test/resources
> > > > > Segmentation fault
> > > > >
> > > > > This is caused by the invocation of just buildr (without any task),
> if
> > > > > buildr is invoked with a task (e.g. build, compile or test) there's
> no
> > > > > segementation fault.
> > > > >
> > > > > This are the versions of buildr, ruby and java:
> > > > > Java: 1.6.0_14
> > > > > Ruby: 1.8.7
> > > > > Buildr: 1.3.4
> > > > >
> > > > > If that's also the case for other users, a first workaround might
> be
> > > not
> > > > > to promote the invocation of just "buildr", but instead say that
> > > "buildr
> > > > > build" should be run.
> > > > >
> > > > > What do you think?
> > > > >
> > > > > Thanx && cheers,
> > > > > Martin
> > > > >
> > > > >
> > > > > [1]
> > > > >
> > >
> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> > > > >
> > > > >
> > > > >
> > >
>
Re: segfaults with java 6
Posted by Martin Grotzke <ma...@javakaffee.de>.
D'oh, no good news. What about switching between minor versions, e.g.
from 1.6.0_03 to 1.6.0_14?
Wouldn't it be good to be able to have several rjb versions running in
parallel, and to switch them with s.th. like alternatives? (the rjb
version then would have to include the used/linked jdk version, s.th.
like <rjbversion-jdkversion>).
Cheers,
Martin
On Sat, 2009-08-01 at 16:37 -0500, Daniel Spiewak wrote:
> Yes, it does.
>
> Daniel
>
> On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <martin.grotzke@javakaffee.de
> > wrote:
>
> > Does this mean, that when one switches the current jvm (e.g. from 1.5 to
> > 1.6) one would have to reinstall rjb, so that it uses the correct jdk
> > header files?
> >
> > Cheers,
> > Martin
> >
> >
> > On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
> > > If it makes you feel any better, the problem is with RJB and not Buildr
> > > itself. However, that doesn't change anything about user perception...
> > >
> > > To be honest, I'm with you on this one. I would much rather run Buildr
> > > under MRI, or really *any* Ruby implementation other than JRuby. Don't
> > get
> > > me wrong, I love the JRuby project, but a tool like Buildr lives and dies
> > by
> > > startup time, an area where JRuby does very poorly. One option which
> > might
> > > work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit (
> > >
> > http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> > ).
> > > Note that if you take this route, you will need to do more than just set
> > > JAVA_HOME and the PATH, you will need to actually symlink
> > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
> > to
> > > the correct directory within SoyLatte, and then
> > > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
> > > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy
> > Apple
> > > VM layout...
> > >
> > > As for running Buildr with Java 6 on other platforms, like Linux or
> > Windows,
> > > I've actually had a lot more success along those lines. To be honest,
> > I've
> > > never had it segfault on Windows, and on Linux only when RJB has been
> > > incorrectly compiled/linked. So, the main trouble is Mac, and as the
> > > "Common Problems and Solutions" document states, the trouble is 32bit MRI
> > > mixing with 64bit Java. The only possible solution I can see here is to
> > > create an entirely new Ruby-Java bridge based on sockets. Obviously,
> > this
> > > isn't a viable option (unless someone wants to volunteer?).
> > >
> > > So, that brings us back to square one. I don't know what else to say at
> > > this point, we really have tried a lot of different solutions to this
> > > problem, none of which have worked terribly well.
> > >
> > > Daniel
> > >
> > > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> > > martin.grotzke@javakaffee.de> wrote:
> > >
> > > > Hi,
> > > >
> > > > I just want to address the issue, that with java 6 there can occur
> > > > segfaults from time to time. The advice ([1]) is to go back to java 5
> > or
> > > > to use jruby. Both solution are not ideal IMHO. java 5 might not be an
> > > > option as there are already projects that require java 6, and jruby is
> > > > not ideal as it has longer startup times of buildr. Therefore, from my
> > > > point of view, running buildr "natively" is the best option and if it's
> > > > required with java 6.
> > > >
> > > > For new users this might be an issue that causes a loss of trust in
> > > > buildr and the stable build.
> > > >
> > > > Do you also think that this issue should be addressed and eliminated?
> > > >
> > > > Are you aware of any reasons that might cause the segmentation faults?
> > > >
> > > > I have also a concrete example (from one of my colleagues) with a
> > > > segmentation fault. That's a part from the build output:
> > > >
> > > > $ buildr clean; buildr -t
> > > > ...
> > > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 +0200
> > 2009
> > > > (/home/philip/projects/final-folder/buildfile). Last successful test
> > run:
> > > > <EARLY TIME>.
> > > > ** Invoke ff:core:test (first_time)
> > > > ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> > > > ** Invoke ff:core:test:compile (first_time)
> > > > ** Invoke ff:core:compile (not_needed)
> > > > ** Invoke ff:core:test:resources (first_time)
> > > > ** Execute ff:core:test:resources
> > > > ** Invoke /home/philip/projects/final-folder/core/target/test/resources
> > > > (first_time)
> > > > ** Execute
> > /home/philip/projects/final-folder/core/target/test/resources
> > > > Segmentation fault
> > > >
> > > > This is caused by the invocation of just buildr (without any task), if
> > > > buildr is invoked with a task (e.g. build, compile or test) there's no
> > > > segementation fault.
> > > >
> > > > This are the versions of buildr, ruby and java:
> > > > Java: 1.6.0_14
> > > > Ruby: 1.8.7
> > > > Buildr: 1.3.4
> > > >
> > > > If that's also the case for other users, a first workaround might be
> > not
> > > > to promote the invocation of just "buildr", but instead say that
> > "buildr
> > > > build" should be run.
> > > >
> > > > What do you think?
> > > >
> > > > Thanx && cheers,
> > > > Martin
> > > >
> > > >
> > > > [1]
> > > >
> > http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> > > >
> > > >
> > > >
> >
Re: segfaults with java 6
Posted by Daniel Spiewak <dj...@gmail.com>.
Yes, it does.
Daniel
On Sat, Aug 1, 2009 at 4:20 PM, Martin Grotzke <martin.grotzke@javakaffee.de
> wrote:
> Does this mean, that when one switches the current jvm (e.g. from 1.5 to
> 1.6) one would have to reinstall rjb, so that it uses the correct jdk
> header files?
>
> Cheers,
> Martin
>
>
> On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
> > If it makes you feel any better, the problem is with RJB and not Buildr
> > itself. However, that doesn't change anything about user perception...
> >
> > To be honest, I'm with you on this one. I would much rather run Buildr
> > under MRI, or really *any* Ruby implementation other than JRuby. Don't
> get
> > me wrong, I love the JRuby project, but a tool like Buildr lives and dies
> by
> > startup time, an area where JRuby does very poorly. One option which
> might
> > work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit (
> >
> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> ).
> > Note that if you take this route, you will need to do more than just set
> > JAVA_HOME and the PATH, you will need to actually symlink
> > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries
> to
> > the correct directory within SoyLatte, and then
> > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
> > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy
> Apple
> > VM layout...
> >
> > As for running Buildr with Java 6 on other platforms, like Linux or
> Windows,
> > I've actually had a lot more success along those lines. To be honest,
> I've
> > never had it segfault on Windows, and on Linux only when RJB has been
> > incorrectly compiled/linked. So, the main trouble is Mac, and as the
> > "Common Problems and Solutions" document states, the trouble is 32bit MRI
> > mixing with 64bit Java. The only possible solution I can see here is to
> > create an entirely new Ruby-Java bridge based on sockets. Obviously,
> this
> > isn't a viable option (unless someone wants to volunteer?).
> >
> > So, that brings us back to square one. I don't know what else to say at
> > this point, we really have tried a lot of different solutions to this
> > problem, none of which have worked terribly well.
> >
> > Daniel
> >
> > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> > martin.grotzke@javakaffee.de> wrote:
> >
> > > Hi,
> > >
> > > I just want to address the issue, that with java 6 there can occur
> > > segfaults from time to time. The advice ([1]) is to go back to java 5
> or
> > > to use jruby. Both solution are not ideal IMHO. java 5 might not be an
> > > option as there are already projects that require java 6, and jruby is
> > > not ideal as it has longer startup times of buildr. Therefore, from my
> > > point of view, running buildr "natively" is the best option and if it's
> > > required with java 6.
> > >
> > > For new users this might be an issue that causes a loss of trust in
> > > buildr and the stable build.
> > >
> > > Do you also think that this issue should be addressed and eliminated?
> > >
> > > Are you aware of any reasons that might cause the segmentation faults?
> > >
> > > I have also a concrete example (from one of my colleagues) with a
> > > segmentation fault. That's a part from the build output:
> > >
> > > $ buildr clean; buildr -t
> > > ...
> > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 +0200
> 2009
> > > (/home/philip/projects/final-folder/buildfile). Last successful test
> run:
> > > <EARLY TIME>.
> > > ** Invoke ff:core:test (first_time)
> > > ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> > > ** Invoke ff:core:test:compile (first_time)
> > > ** Invoke ff:core:compile (not_needed)
> > > ** Invoke ff:core:test:resources (first_time)
> > > ** Execute ff:core:test:resources
> > > ** Invoke /home/philip/projects/final-folder/core/target/test/resources
> > > (first_time)
> > > ** Execute
> /home/philip/projects/final-folder/core/target/test/resources
> > > Segmentation fault
> > >
> > > This is caused by the invocation of just buildr (without any task), if
> > > buildr is invoked with a task (e.g. build, compile or test) there's no
> > > segementation fault.
> > >
> > > This are the versions of buildr, ruby and java:
> > > Java: 1.6.0_14
> > > Ruby: 1.8.7
> > > Buildr: 1.3.4
> > >
> > > If that's also the case for other users, a first workaround might be
> not
> > > to promote the invocation of just "buildr", but instead say that
> "buildr
> > > build" should be run.
> > >
> > > What do you think?
> > >
> > > Thanx && cheers,
> > > Martin
> > >
> > >
> > > [1]
> > >
> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> > >
> > >
> > >
>
Re: segfaults with java 6
Posted by Martin Grotzke <ma...@javakaffee.de>.
Does this mean, that when one switches the current jvm (e.g. from 1.5 to
1.6) one would have to reinstall rjb, so that it uses the correct jdk
header files?
Cheers,
Martin
On Thu, 2009-07-30 at 08:58 -0500, Daniel Spiewak wrote:
> If it makes you feel any better, the problem is with RJB and not Buildr
> itself. However, that doesn't change anything about user perception...
>
> To be honest, I'm with you on this one. I would much rather run Buildr
> under MRI, or really *any* Ruby implementation other than JRuby. Don't get
> me wrong, I love the JRuby project, but a tool like Buildr lives and dies by
> startup time, an area where JRuby does very poorly. One option which might
> work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit (
> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2).
> Note that if you take this route, you will need to do more than just set
> JAVA_HOME and the PATH, you will need to actually symlink
> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries to
> the correct directory within SoyLatte, and then
> /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy Apple
> VM layout...
>
> As for running Buildr with Java 6 on other platforms, like Linux or Windows,
> I've actually had a lot more success along those lines. To be honest, I've
> never had it segfault on Windows, and on Linux only when RJB has been
> incorrectly compiled/linked. So, the main trouble is Mac, and as the
> "Common Problems and Solutions" document states, the trouble is 32bit MRI
> mixing with 64bit Java. The only possible solution I can see here is to
> create an entirely new Ruby-Java bridge based on sockets. Obviously, this
> isn't a viable option (unless someone wants to volunteer?).
>
> So, that brings us back to square one. I don't know what else to say at
> this point, we really have tried a lot of different solutions to this
> problem, none of which have worked terribly well.
>
> Daniel
>
> On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> martin.grotzke@javakaffee.de> wrote:
>
> > Hi,
> >
> > I just want to address the issue, that with java 6 there can occur
> > segfaults from time to time. The advice ([1]) is to go back to java 5 or
> > to use jruby. Both solution are not ideal IMHO. java 5 might not be an
> > option as there are already projects that require java 6, and jruby is
> > not ideal as it has longer startup times of buildr. Therefore, from my
> > point of view, running buildr "natively" is the best option and if it's
> > required with java 6.
> >
> > For new users this might be an issue that causes a loss of trust in
> > buildr and the stable build.
> >
> > Do you also think that this issue should be addressed and eliminated?
> >
> > Are you aware of any reasons that might cause the segmentation faults?
> >
> > I have also a concrete example (from one of my colleagues) with a
> > segmentation fault. That's a part from the build output:
> >
> > $ buildr clean; buildr -t
> > ...
> > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 +0200 2009
> > (/home/philip/projects/final-folder/buildfile). Last successful test run:
> > <EARLY TIME>.
> > ** Invoke ff:core:test (first_time)
> > ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> > ** Invoke ff:core:test:compile (first_time)
> > ** Invoke ff:core:compile (not_needed)
> > ** Invoke ff:core:test:resources (first_time)
> > ** Execute ff:core:test:resources
> > ** Invoke /home/philip/projects/final-folder/core/target/test/resources
> > (first_time)
> > ** Execute /home/philip/projects/final-folder/core/target/test/resources
> > Segmentation fault
> >
> > This is caused by the invocation of just buildr (without any task), if
> > buildr is invoked with a task (e.g. build, compile or test) there's no
> > segementation fault.
> >
> > This are the versions of buildr, ruby and java:
> > Java: 1.6.0_14
> > Ruby: 1.8.7
> > Buildr: 1.3.4
> >
> > If that's also the case for other users, a first workaround might be not
> > to promote the invocation of just "buildr", but instead say that "buildr
> > build" should be run.
> >
> > What do you think?
> >
> > Thanx && cheers,
> > Martin
> >
> >
> > [1]
> > http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> >
> >
> >
Re: segfaults with java 6
Posted by Martin Grotzke <ma...@javakaffee.de>.
Ok, we try to produce a small reproducable case.
Cheers,
Martin
On Thu, 2009-07-30 at 07:13 -0700, Alex Boisvert wrote:
> What's required to fix this issue is somebody who's fairly knowledgeable
> about C/C++ who can dig into RJB and pinpoint the bug, probably using a
> combination of core dump analysis and interactive debugger to step through
> the Ruby -> RJB -> JDK invocation chain.
>
> Having a fairly small reproducible case for the segfault would also help so
> if you have one please file it in Jira.
>
> alex
>
> On Thu, Jul 30, 2009 at 6:58 AM, Daniel Spiewak <dj...@gmail.com> wrote:
>
> > If it makes you feel any better, the problem is with RJB and not Buildr
> > itself. However, that doesn't change anything about user perception...
> >
> > To be honest, I'm with you on this one. I would much rather run Buildr
> > under MRI, or really *any* Ruby implementation other than JRuby. Don't get
> > me wrong, I love the JRuby project, but a tool like Buildr lives and dies
> > by
> > startup time, an area where JRuby does very poorly. One option which might
> > work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit (
> >
> > http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> > ).
> > Note that if you take this route, you will need to do more than just set
> > JAVA_HOME and the PATH, you will need to actually symlink
> > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries to
> > the correct directory within SoyLatte, and then
> > /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
> > /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy Apple
> > VM layout...
> >
> > As for running Buildr with Java 6 on other platforms, like Linux or
> > Windows,
> > I've actually had a lot more success along those lines. To be honest, I've
> > never had it segfault on Windows, and on Linux only when RJB has been
> > incorrectly compiled/linked. So, the main trouble is Mac, and as the
> > "Common Problems and Solutions" document states, the trouble is 32bit MRI
> > mixing with 64bit Java. The only possible solution I can see here is to
> > create an entirely new Ruby-Java bridge based on sockets. Obviously, this
> > isn't a viable option (unless someone wants to volunteer?).
> >
> > So, that brings us back to square one. I don't know what else to say at
> > this point, we really have tried a lot of different solutions to this
> > problem, none of which have worked terribly well.
> >
> > Daniel
> >
> > On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> > martin.grotzke@javakaffee.de> wrote:
> >
> > > Hi,
> > >
> > > I just want to address the issue, that with java 6 there can occur
> > > segfaults from time to time. The advice ([1]) is to go back to java 5 or
> > > to use jruby. Both solution are not ideal IMHO. java 5 might not be an
> > > option as there are already projects that require java 6, and jruby is
> > > not ideal as it has longer startup times of buildr. Therefore, from my
> > > point of view, running buildr "natively" is the best option and if it's
> > > required with java 6.
> > >
> > > For new users this might be an issue that causes a loss of trust in
> > > buildr and the stable build.
> > >
> > > Do you also think that this issue should be addressed and eliminated?
> > >
> > > Are you aware of any reasons that might cause the segmentation faults?
> > >
> > > I have also a concrete example (from one of my colleagues) with a
> > > segmentation fault. That's a part from the build output:
> > >
> > > $ buildr clean; buildr -t
> > > ...
> > > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 +0200 2009
> > > (/home/philip/projects/final-folder/buildfile). Last successful test run:
> > > <EARLY TIME>.
> > > ** Invoke ff:core:test (first_time)
> > > ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> > > ** Invoke ff:core:test:compile (first_time)
> > > ** Invoke ff:core:compile (not_needed)
> > > ** Invoke ff:core:test:resources (first_time)
> > > ** Execute ff:core:test:resources
> > > ** Invoke /home/philip/projects/final-folder/core/target/test/resources
> > > (first_time)
> > > ** Execute /home/philip/projects/final-folder/core/target/test/resources
> > > Segmentation fault
> > >
> > > This is caused by the invocation of just buildr (without any task), if
> > > buildr is invoked with a task (e.g. build, compile or test) there's no
> > > segementation fault.
> > >
> > > This are the versions of buildr, ruby and java:
> > > Java: 1.6.0_14
> > > Ruby: 1.8.7
> > > Buildr: 1.3.4
> > >
> > > If that's also the case for other users, a first workaround might be not
> > > to promote the invocation of just "buildr", but instead say that "buildr
> > > build" should be run.
> > >
> > > What do you think?
> > >
> > > Thanx && cheers,
> > > Martin
> > >
> > >
> > > [1]
> > >
> > http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> > >
> > >
> > >
> >
Re: segfaults with java 6
Posted by Alex Boisvert <bo...@intalio.com>.
What's required to fix this issue is somebody who's fairly knowledgeable
about C/C++ who can dig into RJB and pinpoint the bug, probably using a
combination of core dump analysis and interactive debugger to step through
the Ruby -> RJB -> JDK invocation chain.
Having a fairly small reproducible case for the segfault would also help so
if you have one please file it in Jira.
alex
On Thu, Jul 30, 2009 at 6:58 AM, Daniel Spiewak <dj...@gmail.com> wrote:
> If it makes you feel any better, the problem is with RJB and not Buildr
> itself. However, that doesn't change anything about user perception...
>
> To be honest, I'm with you on this one. I would much rather run Buildr
> under MRI, or really *any* Ruby implementation other than JRuby. Don't get
> me wrong, I love the JRuby project, but a tool like Buildr lives and dies
> by
> startup time, an area where JRuby does very poorly. One option which might
> work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit (
>
> http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2
> ).
> Note that if you take this route, you will need to do more than just set
> JAVA_HOME and the PATH, you will need to actually symlink
> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries to
> the correct directory within SoyLatte, and then
> /System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
> /System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy Apple
> VM layout...
>
> As for running Buildr with Java 6 on other platforms, like Linux or
> Windows,
> I've actually had a lot more success along those lines. To be honest, I've
> never had it segfault on Windows, and on Linux only when RJB has been
> incorrectly compiled/linked. So, the main trouble is Mac, and as the
> "Common Problems and Solutions" document states, the trouble is 32bit MRI
> mixing with 64bit Java. The only possible solution I can see here is to
> create an entirely new Ruby-Java bridge based on sockets. Obviously, this
> isn't a viable option (unless someone wants to volunteer?).
>
> So, that brings us back to square one. I don't know what else to say at
> this point, we really have tried a lot of different solutions to this
> problem, none of which have worked terribly well.
>
> Daniel
>
> On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
> martin.grotzke@javakaffee.de> wrote:
>
> > Hi,
> >
> > I just want to address the issue, that with java 6 there can occur
> > segfaults from time to time. The advice ([1]) is to go back to java 5 or
> > to use jruby. Both solution are not ideal IMHO. java 5 might not be an
> > option as there are already projects that require java 6, and jruby is
> > not ideal as it has longer startup times of buildr. Therefore, from my
> > point of view, running buildr "natively" is the best option and if it's
> > required with java 6.
> >
> > For new users this might be an issue that causes a loss of trust in
> > buildr and the stable build.
> >
> > Do you also think that this issue should be addressed and eliminated?
> >
> > Are you aware of any reasons that might cause the segmentation faults?
> >
> > I have also a concrete example (from one of my colleagues) with a
> > segmentation fault. That's a part from the build output:
> >
> > $ buildr clean; buildr -t
> > ...
> > Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 +0200 2009
> > (/home/philip/projects/final-folder/buildfile). Last successful test run:
> > <EARLY TIME>.
> > ** Invoke ff:core:test (first_time)
> > ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> > ** Invoke ff:core:test:compile (first_time)
> > ** Invoke ff:core:compile (not_needed)
> > ** Invoke ff:core:test:resources (first_time)
> > ** Execute ff:core:test:resources
> > ** Invoke /home/philip/projects/final-folder/core/target/test/resources
> > (first_time)
> > ** Execute /home/philip/projects/final-folder/core/target/test/resources
> > Segmentation fault
> >
> > This is caused by the invocation of just buildr (without any task), if
> > buildr is invoked with a task (e.g. build, compile or test) there's no
> > segementation fault.
> >
> > This are the versions of buildr, ruby and java:
> > Java: 1.6.0_14
> > Ruby: 1.8.7
> > Buildr: 1.3.4
> >
> > If that's also the case for other users, a first workaround might be not
> > to promote the invocation of just "buildr", but instead say that "buildr
> > build" should be run.
> >
> > What do you think?
> >
> > Thanx && cheers,
> > Martin
> >
> >
> > [1]
> >
> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
> >
> >
> >
>
Re: segfaults with java 6
Posted by Daniel Spiewak <dj...@gmail.com>.
If it makes you feel any better, the problem is with RJB and not Buildr
itself. However, that doesn't change anything about user perception...
To be honest, I'm with you on this one. I would much rather run Buildr
under MRI, or really *any* Ruby implementation other than JRuby. Don't get
me wrong, I love the JRuby project, but a tool like Buildr lives and dies by
startup time, an area where JRuby does very poorly. One option which might
work on Mac OS X (one which I haven't tried) is to use SoyLatte 32bit (
http://hg.bikemonkey.org/archive/javasrc_1_6_jrl_darwin/soylatte16-i386-1.0.3.tar.bz2).
Note that if you take this route, you will need to do more than just set
JAVA_HOME and the PATH, you will need to actually symlink
/System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte/Libraries to
the correct directory within SoyLatte, and then
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK to
/System/Library/Frameworks/JavaVM.framework/Versions/SoyLatte. Crazy Apple
VM layout...
As for running Buildr with Java 6 on other platforms, like Linux or Windows,
I've actually had a lot more success along those lines. To be honest, I've
never had it segfault on Windows, and on Linux only when RJB has been
incorrectly compiled/linked. So, the main trouble is Mac, and as the
"Common Problems and Solutions" document states, the trouble is 32bit MRI
mixing with 64bit Java. The only possible solution I can see here is to
create an entirely new Ruby-Java bridge based on sockets. Obviously, this
isn't a viable option (unless someone wants to volunteer?).
So, that brings us back to square one. I don't know what else to say at
this point, we really have tried a lot of different solutions to this
problem, none of which have worked terribly well.
Daniel
On Thu, Jul 30, 2009 at 7:00 AM, Martin Grotzke <
martin.grotzke@javakaffee.de> wrote:
> Hi,
>
> I just want to address the issue, that with java 6 there can occur
> segfaults from time to time. The advice ([1]) is to go back to java 5 or
> to use jruby. Both solution are not ideal IMHO. java 5 might not be an
> option as there are already projects that require java 6, and jruby is
> not ideal as it has longer startup times of buildr. Therefore, from my
> point of view, running buildr "natively" is the best option and if it's
> required with java 6.
>
> For new users this might be an issue that causes a loss of trust in
> buildr and the stable build.
>
> Do you also think that this issue should be addressed and eliminated?
>
> Are you aware of any reasons that might cause the segmentation faults?
>
> I have also a concrete example (from one of my colleagues) with a
> segmentation fault. That's a part from the build output:
>
> $ buildr clean; buildr -t
> ...
> Testing needed. Latest prerequisite change: Do Jul 30 10:59:26 +0200 2009
> (/home/philip/projects/final-folder/buildfile). Last successful test run:
> <EARLY TIME>.
> ** Invoke ff:core:test (first_time)
> ** Invoke /home/philip/projects/final-folder/buildfile (not_needed)
> ** Invoke ff:core:test:compile (first_time)
> ** Invoke ff:core:compile (not_needed)
> ** Invoke ff:core:test:resources (first_time)
> ** Execute ff:core:test:resources
> ** Invoke /home/philip/projects/final-folder/core/target/test/resources
> (first_time)
> ** Execute /home/philip/projects/final-folder/core/target/test/resources
> Segmentation fault
>
> This is caused by the invocation of just buildr (without any task), if
> buildr is invoked with a task (e.g. build, compile or test) there's no
> segementation fault.
>
> This are the versions of buildr, ruby and java:
> Java: 1.6.0_14
> Ruby: 1.8.7
> Buildr: 1.3.4
>
> If that's also the case for other users, a first workaround might be not
> to promote the invocation of just "buildr", but instead say that "buildr
> build" should be run.
>
> What do you think?
>
> Thanx && cheers,
> Martin
>
>
> [1]
> http://cwiki.apache.org/confluence/display/BUILDR/Common+Problems+and+Solutions
>
>
>