On Thu, Oct 04, 2001 at 03:10:52PM -0500, Nathan Froyd wrote:
> [this is not strictly an error, per se, but it did come up in a slightly
> abnormal situation, so I thought I'd pass it along]
> Hearing that CVS had been updated last night made me happy; I cvs up'd
> and proceeded to compile things:
> ./make.sh > build.log 2>&1
> This worked OK. I then thought, "Hmmm...I wonder what happens when I
> compile with :SB-SHOW?" -- I hoped this would provide insights about how
> the build process worked:
> [edit customize-target-features.lisp]
> ./make.sh > build-show.log 2>&1
> So I have a huge log file and a core compiled with :SB-SHOW. I copy
> this new core and the associated binary to my ~/lib and ~/bin
> directories, respectively. I move customize-target-features.lisp to a
> different name and recompile the system again (hoping to see via
> :SB-SHOW how things actually work in the compiler):
> ./make.sh > show-build.log 2>&1
> I left it alone (this whole thing is on a 233MHz p2 w/ 96MB RAM) and
> come back several hours later to find this peculiar message on my terminal:
> Help! 11 nested errors. KERNEL:*MAXIMUM-ERROR-DEPTH* exceeded.
That message is usually becuse of some error which screws up error
handling. After *MAXIMUM-ERROR-DEPTH* recursions of trying to do
sophisticated error handling, the system gets impatient and dies this
Right now the compiler has more than its usual number of problems
outputting debugging information, and debugging information is used in
error handling, so without knowing anything else about the problem I'd
guess that the infinite recursion has about a 60% chance of being
related to that.
> The funny thing is that show-build.log doesn't have anything out of the
> ordinary. `tail' gives this:
> ; compiling file "/home/nathan/sbcl/src/assembly/target/alloc.lisp"
> (written 20 OCT 2000 6:30:33PM):
> ; compiling top-level form:
> ; /home/nathan/sbcl/src/assembly/target/alloc.fasl written
> ; compilation finished in 0:00:00
> * Thu Oct 4 12:21:16 EST 2001
> ...which doesn't seem all that helpful (although it does seem that it
> would give more information about the top-level form in question).
I think some of the error output may not be all that good about going
to the stdout and stderr streams. I dimly remember a similar problem.
It would be good to fix it if it's causing problems.
> Any suggestions on further bug-hunting? I'm not that sure where to
> start (or even if it's worth starting, given that SBCL was probably not
> intended to run with :SB-SHOW enabled, was it?).
Actually, it is supposed to be able to run with :SB-SHOW enabled,
though it's not a very high priority to make sure it does, and it's
not tested systematically, so sometimes it's broken. However, it is
not necessarily supposed to be pleasant to run with :SB-SHOW enabled:
there can be a very large amount of extraneous output.
I'm pretty sure I built with :SB-SHOW within the last week, but I
haven't tested it in the last few builds. I guess it's time to try
that again, I'll though I'll look at the problems building under
>  I think base-target-features.lisp should really refer people to
> local-target-features.lisp-expr rather than
> customize-target-features.lisp since the former should normally be more
> than sufficient. at least, it confused me at first, because I put
> ( :sb-show )
> in customize-target-features.lisp and then had to go look in
> src/cold/shared.lisp to find out what I was really supposed to do when
> the build erred. :)
Good point. I'll try tweaking the comments in base-target-features.lisp.
William Harold Newman <william.newman@...>
Where are we going and why am I in this handbasket?
-- Daniel Demus <demus@...>
PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C