[Openmcl-devel] FFI problem
gb at clozure.com
Mon May 22 04:07:48 EDT 2006
I haven't tried to reproduce this (and this guess may be way off), but
I wonder if the current thread has a current GL context established
(via something like -[NSOpenGLView setOpenGLContext:] or whatever
the equivalent is in AGL or CGL) ?
The unmapped address that the foreign code is trying to indirect
through (#xab0) doesn't look like it has anything to do with the
address that's being passed in the call to #_glGetIntegerv - wherever
that stack-block got allocated, it's unlikely to be that low in memory.
I'd find it easier to believe that some internal data structure related
to the current OpenGL context stores GL_MAX_LIST_NESTING information
#xab0 bytes from the beginning of that structure, and that #_glGetIntegerv
doesn't check to see if the context is NULL before trying to access a
field in a null pointer.)
Note that the notion of "the current GL context" is generally per-thread,
so (for instance) an event-handling thread might have a properly installed
GL context and a listener thread might not.
Like I said, this is mostly a guess. I was doing a lot of GL stuff a
year or so ago and it sort of rings a bell, but I may be misremembering.
On Mon, 22 May 2006, Phil wrote:
> I've been attempting to get the following FFI call to work without much
> Call glGetIntegerv(GLenum pname, GLint *params) using the following:
> (let ((gl-int-size (ccl::foreign-size :<GL>int :bytes)))
> (ccl::%stack-block ((return-value gl-int-size))
> (#_glGetIntegerv #$GL_MAX_LIST_NESTING return-value)
> (ccl::%get-unsigned-long return-value)))
> The result is the kernel debugger:
> ? Unhandled exception 11 at 0x92e97ba0, context->regs at #xf0805498
> Read operation to unmapped address 0xab0
> In foreign code at address 0x92e97ba0
> ? for help
>  OpenMCL kernel debugger:
> What am I missing here?
> Openmcl-devel mailing list
> Openmcl-devel at clozure.com
More information about the Openmcl-devel