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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >> [email protected] >> http://lists.freedesktop.org/mailman/listinfo/swfdec >> > _______________________________________________ Swfdec mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/swfdec
