buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <djspie...@gmail.com>
Subject Re: Buildr aborted with unknown exception in scala module
Date Fri, 21 Aug 2009 15:22:30 GMT
I'm guessing that this would be something related to the way that RJB
works.  JRuby is almost always more reliable when it comes to invoking Java
stuff, so that's the way I would go for a build server.  Actually, I'm
surprised I didn't think of that earlier!  The only disadvantage to using
JRuby is poor startup performance.  This isn't a problem on a build server,
and seeing that JRuby's long-run performance far outstrips MRI, you may
actually reap some build time improvements from the switch.

Daniel

On Fri, Aug 21, 2009 at 4:36 AM, Martin Grotzke <
martin.grotzke@javakaffee.de> wrote:

> Hi,
>
> our builds now are failing more often with "could not connect to
> compilation daemon" on our build server, it's getting a bigger issue for
> us as developers don't notice failed builds.
>
> So we tried several things and found out that the scala compiler doesn't
> crash when buildr is run using jruby. Any idea what's the reason for
> this?
>
> Cheers,
> Martin
>
>
> PS: I also tried increasing the thread stack size using -Xss and/or
> -XX:ThreadStackSize, but this didn't help.
>
>
> On Fri, 2009-08-07 at 14:07 -0500, Daniel Spiewak wrote:
> > >
> > > Why wouldn't you recommend to use fsc?
> >
> >
> > FSC is designed to be solely used as a time saver during local
> development
> > (saving on VM startup and classloading time).  To do this, it keeps a lot
> of
> > stuff floating in a cache.  The danger with this approach is it sometimes
> > leads to very strange stale cache values, particularly when dependent
> > libraries change.  This is manageable on a local machine when a real
> person
> > can catch the problem and immediately rectify the situation, but a CI
> server
> > is supposed to run as independently as possible.  The CI build should
> live
> > and die on the merits of the code, not some flaky cache held in a
> persistent
> > process.Nope, no stack trace.
> >
> > Yes, I just tested this, then the output is like this:
> > >
> > > Compiling ff:processing into
> > > /home/grotzke/proj/freiheit/final_folder/processing/target/classes
> > > Buildr aborted!
> > > Scala compiler crashed:
> > > #<StackOverflowError: unknown exception>
> > >
> > > Cool! ?! :) (it's good to have this improved error reporting ;))
> > >
> >
> > Well, I'm not perfect!  :-)  StackOverflowError does tell us something.
> > There are now two possibilities.  One would be that the scala compiler
> has a
> > bug that your code is unearthing (it wouldn't be the first time).  The
> other
> > possibility is that the compiler's stack is legitimately getting to be
> too
> > deep for the VM to handle.  This happens on occasion actually.  The
> solution
> > is to use the -X JVM options to allocate some of the stack onto the heap.
> > You'll have to lookup the exact options, but I know they exist (I've used
> > them a few times).  I would try that, see if the build runs after that
> > little tweak.
> >
> > Otherwise, the only workaround (other than waiting for the Scala team to
> fix
> > whatever is causing this) would be to use FSC and deal with any weirdness
> > which results.
> >
> > Daniel
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message