From: Vladimir D. <vo...@mi...> - 2005-07-30 17:21:19
|
Hi all, I've been running with code checked in Mesa tree and there appears to be rather large memory leak which can be plainly seen by running glxgears and watching top. Valgrind says it is caused by: ==11962== 1256224 bytes in 4742 blocks are definitely lost in loss record 54 of 55 ==11962== at 0x1B904C19: calloc (vg_replace_malloc.c:175) ==11962== by 0x1BD705C5: _mesa_calloc (imports.c:98) ==11962== by 0x1BD4712B: r300NewProgram (r300_shader.c:47) ==11962== by 0x1BD7F283: update_program (state.c:945) ==11962== by 0x1BD7F2C5: _mesa_update_state (state.c:976) ==11962== by 0x1BD32F91: radeonMakeCurrent (radeon_context.c:294) ==11962== by 0x1BD2EF24: DoBindContext (dri_util.c:515) ==11962== by 0x1BD2EF85: driBindContext3 (dri_util.c:548) ==11962== by 0x1B954821: BindContextWrapper (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B954B70: MakeContextCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x804B7EF: make_window (in /usr/X11R6/bin/glxgears) So apparently we never free programs.. Also, there is a small leak in DRI Hash code: ==11962== 28 bytes in 1 blocks are definitely lost in loss record 21 of 55 ==11962== at 0x1B9042E8: malloc (vg_replace_malloc.c:130) ==11962== by 0x1B96045B: drmMalloc (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B962D20: drmRandomCreate (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B96297B: HashHash (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B962AA4: HashFind (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B962B2C: drmHashLookup (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1BD2EC4A: __driFindDrawable (dri_util.c:238) ==11962== by 0x1BD2EDD3: DoBindContext (dri_util.c:448) ==11962== by 0x1BD2EF85: driBindContext3 (dri_util.c:548) ==11962== by 0x1B954821: BindContextWrapper (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B954B70: MakeContextCurrent (in /usr/X11R6/lib/libGL.so.1.2) ==11962== by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) best Vladimir Dergachev |
From: Vladimir D. <vo...@mi...> - 2005-07-30 22:57:47
|
On Sat, 30 Jul 2005, Vladimir Dergachev wrote: > > Hi all, > > I've been running with code checked in Mesa tree and there appears to be > rather large memory leak which can be plainly seen by running glxgears and > watching top. One more piece of information - the memory leak increases with the size of the window. This is very surprising as I did not think window size should matter. Also, the code path pointed by Valgrind does not appear to cause this, at least not in the obvious way - putting printf("Hello\n") in r300NewProgram does not print many "Hello"'s so this is not the actual culprit.. Does anyone have suggestions ? best Vladimir Dergachev > > Valgrind says it is caused by: > > ==11962== 1256224 bytes in 4742 blocks are definitely lost in loss record 54 > of 55 > ==11962== at 0x1B904C19: calloc (vg_replace_malloc.c:175) > ==11962== by 0x1BD705C5: _mesa_calloc (imports.c:98) > ==11962== by 0x1BD4712B: r300NewProgram (r300_shader.c:47) > ==11962== by 0x1BD7F283: update_program (state.c:945) > ==11962== by 0x1BD7F2C5: _mesa_update_state (state.c:976) > ==11962== by 0x1BD32F91: radeonMakeCurrent (radeon_context.c:294) > ==11962== by 0x1BD2EF24: DoBindContext (dri_util.c:515) > ==11962== by 0x1BD2EF85: driBindContext3 (dri_util.c:548) > ==11962== by 0x1B954821: BindContextWrapper (in > /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B954B70: MakeContextCurrent (in > /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x804B7EF: make_window (in /usr/X11R6/bin/glxgears) > > So apparently we never free programs.. > > Also, there is a small leak in DRI Hash code: > > ==11962== 28 bytes in 1 blocks are definitely lost in loss record 21 of 55 > ==11962== at 0x1B9042E8: malloc (vg_replace_malloc.c:130) > ==11962== by 0x1B96045B: drmMalloc (in /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B962D20: drmRandomCreate (in /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B96297B: HashHash (in /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B962AA4: HashFind (in /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B962B2C: drmHashLookup (in /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1BD2EC4A: __driFindDrawable (dri_util.c:238) > ==11962== by 0x1BD2EDD3: DoBindContext (dri_util.c:448) > ==11962== by 0x1BD2EF85: driBindContext3 (dri_util.c:548) > ==11962== by 0x1B954821: BindContextWrapper (in > /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B954B70: MakeContextCurrent (in > /usr/X11R6/lib/libGL.so.1.2) > ==11962== by 0x1B954D57: glXMakeCurrent (in /usr/X11R6/lib/libGL.so.1.2) > > best > > Vladimir Dergachev > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Aapo T. <ae...@ra...> - 2005-07-31 00:22:46
|
On Sat, 30 Jul 2005 18:57:30 -0400 (EDT) Vladimir Dergachev <vo...@mi...> wrote: > > > On Sat, 30 Jul 2005, Vladimir Dergachev wrote: > > > > > Hi all, > > > > I've been running with code checked in Mesa tree and there appears to be > > rather large memory leak which can be plainly seen by running glxgears and > > watching top. > > One more piece of information - the memory leak increases with the size of > the window. This is very surprising as I did not think window size should > matter. > > Also, the code path pointed by Valgrind does not appear to cause this, at > least not in the obvious way - putting printf("Hello\n") in r300NewProgram > does not print many "Hello"'s so this is not the actual culprit.. > > Does anyone have suggestions ? 'key' is never freed when existing key is found at _mesa_UpdateTexEnvProgram / _tnl_UpdateFixedFunctionProgram. Sorry, forgot to report this one... -- Aapo Tahkola |
From: Vladimir D. <vo...@mi...> - 2005-07-31 02:09:03
|
>> does not print many "Hello"'s so this is not the actual culprit.. >> >> Does anyone have suggestions ? > > 'key' is never freed when existing key is found at _mesa_UpdateTexEnvProgram / _tnl_UpdateFixedFunctionProgram. > Sorry, forgot to report this one... Great, thank you ! Unfortunately, I can't test it - some of the very latest changes to Mesa completely broke R300 driver - glxgears crashes and Quake has broken textures. Probably something to do with function table improvements. best Vladimir Dergachev > > -- > Aapo Tahkola > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |
From: Vladimir D. <vo...@mi...> - 2005-08-06 05:20:01
|
>> >> Also, the code path pointed by Valgrind does not appear to cause this, at >> least not in the obvious way - putting printf("Hello\n") in r300NewProgram >> does not print many "Hello"'s so this is not the actual culprit.. >> >> Does anyone have suggestions ? > > 'key' is never freed when existing key is found at _mesa_UpdateTexEnvProgram / _tnl_UpdateFixedFunctionProgram. > Sorry, forgot to report this one... Fixed - thank you very much ! Vladimir Dergachev > > -- > Aapo Tahkola > > > ------------------------------------------------------- > SF.Net email is sponsored by: Discover Easy Linux Migration Strategies > from IBM. Find simple to follow Roadmaps, straightforward articles, > informative Webcasts and more! Get everything you need to get up to > speed, fast. http://ads.osdn.com/?ad_id=7477&alloc_id=16492&op=click > -- > _______________________________________________ > Dri-devel mailing list > Dri...@li... > https://lists.sourceforge.net/lists/listinfo/dri-devel > |