[Swfdec] memory profiling on swfdec

[zou lunkai]

Thanks!

> 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).
>

If I understand correctly,  "definitely lost memory" is memory without
any reference pointers, ie. unreachable memory before program exit.
But I think that's not enough, especially for the AS engine, which is
really not a simple program.

Let me give a simple example:

//ActionScript code
var obj =  new Object()
delete obj;

If swfdec has destroyed the as_value 'obj' from its script context
after execution, but memory allocated for the Object is not freed by
some reason(eg. there's still a global instance pointer to the
object), then both the AS user and valgrind can't verify the memory
leak. Since it's not reachable to AS user as expected and it's not a
"definitely lost" as there is still a pointer to it.

I don't mean swfdec has this problem,  but if it does, valgrind won't
help much, right?

See this reference: http://myitcorner.com/?p=196   It tried to
suppress the reports that came from glib.

In general, I think programs should still respect that all memory
allocated at run-time should be freed before program exit(glib already
broke that), otherwise the memory profiling would be difficult(eg.
""definitely lost" is far from strict enough).

Any comments?

--zou








On Sun, Oct 12, 2008 at 6:50 PM, Benjamin Otte <otte at gnome.org> wrote:
> 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
>>
>