Re: Mesa XWindows memory leak causing application instability

Hi Rick,
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

- Chuck

On Fri, Jun 16, 2017 at 4:17 PM, Rick Irons <[email protected]>
wrote:

> 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
>
> -----Original Message-----
> From: Brian Paul [mailto:[email protected]]
> Sent: Friday, June 16, 2017 4:06 PM
> To: Rick Irons <[email protected]>
> Cc: Chuck Atkins <[email protected]>;
> [email protected]
> 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 <[email protected]
> > <mailto:[email protected]>> 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:* [email protected]
> >     <mailto:[email protected]>
> >     *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
> >     https://github.com/mesa3d/mesa/commit/0a20051e6da99e91b7bf5
> 89ea457c77a8b618f26
> >     <https://urldefense.proofpoint.com/v2/url?u=https-3A__
> github.com_mesa3d_mesa_commit_0a20051e6da99e91b7bf589ea457c7
> 7a8b618f26&d=DwMFaQ&c=uilaK90D4TOVoH58JNXRgQ&r=Ie7_encNUsqxb
> SRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=sDFaHTXy_QwKdQ0mlORDT6cCzkR
> nbjEwsqTMtCQJVsY&s=WErP_2_7ibjVwY_O0qnVjtrreVBAWiiSUt7LW_qKVxg&e=>
> >     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
> >     [email protected]
> >     <mailto:[email protected]>
> >     https://lists.freedesktop.org/mailman/listinfo/mesa-users
> >
> > <https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedeskto
> > 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
> > [email protected]
> > https://urldefense.proofpoint.com/v2/url?u=https-3A__lists.freedesktop
> > .org_mailman_listinfo_mesa-2Dusers&d=DwIGaQ&c=uilaK90D4TOVoH58JNXRgQ&r
> > =Ie7_encNUsqxbSRbqbNgofw0ITcfE8JKfaUjIQhncGA&m=sDFaHTXy_QwKdQ0mlORDT6c
> > CzkRnbjEwsqTMtCQJVsY&s=T3N_tCx9oTUNZVXOu85-SlFOD-ULhZGi8Z-_zmCcPb8&e=
> >
>
>

_______________________________________________
mesa-users mailing list
[email protected]
https://lists.freedesktop.org/mailman/listinfo/mesa-users