From: Nathan F. <fr...@ro...> - 2001-10-04 20:12:58
|
[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[0]] ./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. 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). 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?). -Nathan [0] 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. :) |
From: William H. N. <wil...@ai...> - 2001-10-04 22:40:58
|
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[0]] > ./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 simpler way. 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 sbcl-0.6.13 first. > [0] 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 <wil...@ai...> Where are we going and why am I in this handbasket? -- Daniel Demus <de...@so...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2001-10-05 15:24:36
|
On Thu, Oct 04, 2001 at 03:10:52PM -0500, Nathan Froyd wrote: > ./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. > 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?). As I wrote in response to another build-problem bug report, % I didn't actually try building 0.pre7.39, but I just finished some % tests on 0.pre7.42 (which is also identical to 0.pre7.43, except for % version) % * current working copy builds under sbcl-0.6.13 on OpenBSD/x86 % * current working copy builds with :SB-SHOW on OpenBSD/x86 % * fresh "cvs co", with no customize-target-features.lisp or % anything, builds under cmucl-18c on Linux/x86 % and I didn't run into any problems. I'm currently rebuilding sbcl-0.6.13 on Linux, and I plan to use it to build sbcl-0.pre7.42 with :SB-SHOW. That should be done later today. But I'll be surprised if :SB-SHOW doesn't work on Linux when it does work on OpenBSD. I still don't know why sbcl-0.pre7.39 had so many more problems than sbcl-0.pre7.42. I'm beginning to wonder whether I tested it only with slam.sh and then after checking it in fixed a bootstrap problem which I both neglected to note in my log and completely forgot afterwards. If that's anything like the truth, your best bet is to "cvs update" again and build the current version. Meanwhile, now that I'm getting more curious about how I screwed up .39, I'll probably check it out and see what's wrong with it (late today or sometime this weekend). I have probably been guilty of testing the result of slam.sh and taking success to indicate a good version, a dirty habit I got into on the flaky5_branch. It's pretty inappropriate to do that on the main branch: even if it didn't cause the problems in .39, it would doubtless have caused problems sooner or later. Henceforth I'll try to go back to the discipline of truly rebuilding before each checkin. (But it's not automated, so I'll still probably make the occasional mistake, just as occasionally version.lisp-expr doesn't always match the version in the CVS checkin message.) -- William Harold Newman <wil...@ai...> who will be less tempted once he upgrades to a 1.x GHz Athlon and the compiler gets some performance tuning PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Nathan F. <fr...@ro...> - 2001-10-05 17:16:27
|
William Harold Newman wrote: > As I wrote in response to another build-problem bug report, > % I didn't actually try building 0.pre7.39, but I just finished some > % tests on 0.pre7.42 (which is also identical to 0.pre7.43, except for > % version) > % * current working copy builds under sbcl-0.6.13 on OpenBSD/x86 > % * current working copy builds with :SB-SHOW on OpenBSD/x86 > % * fresh "cvs co", with no customize-target-features.lisp or > % anything, builds under cmucl-18c on Linux/x86 > % and I didn't run into any problems. > > I'm currently rebuilding sbcl-0.6.13 on Linux, and I plan to use it to > build sbcl-0.pre7.42 with :SB-SHOW. That should be done later today. > But I'll be surprised if :SB-SHOW doesn't work on Linux when it does > work on OpenBSD. Just to clarify: everything builds OK on Linux with :SB-SHOW. It's when I use the core produced by that build to build again that everything horks. I built 0.pre7.39 this morning from a core with :SB-SHOW enabled and :SB-SHOW enabled for the build process and got this output (before I was using a core with :SB-SHOW enabled, but it wasn't on during the build process, so I was getting nothing)(it's on a different machine, so I'm not including all of it, just what I think are the relevant parts. more can be included later if needed): /entering %COMPILE NAME=#:EVAL-TMPFUN-4 [elided] /returning from %COMPILE /entering ERROR, argument life=.. 0x0bfe49c3 /printing ERROR arguments one by one.. SB-DEBUG /entering INFINITE-ERROR-PROTECTOR, *CURRENT-ERROR-DEPTH*=.. 0x00000000 /returning normally from INFINITE-ERROR-PROTECTOR /back from INFINITE-ERROR-PROTECTOR /in INFINITE-ERROR-PROTECT, incremented error depth /entering INTERNAL-ERROR, CONTEXT=.. 0x0bfe49ff /entering INFINITE-ERROR-PROTECTOR, *CURRENT-ERROR-DEPTH*=.. 0x00000004 /returning normally from INFINITE-ERROR-PROTECTOR /back from INFINITE-ERROR-PROTECTOR /in INFINITE-ERROR-PROTECT, incremented error depth /entering INTERNAL-ERROR, CONTEXT=.. 0x0bfe4a37 and it proceeds like this several more times, with *CURRENT-ERROR-DEPTH* increasing by 4 and the CONTEXT increasing by 54 each time. -Nathan |
From: William H. N. <wil...@ai...> - 2001-10-05 19:03:02
|
On Fri, Oct 05, 2001 at 12:15:32PM -0500, Nathan Froyd wrote: > William Harold Newman wrote: > > > As I wrote in response to another build-problem bug report, > > % I didn't actually try building 0.pre7.39, but I just finished some > > % tests on 0.pre7.42 (which is also identical to 0.pre7.43, except for > > % version) > > % * current working copy builds under sbcl-0.6.13 on OpenBSD/x86 > > % * current working copy builds with :SB-SHOW on OpenBSD/x86 > > % * fresh "cvs co", with no customize-target-features.lisp or > > % anything, builds under cmucl-18c on Linux/x86 > > % and I didn't run into any problems. > > > > I'm currently rebuilding sbcl-0.6.13 on Linux, and I plan to use it to > > build sbcl-0.pre7.42 with :SB-SHOW. That should be done later today. > > But I'll be surprised if :SB-SHOW doesn't work on Linux when it does > > work on OpenBSD. > > > Just to clarify: everything builds OK on Linux with :SB-SHOW. It's when > I use the core produced by that build to build again that everything horks. Oh, now I understand. No wonder you get a really really big log file.. Now I have to agree with your (dimly remembered) earlier comment that this isn't really an intended use of :SB-SHOW. However, I'll take a look at it anyway, since there's probably no good reason for it to be broken, so if I can immediately guess what the problem is, I'll fix it. Otherwise, I won't worry about it until I've fixed more urgent things and debugging gets easier. -- William Harold Newman <wil...@ai...> Where are we going and why am I in this handbasket? -- Daniel Demus <de...@so...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: William H. N. <wil...@ai...> - 2001-10-05 16:12:35
|
On Thu, Oct 04, 2001 at 03:10:52PM -0500, Nathan Froyd wrote: > [0] 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. :) Now that I've looked at this, I wonder how you do that. Isn't local-target-features.lisp-expr automatically overwritten when you run make.sh? How do you make your hand-generated changes affect the build? I have tried to rewrite the customization instructions in an attempt to be a little clearer. The current draft looks like this: ;;;; Note that the recommended way to customize the features of a ;;;; local build of SBCL is not to edit this file, but instead to ;;;; tweak customize-target-features.lisp. If you define a function ;;;; in customize-target-features.lisp, it will be used to transform ;;;; the target features list after it's read and before it's used. ;;;; E.g. you can use code like this: ;;;; (lambda (list) ;;;; (flet ((enable (x) (pushnew x list)) ;;;; (disable (x) (setf list (remove x list)))) ;;;; #+nil (enable :sb-show) ;;;; (enable :sb-after-xc-core) ;;;; #+nil (disable :sb-doc) ;;;; list)) ;;;; By thus editing a local file (one which is not in the source ;;;; distribution, and which is in .cvsignore) your customizations ;;;; will remain local even if you do things like "cvs update", ;;;; will not show up if you try to submit a patch with "cvs diff", ;;;; and might even stay out of the way if you use other non-CVS-based ;;;; methods to upgrade the files or store your configuration. Then, since I give the justifications, I hope that people to whom such justifications aren't important can just edit base-target-features.lisp-expr directly and be done with it. Comments? Suggestions? -- William Harold Newman <wil...@ai...> Where are we going and why am I in this handbasket? -- Daniel Demus <de...@so...> PGP key fingerprint 85 CE 1C BA 79 8D 51 8C B9 25 FB EE E0 C3 E5 7C |
From: Nathan F. <fr...@ro...> - 2001-10-05 17:00:52
|
William Harold Newman wrote: > Now that I've looked at this, I wonder how you do that. Isn't > local-target-features.lisp-expr automatically overwritten when > you run make.sh? How do you make your hand-generated changes > affect the build? You are correct. I jumped to the wrong conclusions, without really looking at what was going on. > I have tried to rewrite the customization instructions in an attempt to be > a little clearer. The current draft looks like this: [elided] > Then, since I give the justifications, I hope that people to whom such > justifications aren't important can just edit > base-target-features.lisp-expr directly and be done with it. > > Comments? Suggestions? The instructions are clearer now, although I wonder if it's really worth the extra effort to have customize-target-features.lisp contain a function. Is there any particular reason that something like customize-target-features.lisp-expr is not used (in an analogous fashion to base-target-features.lisp-expr and friends)? My guess it would be so that very precise changing of the *FEATURES* list can be done. Another rationale would be for somebody who want to enable :MP in their builds. Say :MP becomes the default later in SBCL's lifetime; with the current system, *FEATURES* would end up having :MP once, whereas doing things the lisp-expr way would have multiple copies of things in *FEATURES* (although this could be avoided with UNION). I think I just answered my own question. :) -Nathan |
From: Daniel B. <da...@te...> - 2001-10-05 17:14:11
|
Nathan Froyd <fr...@ro...> writes: > The instructions are clearer now, although I wonder if it's really worth > the extra effort to have customize-target-features.lisp contain a > function. Is there any particular reason that something like > customize-target-features.lisp-expr is not used (in an analogous fashion > to base-target-features.lisp-expr and friends)? Well, it works quite nicely for those of us who want (or need) to _remove_ features. Notably, :gencgc is in the basic feature set but doesn't work on Alpha (or other non-x86 ports) -dan -- http://ww.telent.net/cliki/ - Link farm for free CL-on-Unix resources |