On 9 Feb 2011, at 08:44, Tor Lillqvist wrote: > A *true* leak, in my opinion, is if performing some code sequence over > and over again (like what happens if you just do the same UI actions > repeatedly) causes the amount of unreachable memory to grow > continuously. > It's an interesting argument and I could (almost) agree with it if we were referring specifically to program initialisation - but let me cite my earlier example of g_warning(). A call to g_warning() results in 16 memory leaks but when I re-tested it after reading your comment, I realised that 2 calls still only produce 16 leaks. So by your definition Tor, g_warning() doesn't count as code that leaks memory. I would say that it does leak memory because the leak can happen anywhere in my program and won't happen at all a g_warning() never gets issued. When it does leak though, it won't necessarily be associated with the program being initialised so in my view, g_warning() is definitely an example of leaking code.
> Can Visual Studio detect such leaks? Do you see any of > them? > Well, that's where things get difficult. AFAIK you can't tell Visual C++ to report some leaks but ignore others. Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been allocated but not yet released. This creates a problem, inasmuch as if memory is leaking according to your definition Tor, it's almost impossible to find the leak among all the other leaks that wouldn't be classed as leaks by your definition. If 500 leaks are being reported, I've no easy way of finding the one leak that you'd describe as genuine. Maybe other leak detectors are more flexible? It would be interesting to find out. I've asked a few other devs if they can suggest a way for VC to ignore certain leaks so I'll let you know if I find anything.. > And anyway, this "OMG GTK+ leaks memory" discussion has been had > several times already over the years. This parrot is dead. > Well that's the reason I asked. I didn't want to waste my time tracking down these leaks if no-one else was bothered about them. However, it's good to see a couple of other people who can appreciate the value off nailing these leaks! If nothing else, they clearly make leak detection a very difficult task. Just my 2 cents. John _______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
