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 540336 - [mad] Valgrind warns about uninitialised value in output buffers
[mad] Valgrind warns about uninitialised value in output buffers
Status: RESOLVED NOTGNOME
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.18
Other Linux
: Normal normal
: git master
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-06-26 14:51 UTC by Pekka Lampila
Modified: 2011-08-09 09:36 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
The valgrind log (41.60 KB, text/plain)
2008-06-26 14:53 UTC, Pekka Lampila
Details
mp3 file that causes the problem (476.00 KB, audio/mpeg)
2008-06-26 14:55 UTC, Pekka Lampila
Details

Description Pekka Lampila 2008-06-26 14:51:20 UTC
We got an issue in Swfdec where gstreamer returns an invalid buffer size when decoding certain mp3 file, making things crash and burn.

Trying to figure out what's wrong, the following valgrind warning seemed most suspicious:

==799== Conditional jump or move depends on uninitialised value(s)
==799==    at 0x9944AC4: gst_audio_quantize_quantize_signed_tpdf_none (gstaudioquantize.c:314)
==799==    by 0x993FE94: audio_convert_convert (audioconvert.c:587)
==799==    by 0x993D4BA: gst_audio_convert_transform (gstaudioconvert.c:981)
==799==    by 0x8212C02: gst_base_transform_handle_buffer (gstbasetransform.c:1471)

This is from running:
gst-launch-0.10 -v filesrc location=682.mp3 ! mad ! audioresample ! audioconvert ! 'audio/x-raw-int,endianness=byte_order,signed=(boolean)true,width=16,depth=16,rate=44100,channels=2' ! fakesink

My gstreamer version is 0.10.18 from Ubuntu Hardy

I will upload the full log and the mp3 file
Comment 1 Pekka Lampila 2008-06-26 14:53:03 UTC
Created attachment 113467 [details]
The valgrind log
Comment 2 Pekka Lampila 2008-06-26 14:55:10 UTC
Created attachment 113468 [details]
mp3 file that causes the problem
Comment 3 Benjamin Otte (Company) 2008-06-26 15:04:48 UTC
You forgot to happen that this only happens on your 64bit machine and I'm not able to reproduce it on 32bit.
Comment 4 Sebastian Dröge (slomo) 2008-06-27 09:35:45 UTC
From looking at the actual code there the only thing that could be uninitialized is the input buffer to that function. As mad outputs 32 bit samples in the format that is the intermediate one for audioconvert, that file has the same sampling rate as the capsfilter afterwards, the input buffer to that function is actually what mad has pushed downstream.

So my guess is, that this bug lies somewhere in mad or the mad gstreamer element.
Comment 5 Pekka Lampila 2008-06-27 22:48:22 UTC
It seems to indeed be in the mad plugin.

The bug and valgrind warnings disappear when testing with Fluendo's mp3 plugin.
Comment 6 Sebastian Dröge (slomo) 2008-06-28 11:29:39 UTC
I bet it also happens when running
gst-launch-0.10 -v filesrc location=682.mp3 ! mad ! volume ! fakesink

Is this correct? :)
Comment 7 Wim Taymans 2010-01-27 10:11:53 UTC
I can see the errors in valgrind with the line from #Comment 6
Comment 8 Vincent Penquerc'h 2011-01-07 11:44:17 UTC
On 64 bit, I see those errors too.
Trying the minimad minimal decoder from libmad, they're also present.
In addition, I get the telltale messages before valgrind moans:

decoding error 0x0235 (bad main_data_begin pointer) at byte offset 0
decoding error 0x0238 (Huffman data overrun) at byte offset 9195
decoding error 0x0238 (Huffman data overrun) at byte offset 94877

So it looks like libmad not quite properly handling badly formed streams.
Comment 9 Stefan Sauer (gstreamer, gtkdoc dev) 2011-03-27 20:01:03 UTC
So this seems to be an upstream issue. File a bug against libmad:
https://sourceforge.net/tracker/?func=detail&aid=3250295&group_id=12349&atid=112349