[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Gcl-devel] Window ansi crash debug output
From: |
Mike Thomas |
Subject: |
Re: [Gcl-devel] Window ansi crash debug output |
Date: |
Tue, 03 Feb 2004 21:23:11 +1000 |
User-agent: |
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) |
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.
- Re: [Gcl-devel] ANSI Windows: in-package failure, (continued)
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/17
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/17
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/18
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/18
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/19
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/20
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/20
- Re: [Gcl-devel] ANSI Windows: in-package failure, Camm Maguire, 2004/02/11
- RE: [Gcl-devel] ANSI Windows: in-package failure, Mike Thomas, 2004/02/11
Re: [Gcl-devel] Window ansi crash debug output, Camm Maguire, 2004/02/02
- Re: [Gcl-devel] Window ansi crash debug output,
Mike Thomas <=