<div dir="ltr"><div>Hi Rick, </div>If you file a bug report it will usually get looked at by the necessary devs. If you don't hear anything back on the bug after a few days then try the dev list directly. You can also check the IRC channel #dri-devel on freenode. <div><div><div class="gmail_extra"> - Chuck </div><div class="gmail_extra"><div class="gmail_quote">On Tue, Jun 13, 2017 at 12:10 PM, Rick Irons <<a href="mailto:Rick.Irons@mathworks.com" target="_blank">Rick.Irons@mathworks.com</a>> wrote: <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <div link="#0563C1" vlink="#954F72" lang="EN-US"> <div class="m_7697754784556406034m_-970683096374849885WordSection1"> Hi all, Any thoughts on the issue identified below? Perhaps this issue is something for the mesa-dev mailing list. Thanks, Rick <div> <div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"> From: Rick Irons Sent: Friday, June 9, 2017 5:59 PM To: <a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a> Subject: Mesa XWindows memory leak causing application instability </div> </div><div><div class="m_7697754784556406034h5"> Hi, 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. This issue appears to have been introduced in Mesa 8.0.0 and is present in the current 17.1.2 release. 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. Thanks for any help that you can provide. Rick Problem description: 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. 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. 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. 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" target="_blank"> 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: X Error of failed request: BadRequest (invalid request code or no such operation) Major opcode of failed request: 0 () Serial number of failed request: 17 Current serial number in output stream: 17 which is exactly what we see when our glxgears-based test program calls XShmQueryVersion() after a few loops. Reproduction: 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. Possible workaround: 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. </div></div></div> </div> _______________________________________________ mesa-users mailing list <a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/mesa-users" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-users</a> </blockquote></div> </div></div></div></div>