Bug 55175 - Memoryleak with glPopAttrib only on Intel GM45
Memoryleak with glPopAttrib only on Intel GM45
Status: RESOLVED FIXED
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965
8.0
x86 (IA32) Linux (All)
: medium major
Assigned To: Ian Romanick
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-09-21 06:56 UTC by Andreas Lampersperger
Modified: 2012-11-26 16:41 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments
small program to reproduce memory leak. compile with g++ -o memleaker memleaker.c -I/usr/include -lglut -lGLU -lGL -lXext -lX11 -lm -lXi -lXmu (4.30 KB, text/plain)
2012-09-21 06:56 UTC, Andreas Lampersperger
Details
fixed memleak.c (memleak didn't start when given a loopcount) (4.31 KB, application/octet-stream)
2012-11-09 07:47 UTC, Andreas Lampersperger
Details
output of: valgrind --tool=massif ./memleaker 1000 (212.51 KB, text/plain)
2012-11-09 07:50 UTC, Andreas Lampersperger
Details
output of: valgrind --leak-check=full --tool=memcheck memleaker 10 (9.51 KB, text/plain)
2012-11-09 07:53 UTC, Andreas Lampersperger
Details
output of: valgrind --leak-check=full --tool=memcheck memleaker 1000 (11.19 KB, text/plain)
2012-11-09 07:55 UTC, Andreas Lampersperger
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Andreas Lampersperger 2012-09-21 06:56:27 UTC
Created attachment 67475 [details]
small program to reproduce memory leak. compile with g++ -o memleaker memleaker.c -I/usr/include -lglut -lGLU -lGL -lXext -lX11 -lm -lXi -lXmu

There is huge memory leak running the attached small gl programm on a Intel GM45. 
This error does NOT occure on Intel i915 or Intel Ivybridge.

My Versions:
Kernel 3.2.28-rt40
xf86-video-intel 2.19.0
Mesa 8.0.4
libdrm 2.4.37
Xorg 1.9.5

With Mesa 7.10.3 there is no memory leak.

Just run the attached program and watch the the memory size of this program.
Comment 1 Eric Anholt 2012-10-31 18:00:13 UTC
I don't see this problem on my GM45 on either Mesa 8.0.4 or Mesa master, watching in top.  Maybe try using valgrind's massif tool to see where the leak is on your system?
Comment 2 Andreas Lampersperger 2012-11-09 07:47:37 UTC
Created attachment 69790 [details]
fixed memleak.c (memleak didn't start when given a loopcount)

In the previous memleak.c there was a error whenn given a loopcount (1st argument to memleak) the memleak programm did not start but keeps running in a endless loop. This program should be compiled with the following command: 
g++ -o memleaker memleaker.c -ggdb3 -I/usr/include -lglut -lGLU -lGL -lXext -lX11 -lm -lXi -lXmu
Comment 3 Andreas Lampersperger 2012-11-09 07:50:51 UTC
Created attachment 69791 [details]
output of: valgrind --tool=massif ./memleaker 1000

I did run valgrind with the memleaker 1000 (runns 1000 loops with memleaker)
Comment 4 Andreas Lampersperger 2012-11-09 07:53:09 UTC
Created attachment 69792 [details]
output of: valgrind --leak-check=full --tool=memcheck memleaker 10

I run valgrind --memcheck with the memleaker and 10 loops
Comment 5 Andreas Lampersperger 2012-11-09 07:55:22 UTC
Created attachment 69793 [details]
output of: valgrind --leak-check=full --tool=memcheck memleaker 1000

I run valgrind with memleaker and 1000 loops
Comment 6 Andreas Lampersperger 2012-11-09 11:49:39 UTC
I test this also in Mesa 9.0.0, there was _NO_ memory leak.
Comment 7 Eric Anholt 2012-11-16 18:02:39 UTC
I didn't run with any argument before, I assumed the program was built to just leak as it ran.  I still don't see a leak with the updated program on my gm45, with Mesa master, using your 1000 argument.

However, the private email note you had about compile_gs_prog() was good.  So, if we fix that one, is this bug fixed for you in Mesa master?
Comment 8 Eric Anholt 2012-11-26 16:41:16 UTC
Pushed the leak fix:

commit 59bfd66a614177320817a97e1dadfcfcf3b9b092
Author: Eric Anholt <eric@anholt.net>
Date:   Fri Nov 16 09:56:03 2012 -0800

    i965/gen4: Fix memory leak each time compile_gs_prog() is called.
    
    Commit 774fb90db3e83d5e7326b7a72e05ce805c306b24 introduced a ralloc context 
    each user of struct brw_compile, but for this one a NULL context was used,
    causing the later ralloc_free(mem_ctx) to not do anything.
    
    Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=55175
    NOTE: This is a candidate for the stable branches.

Hopefully this is the last leak you're seeing.  Feel free to reopen if this program is still showing leaks for you.