| Summary: | Memoryleak with glPopAttrib only on Intel GM45 | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Andreas Lampersperger <lampersperger.andreas> |
| Component: | Drivers/DRI/i965 | Assignee: | Ian Romanick <idr> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | major | ||
| Priority: | medium | ||
| Version: | 8.0 | ||
| Hardware: | x86 (IA32) | ||
| OS: | Linux (All) | ||
| Whiteboard: | |||
| 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
fixed memleak.c (memleak didn't start when given a loopcount) output of: valgrind --tool=massif ./memleaker 1000 output of: valgrind --leak-check=full --tool=memcheck memleaker 10 output of: valgrind --leak-check=full --tool=memcheck memleaker 1000 |
||
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: 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. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
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.