After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 675270 - playbin2: potential memory leak in 0.10.36
playbin2: potential memory leak in 0.10.36
Status: RESOLVED INCOMPLETE
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
0.10.36
Other Linux
: Normal normal
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2012-05-02 00:03 UTC by Gavin Stark
Modified: 2012-10-16 22:32 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to show unbalanced malloc/free (1.32 KB, patch)
2012-05-02 00:03 UTC, Gavin Stark
none Details | Review

Description Gavin Stark 2012-05-02 00:03:09 UTC
Created attachment 213253 [details] [review]
Patch to show unbalanced malloc/free

An application I was running was memory stable under 0.10.35 but after upgrading to Ubuntu 12.04 and gstreamer 0.10.36 the app shows a linear growth in memory.

valgrind results look similar to #674787 but I'm not sure if this is the same issue.

I added some debug code to gstvideoscale.c since it showed the largest memory leak.

When run with playbin2 I see multiple passes to a malloc statement without an unmatched free. However, running with playbin I do see matched malloc/free.

See: https://gist.github.com/2571816

gst-launch playbin2 uri=......
0:00:00.676655349  2908  0x938e120 DEBUG             videoscale gstvideoscale.c:310:gst_video_scale_init: GES: calling video scale init
0:00:00.838913586  2908 0xb5e05120 DEBUG             videoscale gstvideoscale.c:533:gst_video_scale_set_caps: GES: calling video scale malloc
0:00:00.841475643  2908 0xb5e05120 DEBUG             videoscale gstvideoscale.c:530:gst_video_scale_set_caps: GES: calling video scale free before malloc
0:00:00.841486201  2908 0xb5e05120 DEBUG             videoscale gstvideoscale.c:533:gst_video_scale_set_caps: GES: calling video scale malloc

gst-launch playbin uri=......
0:00:01.136025328  2485  0x8dbeef0 DEBUG             videoscale gstvideoscale.c:310:gst_video_scale_init: GES: calling video scale init
0:00:01.444486894  2485 0xb609fc60 DEBUG             videoscale gstvideoscale.c:533:gst_video_scale_set_caps: GES: calling video scale malloc
0:00:03.937730093  2485  0x8db9600 DEBUG             videoscale gstvideoscale.c:324:gst_video_scale_finalize: GES: calling video scale finalize
0:00:03.937742026  2485  0x8db9600 DEBUG             videoscale gstvideoscale.c:327:gst_video_scale_finalize: GES: calling video scale free

I don't think the memory leak is in gstvideoscale but in something higher up the chain.
Comment 1 Tim-Philipp Müller 2012-05-02 07:06:45 UTC
moving this to playbin2 for the time being, since you say you observe this with playbin2 but not playbin. Could be in (uri)decodebin2 or elsewhere of course.
Comment 2 Gavin Stark 2012-05-04 15:27:33 UTC
Running Ubuntu 12.04 32-bit with 0.10.36 my app sees a linearly increasing memory growth.  Hand compiled gstreamer-plugins-base 0.10.35. Installed with the rest of the packages staying at 0.10.36 release and now memory usage is now flat.

Hopefully that helps narrow the focus for finding the specific memory leak issue.
Comment 3 Vincent Penquerc'h 2012-06-07 13:40:01 UTC
I'm not seeing this with 0.10 git, using both a simple playbin2 uri=...
and a playbin2 uri=... video-sink = 'videoscale ! video/x-raw-yuv,width=8000 ! xvimagesink' (both with gst-launch-0.10).

It could be either fixed already, or only show up with a particular input and/or pipeline.

Can you give more info about your setup (ie, which input format, the pipeline and/or program that uses playbin2) ?
Comment 4 Tim-Philipp Müller 2012-10-16 22:32:01 UTC
Not sure what to do about this, don't really have anything to go on without further information. Can't read all of the info in the gist.github link properly (log lines get cut off).

I'm sure someone will file a new bug if it still happens with 1.0.x.

Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for.
Thanks!