GNOME Bugzilla – Bug 540336
[mad] Valgrind warns about uninitialised value in output buffers
Last modified: 2011-08-09 09:36:07 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
Created attachment 113467 [details] The valgrind log
Created attachment 113468 [details] mp3 file that causes the problem
You forgot to happen that this only happens on your 64bit machine and I'm not able to reproduce it on 32bit.
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.
It seems to indeed be in the mad plugin. The bug and valgrind warnings disappear when testing with Fluendo's mp3 plugin.
I bet it also happens when running gst-launch-0.10 -v filesrc location=682.mp3 ! mad ! volume ! fakesink Is this correct? :)
I can see the errors in valgrind with the line from #Comment 6
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.
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