Page 1 of 4 123 ... LastLast
Results 1 to 10 of 38

Thread: AMD fglrx 8.42.3 leaking gobs of memory in OpenGL apps - any known workaround ?

  1. #1
    Join Date
    Aug 2007
    Location
    Norway
    Posts
    146

    Default AMD fglrx 8.42.3 leaking gobs of memory in OpenGL apps - any known workaround ?

    Hi,

    Just read this article:
    "ATI's New Drivers: Did The Paradise Come?" - http://www.phoronix.com/scan.php?pag...item=914&num=1

    He mentioned the latest fglrx leaking memory, so I tested this myself, and boy was he right. I've got 2GB of memory and don't do much OpenGL, so I hadn't noticed. But now I know I can forget OpenGL altogether with this driver .. unless anyone knows of a work-around ?

    The leaking rate is somehow connected to FPS/ticks, and it seems to occur in every OpenGL-app I've tried. If I run fgl_glxgears and size down the window, the FPS increases, and so does the memory leaking rate. This little app now uses over 400MiB RSS, and it has only been spinning for a couple of minutes. Wow..

    Guess it's back to 8.40.4 for me, this problem is definitely a showstopper .

    Just for the reference: I've got an ATI X1400 on a Lenovo Thinkpad Z61m.

  2. #2
    Join Date
    Nov 2007
    Posts
    1

    Default

    I'd like to add that I am seeing the same behavior on my system, and it definitely is a show stopper if I am to attempt using anything 3D. The performance is lovely, but with any 3D game eating up all my memory within 5 mins is hardly playable. Anybody aware of a workaround until amd/ati fixes this?

    I have heard of another memory leak that was caused by using kernel version 2.6.x and the kernel's own AGP driver, solved by using the built in AGP support in fglrx, but that doesn't work on my machine (fails to start X). I suspect this is different tho- most people these days use PCIe based cards... (grumble grumble need to upgrade... )

    System:
    Athlon XP (32-bit) / nForce 2
    ATi X1600 PRO 512M AGP

  3. #3
    Join Date
    Oct 2007
    Posts
    10

    Default

    The same issue is on my machine too.

    Athlon 64 x2
    Ubuntu 7.10 (32bit)
    ati 8.42.3 on x1800xt

  4. #4
    Join Date
    Apr 2007
    Location
    Mexico City, Mexico
    Posts
    900

    Default

    This seems to be general enough. Running Compiz/Beryl will leak memory too, albeit a bit slower.

  5. #5
    Join Date
    May 2007
    Location
    Up North, Where 10 degrees is shorts weather
    Posts
    80

    Default

    Holy CRAP!

    Yes it leaks -- horribly.

    fgl_fglrxgears running for 15 minutes on my box put me into swap. And I have 2g of ram.

    /proc/18157 $ more status
    Name: fgl_fglxgears
    State: R (running)
    Tgid: 18157
    Pid: 18157
    PPid: 18152
    TracerPid: 0
    Uid: 1000 1000 1000 1000
    Gid: 1342 1342 1342 1342
    FDSize: 256
    Groups: 10 18 27 35 100 1337 1342
    VmPeak: 1437420 kB
    VmSize: 1161892 kB
    VmLck: 0 kB
    VmHWM: 1124884 kB
    VmRSS: 1124884 kB
    VmData: 1126908 kB
    VmStk: 84 kB
    VmExe: 20 kB
    VmLib: 18564 kB
    VmPTE: 2820 kB
    Threads: 1
    SigQ: 0/16383
    SigPnd: 0000000000000000
    ShdPnd: 0000000000000000
    SigBlk: 0000000000000000
    SigIgn: 0000000000000000
    SigCgt: 0000000180000000
    CapInh: 0000000000000000
    CapPrm: 0000000000000000
    CapEff: 0000000000000000
    voluntary_ctxt_switches: 8594487
    nonvoluntary_ctxt_switches: 99266


    That there is 1.4Gb of VM utilization.....


    I'm off to read up -- this certainly explains where my memory errors in WoW are coming from --

  6. #6
    Join Date
    Apr 2007
    Location
    Würzburg, Germany
    Posts
    36

    Default

    The same for me on a X1300 mobility (Thinkpad T60). At least to my untrained eyes it appears that memory is lost systematically with every buffer swap. For those with plenty of RAM, at least a temporary fix for damage reduction may be enforcing vsync, such limiting the total framrate.

  7. #7
    Join Date
    May 2007
    Location
    Up North, Where 10 degrees is shorts weather
    Posts
    80

    Default

    okay :

    fresh reboot, nice clean system
    x up and running kde and fglrx 8.42.3

    card= XT1650Pro agp

    kernel AGP turned on by default, agp_amd64 on by default (IOMMU loaded by default in 2.6.23)

    Gentoo - I'm using the ebuild from the driver bump bug on bugs.gentoo.org.


    Code:
    vmstat 5 100
    procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
     r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
     1  0      0 1156852  70340 429808    0    0    17    13  557  263  1  1 98  0
     2  0      0 1151104  70340 429808    0    0     0     0 1110 25385 31 22 47  0
     1  0      0 1145360  70340 429808    0    0     0     0 1102 24983 32 21 47  0
     1  0      0 1139528  70364 429808    0    0     0     5 1109 25164 31 22 47  0
     1  0      0 1133700  70364 429808    0    0     0     0 1101 25472 31 21 47  0
     3  0      0 1127832  70364 429808    0    0     0     0 1105 25129 31 21 47  0
     1  0      0 1121920  70364 429808    0    0     0     0 1108 25404 31 22 47  0
     1  0      0 1116216  70364 429808    0    0     0     0 1101 25464 31 22 47  0
     1  0      0 1110180  70364 429808    0    0     0     0 1101 25476 31 22 47  0
     1  0      0 1104352  70364 429808    0    0     0     3 1103 25486 31 22 47  0
     2  0      0 1098608  70364 429808    0    0     0     0 1123 25209 31 23 46  0
     1  0      0 1092736  70364 429808    0    0     0     0 1122 25224 30 24 46  0
     1  0      0 1087120  70364 429808    0    0     0     0 1124 25213 31 22 47  0
     1  0      0 1081080  70364 429808    0    0     0     0 1112 25343 31 22 48  0
     1  0      0 1075336  70364 429808    0    0     0     0 1101 25445 31 22 47  0
     1  0      0 1069468  70364 429808    0    0     0     0 1110 25403 31 22 47  0
     1  0      0 1063640  70364 429808    0    0     0     0 1109 25341 32 21 47  0
     1  0      0 1057812  70364 429808    0    0     0     0 1107 25377 31 22 47  0
     1  0      0 1051816  70364 429808    0    0     0     0 1105 25368 31 21 48  0
     0  0      0 1328040  70364 429808    0    0     0     0 1110 22143 27 20 53  0
     0  0      0 1328040  70376 429808    0    0     0     3 1124  921  1  0 99  0
     0  0      0 1328024  70376 429808    0    0     0     0 1113  897  0  0 100  0
     0  0      0 1328108  70376 429808    0    0     0     0 1102  720  0  0 100  0
     0  0      0 1328148  70376 429808    0    0     0     0 1125  932  1  0 99  0
    You can see quite clearly where I kill fgl_fglxgears: the context swtiches die off and the memory utilization drops suddenly.


    gcc -v
    Thread model: posix
    gcc version 4.1.1 (Gentoo 4.1.1-r3)

    ld -v
    GNU ld version 2.16.1


    2.6.23-gentoo-r1iommuin #2 SMP Tue Nov 13 21:18:59 EST 2007 x86_64 AMD Athlon(tm) 64 X2 Dual Core Processor 3800+ AuthenticAMD GNU/Linux


    file /usr/lib/libGL.*
    Code:
    /usr/lib/libGL.la:     libtool library file
    /usr/lib/libGL.so:     symbolic link to `//usr/lib64/opengl/ati/lib/libGL.so'
    /usr/lib/libGL.so.1:   symbolic link to `/usr/lib/libGL.so'
    /usr/lib/libGL.so.1.2: symbolic link to `libGL.so.1'
    
    alistair@ajftl1 ~ $ file /usr/lib64/opengl/ati/lib/libGL.so
    /usr/lib64/opengl/ati/lib/libGL.so: symbolic link to `libGL.so.1.2'
    
    alistair@ajftl1 ~ $ file /usr/lib64/opengl/ati/lib/libGL.so.1.2
    /usr/lib64/opengl/ati/lib/libGL.so.1.2: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), stripped
    
    alistair@ajftl1 ~ $ ls -l /usr/lib64/opengl/ati/lib/libGL.so.1.2
    -rwxr-xr-x 1 root root 601832 Nov 15 11:44 /usr/lib64/opengl/ati/lib/libGL.so.1.2
    glibc version is 2.5

    Code:
    X -version
    
    X Window System Version 1.3.0
    Release Date: 19 April 2007
    X Protocol Version 11, Revision 0, Release 1.3
    Build Operating System: UNKNOWN
    Current Operating System: Linux ajftl1 2.6.23-gentoo-r1iommuin #2 SMP Tue Nov 13 21:18:59 EST 2007 x86_64
    Build Date: 12 November 2007
            Before reporting problems, check http://wiki.x.org
            to make sure that you have the latest version.
    Module Loader present
    I'm suspecting that the folks that ARE seeing the issue have some factor above in common -- so we need to list them all so we can find it...

  8. #8
    Join Date
    Mar 2007
    Location
    DG, IL, USA
    Posts
    208

    Default

    Alistair,
    I'm using Mandriva 2008 x86, kernel 2.6.22.9-desktop-1mdv.
    Mandriva's default drivers for my card were the 8.40' rpm.
    Using ATI's generic installer I've used both the 8.41 and currently the 8.42 drivers. I had no choice because the script is broken in 2008 so I cannot build my own rpm's..

    I have in my xorg Option "UseInternalAGPGART" "no"

    Code:
    gcc -v
    
    Thread model: posix
    gcc version 4.2.2 20070909 (prerelease) (4.2.2-0.RC.1mdv2008.0)
    Code:
    ld -v
    GNU ld version 2.17.50.0.12 20070128
    
    file /usr/lib/libGL.*
    /usr/lib/libGL.so:     symbolic link to `/usr/lib/xorg/libGL.so.1.2'
    /usr/lib/libGL.so.1:   symbolic link to `/usr/lib/xorg/libGL.so.1.2'
    /usr/lib/libGL.so.1.2: symbolic link to `libGL.so.1'
    Code:
    X -version
    
    X Window System Version 1.3.0
    Release Date: 19 April 2007
    X Protocol Version 11, Revision 0, Release 1.3
    Build Operating System: Linux_2.6.12-12mdksmp Mandriva
    Current Operating System: Linux Tardis-1 2.6.22.9-desktop-1mdv #1 SMP Thu Sep 27 04:07:04 CEST 2007 i686
    Build Date: 01 October 2007
            Before reporting problems, check http://wiki.x.org
            to make sure that you have the latest version.
    Module Loader present
    Those who would give up Essential Liberty to purchase a little Temporary Safety,deserve neither Liberty nor Safety.
    Ben Franklin 1755

  9. #9
    Join Date
    Sep 2007
    Location
    Germany
    Posts
    39

    Default

    Quote Originally Posted by DirtyHairy View Post
    ... At least to my untrained eyes it appears that memory is lost systematically with every buffer swap ...
    Hey, good eyes

    I simply did a quick test running glxgears under valgrind (via "$ valgrind --tool=memcheck --leak-check=yes glxgears"). After only 4 glxgears "iterations" (the poor FPS are because of running under valgrind, of course) valgrind gave up for more than 10000000 detected errors and told me to "Go fix your program!"

    The result is posted in the following comment (due to size constraints here). I omitted the startup output, and all those nearly identical "Invalid write of size 1"-Reports but the last one.

    [Edit] This is on Lenovo Z61m / 2 GiB RAM / ATI X1400 / Gentoo AMD64 / Kernel 2.6.22 / GLIBC 2.7 / X.Org xserver 1.3 / fglrx 8.42.3
    Last edited by Snake; 11-16-2007 at 05:01 AM.

  10. #10
    Join Date
    Sep 2007
    Location
    Germany
    Posts
    39

    Default

    Valgrind report for comment #9

    Code:
    <-- PREVIOUS OUTPUT CUT -->
    ==16057== Invalid write of size 1
    ==16057==    at 0x4C2292F: memcpy (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==16057==    by 0x6B51441: (within /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6B4FDE8: lnxioCmdBufSubmit(IODrvConnHandleTypeRec*, unsigned, unsigned, unsigned, unsigned, IOSubmitInfoOutRec&) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6A1184F: ioCmdBufSubmit2(void*, IOSubmitInfoInRec const*, IOSubmitInfoOutRec*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x69D1CF5: (within /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x69D17E7: coraSubmitCommandBuffer(gsl::gsCtx*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x69D0588: gsl::gsCtx::Flush() (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x69D0865: gslFlush(gslCommandStreamRec*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6A06C58: gscxFlush(gslCommandStreamRec*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x66AB74B: wpWindowSurface::copySwap(bool) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x66AC0B7: wpWindowSurface::copyToScreen(bool) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x66AC735: wpWindowSurface::swapBuffers() (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==  Address 0x2B49FD3ACB88 is not stack'd, malloc'd or (recently) free'd
    176 frames in 5.0 seconds = 35.052 FPS
    204 frames in 5.0 seconds = 40.628 FPS
    206 frames in 5.0 seconds = 41.055 FPS
    202 frames in 5.0 seconds = 40.244 FPS
    ==16057== 
    ==16057== More than 10000000 total errors detected.  I'm not reporting any more.
    ==16057== Final error counts will be inaccurate.  Go fix your program!
    ==16057== Rerun with --error-limit=no to disable this cutoff.  Note
    ==16057== that errors may occur in your program without prior warning from
    ==16057== Valgrind, because errors are no longer being displayed.
    ==16057== 
    ==16057== Warning: set address range perms: large range 134217728 (noaccess)
    ==16057== 
    ==16057== ERROR SUMMARY: 10000000 errors from 51 contexts (suppressed: 18 from 1)
    ==16057== malloc/free: in use at exit: 20,084,991 bytes in 3,922 blocks.
    ==16057== malloc/free: 44,360 allocs, 40,439 frees, 56,168,415 bytes allocated.
    ==16057== For counts of detected errors, rerun with: -v
    ==16057== searching for pointers to 3,922 not-freed blocks.
    ==16057== checked 13,187,712 bytes.
    ==16057== 
    ==16057== 
    ==16057== 0 bytes in 61 blocks are definitely lost in loss record 1 of 65
    ==16057==    at 0x4C20C6B: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==16057==    by 0x6AEEC08: operator new[](unsigned long) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6255840: gllCL::gllclProgramImpl::DecodeLoopConstants(gllCL::Section const&, char const*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6255D73: (within /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6254CE8: gllCL::gllclProgramImpl::clExtractElfBinary() (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6254378: gllCL::gllclProgramImpl::ExtractUsageInfo() (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6252B9C: gllCL::scltogllclUsageInfo(sclProgram*, gllCL::gllclProgramImpl*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6253408: gllCL::clCompile(glclStateHandleTypeRec*, gllclCompileParameters const&, gllShaderLanguageEnum, unsigned long, void const*, int, _sourceStrings*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6252703: mbclCompile(glclStateHandleTypeRec*, gllclCompileParameters const&, gllShaderLanguageEnum, unsigned long, void const*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x652934D: gllMB::SurfaceFill::loadProgram(gslProgramTargetEnum, gslProgramObjectRec*&, gslMemObjectRec*&, int*&, unsigned, char const*, gllclCompileParameters const&) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x65A6F6E: gllMB::SurfaceCopy::buildFragmentProgram(gllMB::SurfaceCopyOperation, unsigned) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x65AA782: gllMB::SurfaceCopy::setupFragmentState(gllMB::SurfaceCopyOperation, unsigned) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057== 
    ==16057== 
    ==16057== 664 (16 direct, 648 indirect) bytes in 1 blocks are definitely lost in loss record 36 of 65
    ==16057==    at 0x4C20C6B: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==16057==    by 0x300BA263C2: __FireGLDRIGetVisualConfigPrivates (in /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x300BA281D7: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x300BA2787A: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x300BA26634: __glXInitialize (in /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x300BA22FD4: glXChooseVisual (in /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x402AD3: (within /usr/bin/glxgears)
    ==16057==    by 0x53421F3: (below main) (in /lib64/libc-2.7.so)
    ==16057== 
    ==16057== 
    ==16057== 1,616 bytes in 32 blocks are possibly lost in loss record 44 of 65
    ==16057==    at 0x4C20C6B: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==16057==    by 0x6AEEC08: operator new[](unsigned long) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6A011A3: gsl::FetchProgramObject::SWPathStuff::construct(gsl::gsInput2ResourceTable const&) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6A01686: gsl::FetchProgramObject::pack(gsl::gsCtx*, AtiElfBinary, void*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x69FB587: gslProgramString(gslCommandStreamRec*, gslProgramObjectRec*, gslProgramTargetEnum, gslProgramFormatEnum, unsigned, void const*, void*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6A075B5: gsomProgramStringARB(gslCommandStreamRec*, gslProgramObjectRec*, gslProgramTargetEnum, gslProgramFormatEnum, unsigned, void const*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6529425: gllMB::SurfaceFill::loadFetchProgram(gslProgramObjectRec*&, unsigned, sclFetchShaderInstr*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6529A47: gllMB::SurfaceLoad::init(glmbStateHandleTypeRec*, gslRenderStateRec*, glclStateHandleTypeRec*, gllMB::SurfaceCopy*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6512F52: cxmbInitCtxState(glAdaptorHandleTypeRec*, glmbStateHandleTypeRec*, glshStateHandleTypeRec*, glclStateHandleTypeRec*, glcxStateHandleTypeRec*, glepStateHandleTypeRec*, gldbStateHandleTypeRec*, glsvStateHandleTypeRec*, gsCtxInfoRec*, _bool32, unsigned) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6231C09: glcxCreateContext(glAdaptorHandleTypeRec*, cmNativeContextHandleRec*, glConfigInfoRec const*, _bool32) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x669F195: wsiContext::wsiContext(glAdaptorHandleTypeRec*, cmNativeContextHandleRec*, RefPtr<wsiConfig>) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6695DAF: wsiDisplay::createContext(cmNativeContextHandleRec*, wsiConfigHandle) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057== 
    ==16057== 
    ==16057== 1,728 (216 direct, 1,512 indirect) bytes in 1 blocks are definitely lost in loss record 45 of 65
    ==16057==    at 0x4C20C6B: malloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==16057==    by 0x300BA217F9: _gl_context_modes_create (in /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x6AF12E8: __driCreateNewScreen_20050727 (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x300BA2828F: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x300BA2787A: (within /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x300BA26634: __glXInitialize (in /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x300BA22FD4: glXChooseVisual (in /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x402AD3: (within /usr/bin/glxgears)
    ==16057==    by 0x53421F3: (below main) (in /lib64/libc-2.7.so)
    ==16057== 
    ==16057== 
    ==16057== 987,648 bytes in 1,286 blocks are definitely lost in loss record 63 of 65
    ==16057==    at 0x4C1FD7C: calloc (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
    ==16057==    by 0x300BA48227: XF86DRIGetDeviceInfo (in /usr/lib64/opengl/ati/lib/libGL.so.1.2)
    ==16057==    by 0x6AF2257: DRIGetScreenSize (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6AF5BA8: driGetScreenSize(cmNativeDisplayHandleRec*, unsigned*, unsigned*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6B5061F: lnxioGetWindowInfo(IODrvConnHandleTypeRec*, cmWindowInfoRec*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6A117DD: ioGetWindowInfo(void*, cmWindowInfoRec*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x69D0B51: gslGetWindowInfo(gslCommandStreamRec*, cmWindowInfoRec*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x6A06CC8: gscxGetWindowInfo(gslCommandStreamRec*, cmWindowInfoRec*) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x66C39A0: wpWindowSystem::resizeIfNeeded(bool) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x66B2486: cxwpClear(glwpStateHandleTypeRec*, _bool32) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x621E5DB: epcxClear(glcxStateHandleTypeRec*, unsigned) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057==    by 0x63F1F81: gllEP::ep_tls_Clear(unsigned) (in /usr/lib64/dri/fglrx_dri.so)
    ==16057== 
    ==16057== LEAK SUMMARY:
    ==16057==    definitely lost: 987,880 bytes in 1,349 blocks.
    ==16057==    indirectly lost: 2,160 bytes in 8 blocks.
    ==16057==      possibly lost: 1,616 bytes in 32 blocks.
    ==16057==    still reachable: 19,093,335 bytes in 2,533 blocks.
    ==16057==         suppressed: 0 bytes in 0 blocks.
    ==16057== Reachable blocks (those to which a pointer was found) are not shown.
    ==16057== To see them, rerun with: --leak-check=full --show-reachable=yes

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •