Re: [Sbcl-devel] run-tests.sh DOS

2008/9/27 Michael J. Barillier <blackwolf@...>:
> I was installing unsanctioned software at work today (y'all probably
> 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
> some mystical operation?)
No idea what your problem could be (I like how you didn't even mention
what platform you're using ;) but I can vouch for a number of
SBCL-based applications, deployed in heavily NFS'ed environments, on
Linux and Solaris, on our own servers at my employer, and on those of
some of our clients. Our deployment environment is a slightly-hacked
1.0.10, but I do try out more recent SBCLs from time to time and
haven't seen anything problematic. That said, I'll give the latest a
whirl next week, and see if I see anything amiss.

Thread view

I was installing unsanctioned software at work today (y'all probably
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
some mystical operation?)
--
Michael J. Barillier /// http://www.blackwolfinfosys.net/~blackwolf/
_O_| Greenspun's Tenth Rule of Programming: "Any sufficiently
__O| complicated C or Fortran program contains an ad-hoc, informally-
OOO| specified bug-ridden slow implementation of half of Common Lisp."

2008/9/27 Michael J. Barillier <blackwolf@...>:
> I was installing unsanctioned software at work today (y'all probably
> 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
> some mystical operation?)
No idea what your problem could be (I like how you didn't even mention
what platform you're using ;) but I can vouch for a number of
SBCL-based applications, deployed in heavily NFS'ed environments, on
Linux and Solaris, on our own servers at my employer, and on those of
some of our clients. Our deployment environment is a slightly-hacked
1.0.10, but I do try out more recent SBCLs from time to time and
haven't seen anything problematic. That said, I'll give the latest a
whirl next week, and see if I see anything amiss.

"Michael J. Barillier" <blackwolf@...> writes:
> I was installing unsanctioned software at work today (y'all probably
> thought every sysadmin implicitly though SBCL safe) and managed to blow
> up the target box while running run-tests.sh ... twice.
If the kernel panics (you are not very clear on what actually happened
on what particular platform), it is a kernel bug and only partly related
to SBCL itself.
Regards,
--
Julian Stecklina
Well, take it from an old hand: the only reason it would be easier to
program in C is that you can't easily express complex problems in C,
so you don't. - Erik Naggum (in comp.lang.lisp)

On Fri, Sep 26, 2008 at 8:12 PM, Michael J. Barillier
<blackwolf@...> wrote:
> 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
this.
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?
Cheers,
-- Nikodemus