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

[Mike Thomas]

Hi Camm.

Camm Maguire wrote:

> 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.  
Yes. 

All Windows users of GCL and it's client applications owe you a great 
vote of thanks.  I quite literally was fighting a losing battle without 
your help - having first struck that bug almost as soon as I started 
using GCL which by now must be more than two years ago.  PCL and 
Closette were I think almost the first applications I tried to compile 
with GCL.
I also learnt a lot about how to use gdb under your direction thank you, 
but still much more to go I think..


> 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?
>  
Good idea.

>  
>
> > 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.
In fact last night I transferred the fix across to the stable source 
tree (not yet checked in as I want to try a little more testing first) 
and found that Maxima CVS still doesn't build because of the presence in 
defsystem.lisp of things like  MAKE::TRANSLATE-LOGICAL-PATHNAME 
(undefined) and IGNORE-ERRORS (broken?),  which I am working around as 
follows:

$ cvs diff lisp-utils/defsystem.lisp
Index: lisp-utils/defsystem.lisp
===================================================================
RCS file: /cvsroot/maxima/maxima/lisp-utils/defsystem.lisp,v
retrieving revision 1.12
diff -r1.12 defsystem.lisp
1822c1822,1824
<        (abs-name (ignore-errors (file-namestring abs-dir))) ; was 
pathname-nam
e
---
>        #+:gcl(abs-name (file-namestring abs-dir))
>        #-:gcl(abs-name (ignore-errors (file-namestring abs-dir)))
> ;      (abs-name (ignore-errors (file-namestring abs-dir))) ; was 
pathname-nam
e
2023,2024c2025,2027
<   (translate-logical-pathname
<    (merge-pathnames relative-dir absolute-dir)))
---
>   #-gcl(translate-logical-pathname
>    (merge-pathnames relative-dir absolute-dir))
>   #+gcl(merge-pathnames relative-dir absolute-dir))
2037,2048c2040,2062
<   (translate-logical-pathname
<    (make-pathname
<     :host (or (pathname-host absolute-dir)
<             (pathname-host relative-dir))
<     :directory (append (pathname-directory absolute-dir)
<                      (cdr (pathname-directory relative-dir)))
<     :name (or (pathname-name absolute-dir)
<             (pathname-name relative-dir))
<     :type (or (pathname-type absolute-dir)
<             (pathname-type relative-dir))
<     :version (or (pathname-version absolute-dir)
<                (pathname-version relative-dir)))))
---
>   #-gcl (translate-logical-pathname
>        (make-pathname
>         :host (or (pathname-host absolute-dir)
>                   (pathname-host relative-dir))
>         :directory (append (pathname-directory absolute-dir)
>                            (cdr (pathname-directory relative-dir)))
>         :name (or (pathname-name absolute-dir)
>                   (pathname-name relative-dir))
>         :type (or (pathname-type absolute-dir)
>                   (pathname-type relative-dir))
>         :version (or (pathname-version absolute-dir)
>                      (pathname-version relative-dir))))
>    #+gcl(make-pathname
>        :host (or (pathname-host absolute-dir)
>                  (pathname-host relative-dir))
>        :directory (append (pathname-directory absolute-dir)
>                           (cdr (pathname-directory relative-dir)))
>        :name (or (pathname-name absolute-dir)
>                  (pathname-name relative-dir))
>        :type (or (pathname-type absolute-dir)
>                  (pathname-type relative-dir))
>        :version (or (pathname-version absolute-dir)
>                     (pathname-version relative-dir))))
2057,2068c2071,2093
<     (translate-logical-pathname
<      (make-pathname
<       :host (or (pathname-host absolute-dir)
<               (pathname-host relative-dir))
<       :directory (append (pathname-directory absolute-dir)
<                        (cdr (pathname-directory relative-dir)))
<       :name (or (pathname-name absolute-dir)
<               (pathname-name relative-dir))
<       :type (or (pathname-type absolute-dir)
<               (pathname-type relative-dir))
<       :version (or (pathname-version absolute-dir)
<                  (pathname-version relative-dir))))))
---
>     #-gcl(translate-logical-pathname
>         (make-pathname
>          :host (or (pathname-host absolute-dir)
>                    (pathname-host relative-dir))
>          :directory (append (pathname-directory absolute-dir)
>                             (cdr (pathname-directory relative-dir)))
>          :name (or (pathname-name absolute-dir)
>                    (pathname-name relative-dir))
>          :type (or (pathname-type absolute-dir)
>                    (pathname-type relative-dir))
>          :version (or (pathname-version absolute-dir)
>                       (pathname-version relative-dir))))
>     #+gcl(make-pathname
>               :host (or (pathname-host absolute-dir)
>                         (pathname-host relative-dir))
>               :directory (append (pathname-directory absolute-dir)
>                                  (cdr (pathname-directory relative-dir)))
>               :name (or (pathname-name absolute-dir)
>                         (pathname-name relative-dir))
>               :type (or (pathname-type absolute-dir)
>                         (pathname-type relative-dir))
>               :version (or (pathname-version absolute-dir)
>                            (pathname-version relative-dir)))))
2088c2113,2114
<                (ignore-errors (translate-logical-pathname thing))
---
>                #-gcl(ignore-errors (translate-logical-pathname thing))
>                #+gcl thing
2650c2676,2677
<          (namestring (translate-logical-pathname pathname)))
---
>          (namestring #-gcl(translate-logical-pathname pathname)
>                      #+gcl pathname))
3998c4025
<       (translate-logical-pathname
---
>       #-gcl(translate-logical-pathname
3999a4027
>       #+gcl(merge-pathnames (make-pathname :type type) (pathname path2))
4121c4149
<             ,(namestring (translate-logical-pathname output-file))
---
>             ,(namestring #-gcl(translate-logical-pathname 
output-file) #+gcl o
utput-file)

address@hidden /c/cvs/head/maxima
$


> 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.
Thanks for this.  When you pointed it out the bss problem was blindingly 
obvious - I completely overlooked it when I went over that code a year 
or so ago.  I'm afraid my understanding of the mechanisms involved 
leaves a lot to be desired.

Cheers

MIke Thomas.