[Openmcl-devel] memory management and OpenGL trouble

[Gary Byers]

On Thu, 16 Sep 2010, Alexander Repenning wrote:

> With the latest version of CCL x86 32/64, 1.6-dev-r14265M-trunk  (DarwinX8664) all of our OpenGL code crashes. The same source
> works fine in 1.6-dev-r14231M-trunk and all versions before. I have not tested versions in between. It is as if some memory
> management changed. Is the cocoa bridge more aggressive in getting rid of non-retained objective-C objects?
> 
> When creating a window with an opengl view the crash looks like this:
> 
> Thread 4 Crashed:
> 0   GLEngine                       0x0000000017b3adfa gliAttachDrawableWithOptions + 44
> 1   com.apple.opengl               0x00007fff82843f64 CGLClearDrawable + 186
> 2   com.apple.AppKit               0x00007fff886d8c30 -[NSOpenGLContext clearDrawable] + 82
> 3   com.apple.AppKit               0x00007fff886d90d5 -[NSOpenGLContext dealloc] + 204
> 4   com.apple.AppKit               0x00007fff885671b7 -[NSOpenGLContext initWithFormat:shareContext:] + 215
> 5   com.clozure.Clozure CL-x8664   0x000000000001b38b SPffcall + 99 (x86-spentry64.s:4043)
> 6   ???                           0x0000000017a18fd0 0 + 396464080
> 
> The dealloc makes no sense

Trying to initialize a newly-allocated NSObject with invalid arguments
can (IIRC) cause the object to be deallocated; in some cases, the newly-allocated
object is a placeholder and initialization deallocates the placeholder and returns
an instance of a more specific class.  (So seeing an init method call dealloc
makes sense, though in this case it probably means that there's something wrong
with the arguments - the pixel format or the shared context - and it's believable
that  deallocating a partially/incorrectly-initialized GL context  has it's own
problems.)

A number of things in the bridge have changed in the last day or so,
many of them having to do with how MAKE-INSTANCE's initargs are used
to select and invoke an ObjC init method.  I don't have a good guess
as to exactly what the problem is here, but (since it seems likely
that the pixel-format and/or shared context are incorrectly initialized)
that code is certainly the prime suspect.