From: Michael J. B. <bla...@bl...> - 2008-09-27 00:42:32
|
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." |
From: Thomas F. B. <tbu...@gm...> - 2008-09-27 19:02:40
|
2008/9/27 Michael J. Barillier <bla...@bl...>: > 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. |
From: Julian S. <der...@we...> - 2008-09-27 20:18:29
|
"Michael J. Barillier" <bla...@bl...> 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) |
From: Nikodemus S. <nik...@ra...> - 2008-09-28 13:24:37
|
On Fri, Sep 26, 2008 at 8:12 PM, Michael J. Barillier <bla...@bl...> 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 |