GNOME Bugzilla – Bug 623240
Memory allocation fails when reading .xm (audio/x-mod) file metadata
Last modified: 2012-01-31 19:02:33 UTC
Created attachment 164993 [details] Dumps The attachment is a dump from Rhythmbox launched with the "-d" switch, but I've the same error with Quodlibet (see my previous bug report here: https://bugzilla.redhat.com/show_bug.cgi?id=585545). As you can see in the attachment, the bug raises not when processing a particular tag but "randomly" while reading metadata of a .xm file. Moreover, sometimes the error is "realloc(): invalid next size" whereas sometimes it's "malloc(): memory corruption".
Can you post a file that exhibits the problem ? I don't have xm files apparently, and I don't see the problem with s3m/mod/it (using gst-launch with playbin2 using modplug). Thanks
I just tried to play some bogus xm files and I have no error as before (GStreamer 0.10.31). I attached an example file if you want to try but I think you can close the bug.
Created attachment 177714 [details] Example XM file
Seems fine with that file as well. I noticed a little bug in libmodplug with Impulse Tracker modules, though, patch below (Sourceforge doesn't seem to want me to post that patch on the modplug tracker). I doubt it'd cause memory corruption, but it depends how delete/delete[] are implemented. In any case, that issue doesn't seem to be with gstreamer itself. diff --git a/libmodplug/src/sndfile.cpp b/libmodplug/src/sndfile.cpp index 4cb0646..1145986 100644 --- a/libmodplug/src/sndfile.cpp +++ b/libmodplug/src/sndfile.cpp @@ -285,12 +285,12 @@ BOOL CSoundFile::Destroy() m_nPatternNames = 0; if (m_lpszPatternNames) { - delete m_lpszPatternNames; + delete[] m_lpszPatternNames; m_lpszPatternNames = NULL; } if (m_lpszSongComments) { - delete m_lpszSongComments; + delete[] m_lpszSongComments; m_lpszSongComments = NULL; } for (i=1; i<MAX_SAMPLES; i++)
This may be a bug in modplug it seems: <slomo> tpm: yes, modplug believes that long is a 32 bit integer <slomo> tpm: causing it to write twice as much data as it should on amd64 Marking as duplicate of bug #614361 *** This bug has been marked as a duplicate of bug 614361 ***
Oh sorry, wrong bug
Testing again here, I see no memory corruption playing with playbin2, or using gst-discoverer. Valgrind's happy about it too. Most likely, either the bug is fixed, or lies elsewhere. If you can repdroduce it with gst-launch, can you please run valgrind on it, eg: G_SLICE=always-malloc valgrind --leak-check=full --suppressions=/.../gstreamer/common/gst.supp --suppressions=/.../gst-plugins-base/tests/check/gst-plugins-base.supp --suppressions=/.../gst-plugins-good/tests/check/gst-plugins-good.supp --suppressions=/.../gst-plugins-bad/tests/check/gst-plugins-bad.supp --suppressions=/.../gst-plugins-ugly/tests/check/gst-plugins-ugly.supp gst-launch-0.10 uri=file:///.../test.xm Then attach the output and reopen.