|
From: Jengu (s. by Nabble.com) <li...@na...> - 2005-12-15 05:05:41
|
I'm working on a C++ project that links with wxgtk, boost, freetype, and OpenGL. So needless to say I'm passing a bunch of -l flags =) The issue is that whenever I try to run valgrind on my app I get lots of output regarding wxgtk and mesa. I can use --gen-suppressions=yes to generate suppressions for each one of these, but that's extremely repetitive given the number of different warnings. Also, some of the mesa ones are specific to my video card, so as soon as I test on another machine I'll have to repeat the process all over again. Is there an easy way to stop valgrind from checking for leaks in my shared libraries? -- Sent from the Valgrind - Users forum at Nabble.com: http://www.nabble.com/How-to-suppress-messages-in-shared-libraries--t746365.html#a1952755 |
|
From: Dirk M. <dm...@gm...> - 2005-12-15 10:18:15
|
On Thursday 15 December 2005 06:05, Jengu (sent by Nabble.com) wrote: > Is there an easy way to stop valgrind from checking for leaks in my shared > libraries? -- No, thinking about it, it doesn't even make sense to do that, given that a leak in a shared library could be caused by your application not calling the correct cleanup hook. Dirk |
|
From: Jengu (s. by Nabble.com) <li...@na...> - 2005-12-15 18:05:29
|
Valgrind seems totally unusable then. My app doesn't get even 5 lines in before Valgrind hits the 30,000 error mark unless I put in several suppressions that are going to be mostly specific to my machine because one is due to my gtk theme, and just about any OpenGL call valgrind decides causes a leak in the rage128 dri driver. How do developers cope with this? -- Sent from the Valgrind - Users forum at Nabble.com: http://www.nabble.com/How-to-suppress-messages-in-shared-libraries--t746365.html#a1962075 |
|
From: Nicholas N. <nj...@cs...> - 2005-12-15 19:51:50
|
On Thu, 15 Dec 2005, Jengu (sent by Nabble.com) wrote: > Valgrind seems totally unusable then. My app doesn't get even 5 lines in > before Valgrind hits the 30,000 error mark unless I put in several > suppressions that are going to be mostly specific to my machine because > one is due to my gtk theme, and just about any OpenGL call valgrind > decides causes a leak in the rage128 dri driver. How do developers cope > with this? You might have some luck with very general suppressions -- eg. if you only have a single line in the stack trace: { blah blah blah Memcheck:Leak obj:/foo/blah/buggy_lib.so } If I've got it right, this will suppress all leak errors in /foo/blah/buggy_lib.so. Nick |
|
From: Igmar P. <mai...@jd...> - 2005-12-15 19:19:49
|
> Valgrind seems totally unusable then. My app doesn't get even 5 lines in > before Valgrind hits the 30,000 error mark unless I put in several > suppressions that are going to be mostly specific to my machine because > one is due to my gtk theme, and just about any OpenGL call valgrind > decides causes a leak in the rage128 dri driver. How do developers cope > with this? 30000 errors usually indicate corruption, or extremely buggy software. Those numbers also give problems when not run under valgrind, so the only way is to fix the .so's. Igmar |
|
From: Dennis L. <pla...@pr...> - 2005-12-15 19:58:49
|
Am Donnerstag, den 15.12.2005, 20:19 +0100 schrieb Igmar Palsenberg: > > > Valgrind seems totally unusable then. My app doesn't get even 5 lines in > > before Valgrind hits the 30,000 error mark unless I put in several > > suppressions that are going to be mostly specific to my machine because > > one is due to my gtk theme, and just about any OpenGL call valgrind > > decides causes a leak in the rage128 dri driver. How do developers cope > > with this? > > 30000 errors usually indicate corruption, or extremely buggy software. > Those numbers also give problems when not run under valgrind, so the only > way is to fix the .so's. As he said hes working with a vendor supplied binary driver, so fixing that is not an option. And it does not necessarily me an extrem serious bug as lots of closed-source projects think that not initializing data is a kind of optimization. Nevertheless suppressing such errors is possible, but it needs some effort and this is good so. You dont have to make a suppression for every single error, you can make some that catch a wideer range of errors, the docs explain how. So I have about 30 suppressions for my nvidia driver. Unfortunately some errors are not suppressible (probably some V bug) but they only occur now and then and are not so important. greets Dennis |
|
From: Ashley P. <as...@qu...> - 2005-12-16 15:16:42
|
On Thu, 2005-12-15 at 20:19 +0100, Igmar Palsenberg wrote: > > > Valgrind seems totally unusable then. My app doesn't get even 5 lines in > > before Valgrind hits the 30,000 error mark unless I put in several > > suppressions that are going to be mostly specific to my machine because > > one is due to my gtk theme, and just about any OpenGL call valgrind > > decides causes a leak in the rage128 dri driver. How do developers cope > > with this? > > 30000 errors usually indicate corruption, or extremely buggy software. > Those numbers also give problems when not run under valgrind, so the only > way is to fix the .so's. This doesn't hold true in some cases, for example when there is hardware, in this case a graphics card, accessing user-space memory directly. I have several test programs that report 100000+ errors (at which point valgrind sensibly stops counting) and yet run fine without problem. The only way to make any progress in cases is just to add very broad suppressions and accept the fact this probably means some problems will get overlooked. Without the source of the library there probably isn't much else you can do. Ashley, |