[Webkit-unassigned] [Bug 118473] [GTK] Leak: GstElement* leaking in MediaPlayerPrivateGStreamer::createAudioSink()

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=118473





--- Comment #13 from Brian Holt <brian.holt at samsung.com>  2013-07-09 03:03:33 PST ---
(In reply to comment #12)
> (In reply to comment #11)
> > Some more detail about the origins of the leaks from the debug build:
> > 
> > Leak_StillReachable
> > 40 bytes in 1 blocks are still reachable in loss record 335 of 1,176
> >     malloc (/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
> >     ...
> >     gst_element_factory_make (/WebKitBuild/Dependencies/Source/gstreamer/gst/gstelementfactory.c:446)
> >     WebCore::MediaPlayerPrivateGStreamer::createAudioSink() (/WebKitBuild/Debug/../../Source/WebCore/platform/graphics/gstreamer/MediaPlayerPrivateGStreamer.cpp:1564)
> > GstElement* scale = gst_element_factory_make("scaletempo", 0);
> > 
> 
> still-reachebles are not leaks, at least in WebKit sense.
> It's normal that there are unfreed heap objects at termination because WebKit is intentionally does not care about that (the idea is to terminate faster, the OS frees up the memory anyway). It means that for example singletons are usually created on the heap and never freed.
> We should be sure that the objects holding these pointers are actually destroyed. Only in that case can we say that these are real leaks. Given that in this case valgrind would rather report definitely-lost failures, I assume these are not leaks.

That's a fair point.  I will restrict my efforts to Definitely-Lost in the meantime.  

Should I mark this as wontfix?

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.