buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grotzke <>
Subject Re: Buildr aborted with unknown exception in scala module
Date Fri, 21 Aug 2009 09:36:30 GMT

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


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

View raw message