On Thu, Jun 27, 2013 at 5:25 PM, Jeff Morriss <jeff.morriss.ws@xxxxxxxxx> wrote:
> [Taking discussion out of the bug since it's not specifically related to
> that bug.]
>
> On 06/18/13 18:20, bugzilla-daemon@xxxxxxxxxxxxx wrote:
>>
>> https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=8674#c8
>>
>> However, those
>> protocols currently use glib memory and therefore leak on shutdown,
>
>
> Isn't that a bit of an oxymoron? :-)
>
> (I know, I know, a while ago I spent a bunch of time cleaning up the
> preferences code to avoid leaks on shutdown--I think I commented something
> like "I do this just so I know where it is the stuff is being freed.")
>
> But, more seriously, Guy pointed out a (long?) while ago that a certain OS
> from a company he knows well has a way for applications to tell the OS
> something like "I have nothing to save before exiting" and when that flag is
> set and the user closes the app, the OS kills it with SIGKILL: it's faster
> and simpler that way. It's an interesting concept... It makes me think
> that we shouldn't really be spending time trying to fix leaks on shutdown.
The one benefit of fixing leaks on shutdown is that it makes it a
million times easier to detect other (real) leaks because valgrind's
output becomes useful. Right now any valgrind run you do with
--leak-check=full is painfully difficult to analyze because of all the
garbage (and dynamic hf arrays) that count as 'leaks'.
Wmem's epan scope should help a lot in this regard once it ends up
more widely used.
Evan
