buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From peter schröder ...@blau.de>
Subject Re: segfaults with java 6
Date Mon, 03 Aug 2009 12:34:41 GMT
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<djspiewak@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


Mime
View raw message