buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alex Boisvert <alex.boisv...@gmail.com>
Subject Re: Buildr aborted with unknown exception in scala module
Date Fri, 21 Aug 2009 15:18:51 GMT
Please open a bug and attach all possible information.  I haven't seen this
myself but given how random this is, we need to start collecting information
in order to determine the pattern of failure.

Did you also increase the maximum heap size?   -Xmx2048m    The scala
compiler is pretty hungry for memory.

alex


On Fri, Aug 21, 2009 at 2: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