Bug 30075

Hi,
I'm using Mesa-7.8.2 (with libdrm-2.4.21, xorg-server-1.8.2, and linux-2.6.35.4). Once done with a current context, my understanding is that one then calls glXMakeContextCurrent(dpy, None, None, NULL) or glXMakeCurrent(dpy, None, Null) as appropriate, and then calls glXDestroyContext(dpy, ctx).

However, from OpenGL doc, it would appear to be acceptable, while context ctx is still current, to simply call glXDestroyContext(dpy, ctx) when done with it; in this case, ctx->dri_xid will be set to None (ref: glxcmds.c, line: 568), and glXDestroyContext will then return without actually destroying anything (gc->currentDpy is true; line 571, glxcmds.c). The actual destruction of ctx will then take place in the ensuing glXMakeContextCurrent call used to set a new context current (ref: glxcurrent.c, line 339).

There appears to be an inconsistency in the two above destroy context approaches. Specifically, assuming GLX_DIRECT_RENDERING and NOT GLX_USE_APPLEGL, if one issues glXDestroyContext(dpy, ctx), after ctx is made non-current, then the following code in glxcmds.c is executed:

 581 #if defined(GLX_DIRECT_RENDERING) && !defined(GLX_USE_APPLEGL)
 582    /* Destroy the direct rendering context */
 583    if (gc->driContext) {
 584       (*gc->driContext->destroyContext) (gc->driContext, gc->psc, dpy);
 585       gc->driContext = NULL;
 586       GarbageCollectDRIDrawables(dpy, gc->psc);
 587    }
 588 #endif

as well as:
 615 #ifndef GLX_USE_APPLEGL
 616    if (!imported) {
 617       /*
 618        ** This dpy also created the server side part of the context.
 619        ** Send the glXDestroyContext request.
 620        */
 621       LockDisplay(dpy);
 622       GetReq(GLXDestroyContext, req);
 623       req->reqType = opcode;
 624       req->glxCode = X_GLXDestroyContext;
 625       req->context = xid;
 626       UnlockDisplay(dpy);
 627       SyncHandle();
 628    }
 629 #endif

However, if one issues glXDestroyContext(dpy, ctx) while ctx is still current, then, in the soon to follow glXMakeContextCurrent call to set a new context, the former 'previously destroyed' context ctx is destroyed, but apparently WITHOUT carrying out either line 586, or lines 621-627 above. Perhaps, I'm missing something here, but I am concerned about why the dricontext garbage collection and the server-side context doesn't appear to be handled in this case.

thanks