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 166362 - data discarded by probes is leaked
data discarded by probes is leaked
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
git master
Other Linux
: Urgent blocker
: 0.8.9
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-02-05 12:29 UTC by Tim-Philipp Müller
Modified: 2005-02-08 09:46 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Small program that demonstrates the problem (2.40 KB, text/x-csrc)
2005-02-05 12:31 UTC, Tim-Philipp Müller
  Details
proposed patch (1.90 KB, patch)
2005-02-05 12:33 UTC, Tim-Philipp Müller
none Details | Review
updated (2.04 KB, patch)
2005-02-07 14:57 UTC, Ronald Bultje
none Details | Review

Description Tim-Philipp Müller 2005-02-05 12:29:51 UTC
When you have a probe hooked up to a pad, and the probe callback returns FALSE,
the data is not to be sent on and is to be discarded.

While the data is actually not processed any further when a probe callback
returns FALSE, the data is never actually freed.

This causes massive memory leaks in a pipeline of mine (about 500MB/sec).

Test program to demonstrate the bug attached.

Patch to fix the problem attached as well (however, note added FIXME in
gst_pad_pull() - I'm not 100% sure if it needs to be freed there as well).

Cheers 
 -Tim
Comment 1 Tim-Philipp Müller 2005-02-05 12:31:17 UTC
Created attachment 37022 [details]
Small program that demonstrates the problem
Comment 2 Tim-Philipp Müller 2005-02-05 12:33:05 UTC
Created attachment 37023 [details] [review]
proposed patch
Comment 3 Ronald Bultje 2005-02-07 14:57:50 UTC
Created attachment 37102 [details] [review]
updated

Data should also be discarded after pull dispatching blocks, here's an update
to Tim's patch.
Comment 4 Wim Taymans 2005-02-07 15:14:16 UTC
The alternative would be to unref the data in the callback handler which is not
a good idea because there might be other callbacks registered as a probe. This
solution is therefore the best.
The documentation is not clear about this, can you update it so that it clearly
states that the data will be unreffed at the end of the dispatching of all
handlers. 
Comment 5 Ronald Bultje 2005-02-07 16:20:32 UTC
Where is that documented?
Comment 6 Thomas Vander Stichele 2005-02-08 09:46:57 UTC
Ronald -> the api docs ?

commited to cvs, fixed