<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=us-ascii"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="#0563C1" vlink="#954F72"> <div class="WordSection1"> Hi,<o:p></o:p> <o:p> </o:p> We are encountering sporadic application instability with an XWindows based implementation of Mesa. The source of the instability appears to be a memory leak. The details of our investigation are included below.<o:p></o:p> <o:p> </o:p> This issue appears to have been introduced in Mesa 8.0.0 and is present in the current 17.1.2 release.<o:p></o:p> <o:p> </o:p> Our workaround is identified below. We are interested to know if this is a valid fix or if there is an alternative preferred approach to addressing the problem.<o:p></o:p> <o:p> </o:p> Thanks for any help that you can provide.<o:p></o:p> <o:p> </o:p> Rick<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> Problem description:<o:p></o:p> It looks like Mesa is dependent on MIT-SHM extension in the sense that if the MIT-SHM loads, it needs to be left in the same state such that Mesa's call to XShmDetatch() works correctly, with no unintended side-effects.<o:p></o:p> <o:p> </o:p> The order of extension "close" callbacks appear to be driven by a loop in XCloseDisplay() where "Display *" points to a linked-list identified in the "ext_procs" field.<o:p></o:p> <o:p> </o:p> We find that in Mesa’s current state, MIT-SHM's close_display extension hook is called _before_ Mesa's extension hook has been called. Thus, MIT-SHM's shm_info has removed/deleted the _XExtDisplayInfo entry associated with the Display * being closed _before_ Mesa has called XShmDetach as part of its close callback.<o:p></o:p> <o:p> </o:p> The effect is to create a new _XExtDisplayInfo pointer that's left pointing to a freed "codes" field. If the _next_ caller of XOpenDisplay() is unlucky enough to a) obtain a recycled address of a "Display *" matching the previous one and b) call XShmQueryVersion(), there is a chance that the "codes" value(s) have been overwritten resulting in XError of BadRequest, BadLength, or hanging (all have been observed). This appears to be what <a href="https://github.com/mesa3d/mesa/commit/0a20051e6da99e91b7bf589ea457c77a8b618f26"> https://github.com/mesa3d/mesa/commit/0a20051e6da99e91b7bf589ea457c77a8b618f26</a> alludes to. In fact, I added XShmQueryVersion() back in to xm_api.c, removed the XShmQueryVersion() I'd incorporated into glxgears-based test program, and reproduced this failure:<o:p></o:p> <o:p> </o:p> X Error of failed request: BadRequest (invalid request code or no such operation)<o:p></o:p> Major opcode of failed request: 0 ()<o:p></o:p> Serial number of failed request: 17<o:p></o:p> Current serial number in output stream: 17 <o:p></o:p> <o:p> </o:p> which is exactly what we see when our glxgears-based test program calls XShmQueryVersion() after a few loops.<o:p></o:p> <o:p> </o:p> Reproduction:<o:p></o:p> See the modified "glxgears" demo. If possible, run on Debian 8.3 and keep hitting escape to close the current gears demo window and advance the loop. <o:p></o:p> <o:p> </o:p> Possible workaround:<o:p></o:p> If src/mesa/drivers/x11/fakeglx.c references MIT-SHM _before_ registering itself as an extension with the current display, this appears to allow Mesa's call to XShmDetach to occur with no unintended consequence. MIT-SHM's close callback is called _after_ Mesa has performed its clean up and we see no stranded entries in shm_info associated with the current display.<o:p></o:p> <o:p> </o:p> </div> </body> </html>