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.
With Mesa 7.10.3 there is no memory leak.
Just run the attached program and watch the the memory size of this program.
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?
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
Created attachment 69791 [details]
output of: valgrind --tool=massif ./memleaker 1000
I did run valgrind with the memleaker 1000 (runns 1000 loops with memleaker)
Created attachment 69792 [details]
output of: valgrind --leak-check=full --tool=memcheck memleaker 10
I run valgrind --memcheck with the memleaker and 10 loops
Created attachment 69793 [details]
output of: valgrind --leak-check=full --tool=memcheck memleaker 1000
I run valgrind with memleaker and 1000 loops
I test this also in Mesa 9.0.0, there was _NO_ memory leak.
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?
Pushed the leak fix:
Author: Eric Anholt <firstname.lastname@example.org>
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.
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.
on Jan 20, 2017 at 05:41:12.
(provided by the Example extension).