Comment # 15
on bug 74539
from Michel Dänzer
(In reply to comment #14) > Actually, I'm hoping that the valgrind output from WoW on my native 32 bit > box will be sufficient. If you could produce an apitrace reproducing the leaks as reported by valgrind, that might make it easier for us to reproduce and investigate the problem. This one looks interesting, but I'm not sure yet how the memory ends up being leaked: ==13334== 302,736 bytes in 84 blocks are possibly lost in loss record 6,231 of 6,282 ==13334== at 0x400870E: calloc (in /usr/lib/valgrind/vgpreload_memcheck-x86-linux.so) ==13334== by 0x8444B00: r600_texture_create_object (r600_texture.c:571) ==13334== by 0x844587C: r600_texture_create (r600_texture.c:759) ==13334== by 0x843FF69: r600_resource_create_common (r600_pipe_common.c:589) ==13334== by 0x83DC5EF: r600_resource_create (r600_pipe.c:558) ==13334== by 0x81D7A98: st_texture_create (st_texture.c:96) ==13334== by 0x81AA32E: guess_and_alloc_texture (st_cb_texture.c:405) ==13334== by 0x81AA476: st_AllocTextureImageBuffer (st_cb_texture.c:459) ==13334== by 0x814C953: _mesa_store_compressed_teximage (texstore.c:4195) ==13334== by 0x81A99D4: st_CompressedTexImage (st_cb_texture.c:823) ==13334== by 0x8138540: teximage (teximage.c:3244) ==13334== by 0x813A8D3: _mesa_CompressedTexImage2D (teximage.c:3913)
You are receiving this mail because:
- You are the assignee for the bug.
_______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel
