buildr-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Grotzke <martin.grot...@javakaffee.de>
Subject Re: Buildr aborted with unknown exception in scala module
Date Sun, 23 Aug 2009 22:12:35 GMT
On Fri, 2009-08-21 at 08:18 -0700, Alex Boisvert wrote:
> 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.
When I find some time I'll try to reproduce this. The problem is, that
there were lots of commits around when this issue occurred. And it
probably was introduced by a developer using jruby so the issue was
discovered later by another dev not using jruby. So it's not clear which
revision introduced this problem, and I cannot publish the code as it's
not an open source project.

> 
> Did you also increase the maximum heap size?   -Xmx2048m    The scala
> compiler is pretty hungry for memory.
Yes, I also tried this, without success.

Cheers,
Martin


> 
> 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
View raw message