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
(BYTE-APPLY FUNCTION NUM-ARGS OLD-SP)
0] ba

0: (C::DO-CALL #<Code Object "DEFUN DEBUG-LOOP" {10196D57}> 186 169 163
    301948867 301948867)
1: (C::BYTE-UNWIND-PROTECT-XOP #<Code Object "DEFUN INTERNAL-DEBUG" {10196CAF}>
                               #<unused-arg>
                               30
                               154)
2: (ERROR "Segmentation Violation at #x~x." 1207794556)
3: (UNIX::SIGSEGV-HANDLER #<unused-arg>
                          #<unused-arg>
                          #.(SYSTEM:INT-SAP #x47FE0500))

0]

----------------------------------------

| is to figure out why you are getting a segment violation.  If this is 
| still how a stack overflow looks, there is a good chance you are blowing 
| out the stack due to some infinite recursion, possibly because something 
| that the interpreter assumes will be open-coded isn't being.  In this 
| case, it will be necessary to somehow get some sort of backtrace to tell 
| what is going on.  If it is too late to backtrace by the time the stack 
| is blown out, then you may need to hack the code to stop things before 
| it gets that far.  Or it is possible that the byte interpreter is 
| actually dereferencing off into space somewhere, in which case it would 
| likely help to compile the relevant parts of the byte interpreter safe.
| 
| 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 ..

-- Alex -- alex-goncharov <at> comcast.net --

/*
 * Vital papers will demonstrate their vitality by spontaneously moving
 * from where you left them to where you can't find them.
 */