Re: Memory leaks

[Bill C <czermak netspace net au>]

Hi All

On 10/02/11 18:26, John Emmas wrote:
> On 9 Feb 2011, at 17:01, James Morris wrote:
>
> > Not only do we have to write our own code, we have to put work into
> > making other peoples code ignore the errors in other peoples code so
> > we can see the errors in our own code. It's a bloody outrage!
> I've never used Valgrind but I can fully understand how frustrating that would be and how unproductive.  
> Surely everybody agrees that tracking down genuine leaks in one's code is a good and desirable thing?  And 
> surely everybody agrees that having to jump through hoops like that in order to achieve it is an unproductive 
> waste of the programmer's time?  Full marks to Valgrind for providing the feature - but it shouldn't excuse 
> sloppiness by other developers.
A few years back I first used valgrind with GTK.

On the Web I came across details on setting up an exception file; tried 
it and gave up.
I think it is the wrong approach, and maybe explains why noone has 
bothered to update it in the last 2 years.  I neglected to post the 
solution that worked for me

I would say that valgrind is a very powerful tool, but requires good 
software engineering skills to use.  It does not spoonfeed you an answer.

My approach was to only look at leaked memory that I had allocated 
myself.  Using this approach worked for my C generated from Legacy 
Pascal source, using my own compilation workbench.  That is I know 
exactly what is happening outside of GTK2 as everything else is my 
code.  (wrapper code, generated C code, database code or written 
subroutines)

With an IDE and C++ you are introducing new variables.  As with any 
debugging problem, what is needed is a minimal test program, so code 
with GTK and C and see what happens.  Is the problem GTK or gtkmm?  What 
happens on the latest Linux and Windows releases of GTK2 and GTK3.

I dont think I use the calls you use, else I would give it a go.  Also I 
am not using GTK3 or GTK under windows

Rgds Bill