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 647295 - pad: Decreased log level when a too small buffer size is allocated
pad: Decreased log level when a too small buffer size is allocated
Status: RESOLVED INVALID
Product: GStreamer
Classification: Platform
Component: gstreamer (core)
0.10.x
Other All
: Normal enhancement
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
: 667304 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2011-04-09 17:19 UTC by Haakon Sporsheim (ieei)
Modified: 2012-01-05 10:24 UTC
See Also:
GNOME target: ---
GNOME version: ---

Attachments
patch (836 bytes, patch)
2011-04-09 17:19 UTC, Haakon Sporsheim (ieei) 		none Details | Review

Description Haakon Sporsheim (ieei) 2011-04-09 17:19:52 UTC 
Created attachment 185598 [details] [review]
patch

This is not an error since we handle it with a fallback method.
Comment 1 René Stadler 2011-04-09 17:34:48 UTC 
It's indeed not an error, but this should be a warning instead. However I agree that it shouldn't fire for each and every single buffer.

The size mismatch indicates a possible problem still (at least for performance), and these cases should not at all be swept under the carpet by demoting to debug or log level.
Comment 2 Tim-Philipp Müller 2011-04-09 19:03:27 UTC 
If I'm not mistaken, this indicates a severe bug in some element and it's not something that should ever happen under normal circumstances. It's not an error in the sense that it's fatal, but it's still an error really. It would be equally valid to just error out IMHO, the fact that we're doing a fallback here is just us being nice.

I think we should keep this at ERROR debug level, because git builds of GStreamer core default to GST_DEBUG=*:1, and I think this is really something we'd like to know about if it happened. If things like this don't warrant an ERROR debug level, what does?
Comment 3 Haakon Sporsheim (ieei) 2011-04-09 19:15:31 UTC 
True, this is probably a patch I will keep around at my end. We have some requirements to how memory and buffers are allocated, so we have some local patches which perform trickery which again makes this happen. I originally thought this was a good idea, but maybe warning would be better. Anyway, after Tim-Philipps comment it made me realize that this is nothing you want to have upstream.
Comment 4 Tim-Philipp Müller 2012-01-05 10:24:09 UTC 
*** Bug 667304 has been marked as a duplicate of this bug. ***