On Fri, Sep 17, 2010 at 09:59:23AM +0200, Josef Wolf wrote:
> I might try to run the build over and over again until it happens again. One
> build lasts about 1 hour on this machine, so it might take a while until it
> happens again (if at all).
Though it might be annoying, I think I should share what I found up to now.
I am building over and over again with the same build script, and get
seemingly non-deterministic results.
Problem is, that I have not payed attention on the _exact_ environment with
my first compiles. So there's room for uncertainty here.
What I can say for sure is that for the last 7 hours not a single build had
a problem. (a build including tests lasts about 20 minutes on this machine).
Before that, I had arbitrary failures on almost every other build (I posted
two of them onto this list, but there were more failures).
The only difference I can see is:
- the (successful) builds of the last seven hours were run from a kde
terminal.
- the arbitrarily failing builds were run from a screen session (which is
actually highly recommended on http://sbcl.sourceforge.net/getting.html)
I can not tell for sure, since I have not payed attention from the very first
builds. But I can tell for sure that since I started pay attention, I had not
a single failure in KDE terminal but lots of failures in screen sessions.
So I think the question has to be rephrased: what is so special about screen
sessions that could provoke broken builds?
Thinking a little about it leads to signals. When a screen session is
de/re-attached from different machines, resize signals are pretty much to be
expected. What happens when the build process receives signals? Could that
be the cause of the problems?
|