<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=utf-8"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="EN-US" link="blue" vlink="purple"> <div class="WordSection1"> Hi Chuck,<o:p></o:p> <o:p> </o:p> One of my colleagues tried the configuration that you recommended and was unable to reproduce the issue. On further investigation he determined that the Gallium configuration doesn’t call XShmDetach. He added a call to XShmDetach and was then able to recreate the issue. Is it intentional (and appropriate) that the XShmDetach call is absent from the Gallium configuration?<o:p></o:p> <o:p> </o:p> Thanks,<o:p></o:p> Rick<o:p></o:p> <o:p> </o:p> From: Chuck Atkins [mailto:chuck.atkins@kitware.com] Sent: Friday, June 16, 2017 8:44 PM To: Rick Irons <Rick.Irons@mathworks.com> Cc: Brian Paul <brianp@vmware.com>; mesa-users@lists.freedesktop.org Subject: Re: [Mesa-users] Mesa XWindows memory leak causing application instability<o:p></o:p> <o:p> </o:p> <div> <div> Hi Rick,<o:p></o:p> </div> Do you have the same problem if you use the gallium-xlib driver instead? Try with a bare-bones gallium-xlib configuration (only the softpipe driver): ./configure --enable-opengl --disable-gles1 --disable-gles2 --disable-dri --disable-egl --disable-gbm --enable-glx=gallium-xlib --disable-llvm --disable-shared-glapi --disable-va --disable-xvmc --disable-vdpau --with-gallium-drivers=swrast --with-platforms=x11<o:p></o:p> <div> - Chuck<o:p></o:p> </div> <div> <div> On Fri, Jun 16, 2017 at 4:17 PM, Rick Irons <<a href="mailto:Rick.Irons@mathworks.com" target="_blank">Rick.Irons@mathworks.com</a>> wrote:<o:p></o:p> <blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in"> Hi Brian, We are using the old Mesa Xlib driver. The configure options we use are the following... ./autogen.sh --enable-glx=xlib --disable-driglx-direct --disable-dri --without-gallium-drivers --disable-egl --disable-gbm -with-platforms=x11 Output of glxinfo is attached. Thanks, Rick<o:p></o:p> <div> <div> -----Original Message----- From: Brian Paul [mailto:<a href="mailto:brianp@vmware.com" target="_blank">brianp@vmware.com</a>] Sent: Friday, June 16, 2017 4:06 PM To: Rick Irons <<a href="mailto:Rick.Irons@mathworks.com" target="_blank">Rick.Irons@mathworks.com</a>> Cc: Chuck Atkins <<a href="mailto:chuck.atkins@kitware.com" target="_blank">chuck.atkins@kitware.com</a>>; <a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a> Subject: Re: [Mesa-users] Mesa XWindows memory leak causing application instability Rick, Which Mesa driver are you using? What's the output of glxinfo? Both the old Mesa Xlib driver and the newer gallium softpipe/llvmpipe drivers use XShm and I'm not sure which one you're using. -Brian On 06/16/2017 01:28 PM, Chuck Atkins wrote: > Hi Rick, > 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. > > - Chuck > > 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> > <mailto:<a href="mailto:Rick.Irons@mathworks.com" target="_blank">Rick.Irons@mathworks.com</a>>> wrote: > > Hi all,____ > > __ __ > > Any thoughts on the issue identified below? ____ > > __ __ > > Perhaps this issue is something for the mesa-dev mailing list.____ > > __ __ > > Thanks,____ > > Rick____ > > __ __ > > *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> > <mailto:<a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a>> > *Subject:* Mesa XWindows memory leak causing application > instability____ > > __ __ > > 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> > <<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mesa3d_mesa_commit_0a20051e6da99e91b7bf589ea457c77a8b618f26&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=sDFaHTXy_QwKdQ0mlORDT6cCzkRnbjEwsqTMtCQJVsY&s=WErP_2_7ibjVwY_O0qnVjtrreVBAWiiSUt7LW_qKVxg&e=" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_mesa3d_mesa_commit_0a20051e6da99e91b7bf589ea457c77a8b618f26&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=sDFaHTXy_QwKdQ0mlORDT6cCzkRnbjEwsqTMtCQJVsY&s=WErP_2_7ibjVwY_O0qnVjtrreVBAWiiSUt7LW_qKVxg&e=</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.____ > > __ __ > > > _______________________________________________ > mesa-users mailing list > <a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a> > <mailto:<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" target="_blank">https://lists.freedesktop.org/mailman/listinfo/mesa-users</a> > > <<a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedeskto" target="_blank">https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedeskto</a> > p.org_mailman_listinfo_mesa-2Dusers&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ& > r=Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=sDFaHTXy_QwKdQ0mlORDT6 > cCzkRnbjEwsqTMtCQJVsY&s=T3N_tCx9oTUNZVXOu85-SlFOD-ULhZGi8Z-_zmCcPb8&e= > > > > > > > _______________________________________________ > mesa-users mailing list > <a href="mailto:mesa-users@lists.freedesktop.org" target="_blank">mesa-users@lists.freedesktop.org</a> > <a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop" target="_blank"> https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop</a> > .org_mailman_listinfo_mesa-2Dusers&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r > =Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=sDFaHTXy_QwKdQ0mlORDT6c > CzkRnbjEwsqTMtCQJVsY&s=T3N_tCx9oTUNZVXOu85-SlFOD-ULhZGi8Z-_zmCcPb8&e= ><o:p></o:p> </div> </div> </blockquote> </div> <o:p> </o:p> </div> </div> </div> </body> </html>