Swfdec - Oct 2008 - memory profiling on swfdec

Hello,

Now I'v some trouble on  profiling swfdec, which uses glib heavily.
The problem is that the gobject system registers many new types but
never free them before program exiting. It is said that it's the OS
responsibility to recycle those memory used by the gobject type
system. But my memory checkers(profiling tools) don't like that. Any
memory allocated during program executing but not freed before program
exiting is marked as a "memory leak".  So after a single run of
swfdec, the profiling reports gave hundreds of "memory leaks" in the
report.  Many of them are happened inside the glib,  though glib
designers think they are not real "memory leaks" since they would be
collected right after program exiting anyway.  The difficulty here is
it's hard to check which are real "memory leaks". Because memory
leaks(if any) caused by swfdec are mixed together with those caused by
glib in the final reports.

I'v googled related issue with glib, and it's seemed to be common
problem with glib based apps and memory profilers.  You guys have
designed the smart GC mechanism in swfdec, so I guess you should have
some good tips on profiling the memory leaks.  Any suggestions?

Thanks ahead.

--zou

Hey,

We've solved this by using a smart memory profiling tool, which knows
if memory should or should not be freed and this tool is valgrind. THe
magic command line I'm using is:
G_SLICE=always-malloc GST_REGISTRY_FORK=no valgrind --leak-check=full
--leak-resolution=high player/.libs/lt-swfplay test.swf
That will give you quite a bit of output on stderr, so it might be
useful to redirect it to a file. Only stuff which is marked as
"definitely lost" is memleak, "possibly lost" often is not
(but might
be).

For added fun you can add --show-reachable=yes to get all the in-use
memory listed, too.

Cheers,
Benjamin


On Sun, Oct 12, 2008 at 6:13 AM, zou lunkai <zoulunkai at gmail.com>
wrote:
> Hello,
>
> Now I'v some trouble on  profiling swfdec, which uses glib heavily.
> The problem is that the gobject system registers many new types but
> never free them before program exiting. It is said that it's the OS
> responsibility to recycle those memory used by the gobject type
> system. But my memory checkers(profiling tools) don't like that. Any
> memory allocated during program executing but not freed before program
> exiting is marked as a "memory leak".  So after a single run of
> swfdec, the profiling reports gave hundreds of "memory leaks" in
the
> report.  Many of them are happened inside the glib,  though glib
> designers think they are not real "memory leaks" since they would
be
> collected right after program exiting anyway.  The difficulty here is
> it's hard to check which are real "memory leaks". Because
memory
> leaks(if any) caused by swfdec are mixed together with those caused by
> glib in the final reports.
>
> I'v googled related issue with glib, and it's seemed to be common
> problem with glib based apps and memory profilers.  You guys have
> designed the smart GC mechanism in swfdec, so I guess you should have
> some good tips on profiling the memory leaks.  Any suggestions?
>
> Thanks ahead.
>
> --zou
> _______________________________________________
> Swfdec mailing list
> Swfdec at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/swfdec
>