[Mesa-users] Mesa XWindows memory leak causing application instability
Rick Irons
Rick.Irons at mathworks.com
Mon Jun 19 15:22:16 UTC 2017
Hi Chuck,
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?
Thanks,
Rick
From: Chuck Atkins [mailto:chuck.atkins at kitware.com]
Sent: Friday, June 16, 2017 8:44 PM
To: Rick Irons <Rick.Irons at mathworks.com>
Cc: Brian Paul <brianp at vmware.com>; mesa-users at lists.freedesktop.org
Subject: Re: [Mesa-users] 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 <Rick.Irons at mathworks.com<mailto:Rick.Irons at mathworks.com>> 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:brianp at vmware.com<mailto:brianp at vmware.com>]
Sent: Friday, June 16, 2017 4:06 PM
To: Rick Irons <Rick.Irons at mathworks.com<mailto:Rick.Irons at mathworks.com>>
Cc: Chuck Atkins <chuck.atkins at kitware.com<mailto:chuck.atkins at kitware.com>>; mesa-users at lists.freedesktop.org<mailto:mesa-users at lists.freedesktop.org>
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 <Rick.Irons at mathworks.com<mailto:Rick.Irons at mathworks.com>
> <mailto:Rick.Irons at mathworks.com<mailto:Rick.Irons at mathworks.com>>> 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:* mesa-users at lists.freedesktop.org<mailto:mesa-users at lists.freedesktop.org>
> <mailto:mesa-users at lists.freedesktop.org<mailto:mesa-users at lists.freedesktop.org>>
> *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/0a20051e6da99e91b7bf589ea457c77a8b618f26
> <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=>
> 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
> mesa-users at lists.freedesktop.org<mailto:mesa-users at lists.freedesktop.org>
> <mailto:mesa-users at lists.freedesktop.org<mailto:mesa-users at lists.freedesktop.org>>
> 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
> mesa-users at lists.freedesktop.org<mailto:mesa-users at lists.freedesktop.org>
> 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=
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-users/attachments/20170619/13423227/attachment-0001.html>
More information about the mesa-users
mailing list