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 142555 - wavparse doesn't handle truncated files gracefully
wavparse doesn't handle truncated files gracefully
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins
git master
Other Linux
: Normal normal
: 0.8.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2004-05-14 17:44 UTC by Christophe Fergeau
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Christophe Fergeau 2004-05-14 17:44:55 UTC
I found what could be a bug in wavparse or riff-read when using it
though. When downloading this file, I stopped the download before it
completed, but tried to play the file.
gst-launch then complains about trying to push a NULL buffer. 
After gdb-ing a bit, I found that wavparse calls
gst_riff_read_element_data asking it to read XXX bytes, this function
can't read that many bytes so it returns NULL and then wavparse pushes
that NULL. It probably happens when reaching the end of my truncated
file even though I didn't check.
I was wondering if it was intentional that gst_riff_read_element_data
basically does:
if ((got = gst_bytestream_peek (riff->bs, &buf, length)) != length) {
        return NULL;
}
return buf;

or if it should be more clever? (for example, return buffers whose
length is smaller than the length asked to the function, or try a bit
harder to get a full buffer).
Comment 1 Stephane Loeuillet 2004-05-14 17:51:15 UTC
if wavparse has this bug, then cdxaparse has it too (i ripped iain's wavparse code)
Comment 2 Ronald Bultje 2004-05-16 20:09:24 UTC
Fixed as a side-effect of prettifying wavdemux a bit.