Re: [Gcl-devel] Window ansi crash debug output

[Camm Maguire]

Greetings!

Mike Thomas <address@hidden> writes:

> Hi Camm.
> 
> A brief reply but more good news (I think) - I did a complete update,
> clean and rebuild and the problem went away.  CVS Maxima with ANSI

Great!  I take it this means your ansi build completes without failure
without disabling use-fast-links.  If so, might I suggest as a test
procedure to follow in pursuing remaining bugs that you keep a
(si::use-fast-links nil) build around, and that you determine if/when
each bug is affected by the use-fast-links setting?

> still fails with the strange path problem recently described.
> 

I'm hoping this is the last remaining issue, as it seems to be common
to the problem you report in a following email, the maxima build, and
perhaps also the problem you show below.  Thankfully, this should be
much easier to chase down than the bug we've just squashed.

> The ANSI "make test-unixport" fails as  follows.  I'll chase these
> early this week:
> 
> Test CL-VARIABLE-SYMBOLS.1 failed
> Form: (LOOP
>         FOR
>         S
>         IN
>         *CL-VARIABLE-SYMBOLS*
>         WHEN
>         (NOT (BOUNDP S))
>         COLLECT
>         S)
> Expected value: NIL
> Actual value: (*COMPILE-FILE-PATHNAME* *COMPILE-FILE-TRUENAME*
>                   *LOAD-PATHNAME* *LOAD-PRINT* *LOAD-TRUENAME*
>                   *PRINT-LINES* *PRINT-MISER-WIDTH*
>                   *PRINT-PPRINT-DISPATCH* *PRINT-RIGHT-MARGIN*
>                   *READ-EVAL*).
>  CL-TYPES-THAT-ARE-CLASSES.1 CL-TYPES-THAT-ARE-CLASSES.2
>  CL-TYPES-THAT-ARE-CLASSES.3 SYMBOL-FUNCTION.ERROR.1
>  SYMBOL-FUNCTION.ERROR.2 SYMBOL-PACKAGE.ERROR.1 SYMBOL-PACKAGE.ERROR.2
>  SYMBOL-PLIST.ERROR.1 SYMBOL-PLIST.ERROR.2 SYMBOL-VALUE.ERROR.1
>  SYMBOL-VALUE.ERROR.2 SYMBOLP.1 SYMBOLP.2 SYMBOLP.3 SYMBOLP.ERROR.1
>  SYMBOLP.ERROR.2 BOUNDP.ERROR.1 BOUNDP.ERROR.2 BOUNDP.ERROR.3
>  BOUNDP.ERROR.4 BOUNDP.ERROR.5 BOUNDP.ERROR.6 BOUNDP.1 BOUNDP.2
>  BOUNDP.3 BOUNDP.4 BOUNDP.5 BOUNDP.ORDER.1 COPY-SYMBOL.1 COPY-SYMBOL.2
>  COPY-SYMBOL.3 COPY-SYMBOL.4 COPY-SYMBOL.5 COPY-SYMBOL.ERROR.1
>  COPY-SYMBOL.ERROR.2 GENSYM.1 GENSYM.2 GENSYM.3 GENSYM.4 GENSYM.5
>  GENSYM.6 GENSYM.7 GENSYM.8 GENSYM.9 GENSYM.10 GENSYM.11 GENSYM.12
>  GENSYM.13 GENSYM-COUNTER.1 GENSYM.ERROR.1 GENSYM.ERROR.2
>  GENSYM.ERROR.3 GENSYM.ERROR.4 GENSYM.ERROR.5 GENSYM.ERROR.6
>  GENSYM.ERROR.7 GENSYM.ERROR.8 GENSYM.ERROR.9 KEYWORDP.1 KEYWORDP.2
>  KEYWORDP.3 KEYWORDP.4 KEYWORDP.5 KEYWORDP.6 KEYWORDP.7 KEYWORDP.8
>  KEYWORDP.9 KEYWORDP.10 KEYWORDP.12 KEYWORDP.ORDER.1 KEYWORDP.ERROR.1
>  KEYWORDP.ERROR.2 MAKE-SYMBOL.1 MAKE-SYMBOL.2 MAKE-SYMBOL.3
>  MAKE-SYMBOL.4 MAKE-SYMBOL.5 MAKE-SYMBOL.6 MAKE-SYMBOL.7 MAKE-SYMBOL.8
>  MAKE-SYMBOL.9 MAKE-SYMBOL.10
> Error in ERROR [or a callee]: The GO tag NIL is not established.
> 
> Broken at INVOKE-DEBUGGER.
>  1 (Continue) Retry loading file "gclload.lsp".
>  2 Return to top level.
> dbl:CL-TEST>>>
> 
> #0   INVOKE-DEBUGGER
> {datum=#<conditions::internal-simple-error.0>,arguments=nil
> ,loc2=#<conditions::i...} [ihs=17]
> #1   ERROR
> {datum=conditions::internal-simple-error,arguments=(:function-name er
> ror :format...} [ihs=16]
> Error in system::apply-display-fun [or a callee]: Caught fatal error
> [memory may
>  be damaged]
> 
> Broken at INVOKE-DEBUGGER.
>  1 (Abort) Return to debug level 2.
>  2 Retry loading file "gclload.lsp".
>  3 Return to top level.
> dbl:CL-TEST>>>>
> 
> 
> 
> Camm Maguire wrote:
> 
> >Hi Mike!  OK, progress!
> >
> >Mike Thomas <address@hidden> writes:
> >
> >
> >>Hi Camm.
> >>
> >>I really don't know how you managed to work that out but it was
> >>certainly a welcome message. While Rosie was asleep this afternoon I
> >>
> >
> >I can elaborate if interested.
> >
> If you have a few spare moments I would like to hear about it thanks.
> I'll check the current changes in so that I can get onto the job over
> the next few days.

OK, unlike compiled functions, compiled closures also have a per
function environment variable, accessed via a pointer
(i.e. Lclptr...), which is also redirected to its actual location in
memory upon the first call to call_or_link when fast-links are turned
on.  In other words, GCL has a slow way of looking up both function
and environment address by name, but when using fast-links, it can
store these looked-up values directly into the pointers used by the
calling function.  In this manner, the call_or_link is invoked only
once when using fast-links.

The function pointers thus redirected are called LnkLI...., and, as
objdump shows, are located in the .data section of the compiled
object.  In other words, space is allocated in the .data section to
hold the 4 byte final function address.  When the object is loaded and
relocated to its new position in memory, the address of this space
changes accordingly, and subsequent references to it must be modified
according to the instructions in a 'reloc record' for this pointer.
In this case, the reloc record simply says take your new .data section
start, and add xxx to get the pointer address.

The space for the environment pointers on the other hand is provided
in the .bss section.  Looking at your output, it was clear that the
addresses for these pointers were being assigned to locations near the
beginning of the relocated code, clearly in the .text section, or
where the cpu instructions themselves were being stored.  When
call_or_link tried to write to this space in redirecting the
environment pointer, it overwrote the code and produced illegal
instructions.  

Initially, we thought that something in pcl_braid was being relocated
to a space allocated for pcl_dfun, but your output made clear this was
not the case.  I fired up my own pcl build, and found that
the offending call_or_Link_closure was invoked three levels deep from
the pcl_braid init sequence.  In other words, the init sequence called
a compiled pcl_braid_closure, which called another closure, and which
in turn called the offending closure in pcl_dfun.  So the problem was
in pcl_dfun's relocation, not pcl_braid's, though this bug would
surely have showed up later there too.  In my gdb trace, the ptr given
to call_or_link_closure was at the end of the space allocated for the
object, not at the beginning.  This led me to look at sfasl.c and spot
the discrepancy between data and bss pointer initialization.

Take care,

> 
> Cheers
> 
> Mike Thomas.
> 
> 
> 
> 

-- 
Camm Maguire                                            address@hidden
==========================================================================
"The earth is but one country, and mankind its citizens."  --  Baha'u'llah