gmane.lisp.cmucl.devel

Re: Small core broken?

,--- You/Rob (Thu, 29 May 2008 12:52:44 -0400) ----*
|
| If someone is interested in debugging the byte compiler, the first
| thing

If somebody with meaningful knowledge (that is, larger than mine)
thinks it's a worthy thing to look into the problem and can provide
some guidance, I can continue experimenting on my system.

The error is still "alive" here, and here is what "backtrace" shows:

----------------------------------------
; Compiling Top-Level Form: 

; target:code/hash-new.x86f written.
; Compilation finished in 0:00:00.

Error in function "<error finding name>":  Segmentation Violation at #x47FD7B7C.
   [Condition of type SIMPLE-ERROR]

Restarts:
  0: [CONTINUE] Return NIL from load of "target:tools/worldcom".
  1: [ABORT   ] Return to Top-Level.

Debug  (type H for help)

(C::DO-CALL #<Code Object "DEFUN PRINT-FRAME-CALL-1" {101A65D7}> 24 231 216
 301948867 ("Tag for DEFUN PRINT-FRAME-CALL-1"))
Source: 
; File: target:code/byte-interp.lisp

(Continue reading)

headers

Raymond Toy | 30 May 02:32

Re: Small core broken?

Alex Goncharov wrote:
> Another thought is that, just given the info shown, that the debugger is 
> | running byte-interpreted, and this is failing, and masking the original 
> | error.  You could try recompiling the debugger and debug-internals stuff 
> | normally and then building a core that way so that you have a working 
> | lisp debugger.
>
> I'd do this if I knew how ..
>
>   
One way is to go look at tools/comcom and tools/worldcom.  Look at the 
commands that compile the debugger and if it says :byte-compile, change 
it so it doesn't byte-compile it.

Maybe also look tools/worldload and make sure maybe-byte-load isn't 
loading the byte-compiled version.  Maybe also find out what 
byte-load-over does.

This is from just looking at this stuff for five minutes.  I've never 
tried this before.

Ray

headers

Carl Shapiro | 30 May 03:27

Re: Small core broken?

It is worth noting that :small implies a lower safety setting than what is in the default builds. A good first step to debugging this problem may be to experiment with higher safety and debug settings than what is specified by :small.

I think a similar issue came up not too long ago regarding the treatment of format strings in :small builds.

On Thu, May 29, 2008 at 5:32 PM, Raymond Toy <toy.raymond <at> gmail.com> wrote:

Alex Goncharov wrote:
Another thought is that, just given the info shown, that the debugger is | running byte-interpreted, and this is failing, and masking the original | error. You could try recompiling the debugger and debug-internals stuff | normally and then building a core that way so that you have a working | lisp debugger.

I'd do this if I knew how ..

One way is to go look at tools/comcom and tools/worldcom. Look at the commands that compile the debugger and if it says :byte-compile, change it so it doesn't byte-compile it.

Maybe also look tools/worldload and make sure maybe-byte-load isn't loading the byte-compiled version. Maybe also find out what byte-load-over does.

This is from just looking at this stuff for five minutes. I've never tried this before.

Ray

headers

Fred Gilham | 12 Jul 19:40

Re: Small core broken?

Don't know if anyone still actively cares about this, but I spent an 
hour looking at this.

Turns out that somewhere during the compiling of lisp, LOAD seems to 
lose the pointer to the descriptor for worldcom.lisp:

target:code/hash-new
target:code/list
target:code/seq
** Closed file "/beta/homes/fred/cmucl-cvs/src/tools/worldcom.lisp"
target:code/string
target:code/mipsstrops
target:code/unix
target:code/bsd-os

The descriptor is finalized, resulting in it being closed.

I strongly suspect this is the reason for the problem compiling small 
cores.  I've tried to figure out why it happens but so far no luck. 
Perhaps someone else would know off the top of their head?

--

-- 
Fred Gilham                           gilham <at> ai.sri.com
Time is nature's way of keeping everything from happening
at once.  Unfortunately, it doesn't always work.

headers

Paul Werkowski | 12 Jul 21:11

Re: Small core broken?

Fred Gilham wrote:
> Don't know if anyone still actively cares about this, but I spent an 
> hour looking at this.
> 
> Turns out that somewhere during the compiling of lisp, LOAD seems to 
> lose the pointer to the descriptor for worldcom.lisp:
> 
> target:code/hash-new
> target:code/list
> target:code/seq
> ** Closed file "/beta/homes/fred/cmucl-cvs/src/tools/worldcom.lisp"
> target:code/string
> target:code/mipsstrops
> target:code/unix
> target:code/bsd-os
> 
> The descriptor is finalized, resulting in it being closed.
> 
> I strongly suspect this is the reason for the problem compiling small 
> cores.  I've tried to figure out why it happens but so far no luck. 
> Perhaps someone else would know off the top of their head?
> 

Odd that worldcom is still being read at that point as the form with
all those pathnames must have been read at the beginning. Some kind
of delayed printout?

Paul