buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Spiewak <>
Subject Re: Buildr aborted with unknown exception in scala module
Date Fri, 07 Aug 2009 19:07:19 GMT
> 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.


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