[Gcl-devel] Re: var types

[Camm Maguire]

Greetings, and thanks for your progress!

Inside of gdb, the seqfault occurs inside the X11 library call
XQueryPointer.  It is not strictly reproducible, and can alternatively
appear in XGetGeometry.  This makes me suspect something amiss in the
display struct returned as a pointer via XopenDisplay.  Do be sure I
need to either compile the x libraries myself with debugging, or
perhaps ask that the -dbg packages (i.e. devel packages with debugging
symbols left in) be installed on harper.  Disassembling the output
inside of XQueryPointer, the assembly tries to write into the memory
indirected by register %rax, which is some huge value in high memory
-- this suggests either a memory alignment or 4/8 byte mismatch.  

The way to be sure about all of this is to include proper prototypes
in the psedo header I've provided in xgcl.h.  There is a gcc tool
called protoize which can do this automatically.  When done, there are
countless C warnings complaining of integers being assigned to
pointers without a cast and vice versa.   Perhaps it is best to ignore
these and work with the prototypes anyway, as any call taking an int
(as opposed to an int *) will most likely misalign followwing word
sized arguments by 4 bytes when called without a prototype.  I.e. if
memory serves, all arguments are not word aligned on the C stack in
amd64, but rather (at least) half aligned.  Haven't actually found an
X call you use that takes an int as argument, however.

Once all this is worked out, there are a few improvements that come to
mind.  We can make defentry and defCfun write fast-linked code as
opposed to the older slower lisp value stack being used now.  If these
calls are reentrant (i.e. do not store fixed addresses outside the
calls), then perhaps the structures could be allocated on the faster
relocatable memory space as opposed to the current immovable
contiguous space.

Take care,

"Gordon Shaw Novak" <address@hidden> writes:

> Camm,
> 
> Maybe you can help me understand what is going on.
> 
> ./saved_xgcl
> (load "gcl_dwtest")
> (load "/home/novak/gcl-2.6.8pre/xgcl-2/fixes.lsp")
> (wtesta)
> (wtestb)
> (trace XLIB::XQUERYPOINTER WINDOW-GET-MOUSE-POSITION)
> (WINDOW-GET-MOUSE-POSITION)
> 
> which gives:
> 
>   1> (WINDOW-GET-MOUSE-POSITION)
>     2> (XLIB::XQUERYPOINTER 16144896 37 15982560 15994848 15978464
>            15974368 15896544 15892448 15888352)
> Error in XLIB::XQUERYPOINTER [or a callee]: Caught fatal error [memory may be 
> damaged]
> 
> The last 3 lines of WINDOW-GET-MOUSE-POSITION (version in fixes.lsp)
> are not executed, but those lines work and give plausile values:
> 
> (xlib::int-pos *root-x-return* 0)
> (xlib::int-pos *root-y-return* 0)
> (xlib::fixnum-pos *child-return* 0)
> 
> So it looks like the error occurred in the call to XQUERYPOINTER
> but I'm not sure wht the problem is -- maybe the wrong function
> signature, wrong number of args, or something.
> 
> Many thanks, Gordon
> 
> 
> 

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