On Fri, Sep 26, 2008 at 8:12 PM, Michael J. Barillier
> thought every sysadmin implicitly though SBCL safe) and managed to blow
> up the target box while running run-tests.sh ... twice. The second
> crash caught the eye of one of the PFYs, who e-mailed me a portion of a
> log file griping about an NFS issue (no significant detail). Naturally,
> this isn't the kind of bug I'm going to attempt to reproduce. Can
> anyone come up with a reason why the SBCL test suite would reliably tank
> a RedSplat box, and - here's the part I'm most concerned about - is this
> something that would preclude attempting to present SBCL as a viable
> solution? (i.e. would SBCL blow up anytime an NFS volume is involved in
The test suite is fairly stressful and can severely impact the
performance of the box it runs on, but it definitely should not break
anything. Nor should SBCL be particularly picky about NFS.
...but I would neither build nor run regressions for SBCL on a
production box that was supposed to be doing something interesting at
the same time, just like I would not build GCC on such a box; either
wait till the box is free to muck with, or install precompiled and
tested binaries. Which is to say that (assuming you have access to
non-production boxes) I don't see why you would not try to reproduce
What exactly do you mean by "blow up the target box"? What does uname
-a say? Did the problem occur at the exact same point in run-tests.sh?
At what point(s) did the problem occur?