Bug 30075 - Possible glXDestroyContext glXMakeContextCurrent inconsistency
Summary: Possible glXDestroyContext glXMakeContextCurrent inconsistency
Status: RESOLVED NOTABUG
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: unspecified
Hardware: x86 (IA32) Linux (All)
: medium normal
Assignee: mesa-dev
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-07 21:54 UTC by jpsinthemix
Modified: 2010-09-08 07:20 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Description jpsinthemix 2010-09-07 21:54:53 UTC
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
Comment 1 Kristian Høgsberg 2010-09-08 07:20:55 UTC
The request to destroy the server side context is always sent immediately.  If the context is current on the server side, it's up to the server to hold on to in until it's no longer current.

The garbage collection is gone in master.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.