[Swfdec] memory profiling on swfdec

[Benjamin Otte]

On Sun, Oct 12, 2008 at 3:59 PM, zou lunkai <zoulunkai at gmail.com> wrote:
> If I understand correctly,  "definitely lost memory" is memory without
> any reference pointers, ie. unreachable memory before program exit.
>
Yes, definitely lost is a memory region without a pointer to it.
Possibly lost is memory only referenced by data from definitely lost
regions and by other very unlikely conditions.

> 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 think you confuse memory allocated by Swfdec with objects created by
Actionscript code. For catching leaks in Actionscript code, you would
need to hack Swfdec, so it can show you why an object is not yet
freed. However, When a SwfdecPlayer is disposed, it will release all
objects that were allocated in its lifetime automatically so there's
no memleaks that could happen there.

> I don't mean swfdec has this problem,  but if it does, valgrind won't
> help much, right?
>
If your code acquires references to internal objects, then yes you
need to be more careful. In that case running with
--show-reachable=yes and checking the output for calls to
g_object_newv should usually be enough, as that's the function that
will always be called when a GObject is allocated.

> 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).
>
Feel free to convince the glib people that this is a good idea. If
they implement it, I'll make Swfdec be uninitializable, too. But I'm
not sure anyone is interested in doing (or paying for) the required
work, as it really doesn't buy you anything.


Cheers,
Benjamin