GNOME Bugzilla – Bug 300791
gstreamer grows until the linux OOM killer steps in with one mp3
Last modified: 2005-04-17 20:44:14 UTC
Distribution/Version: Ubuntu Both these commands allocate memory until the system is out of memory. My ~3000 other mp3's work fine. Happens both on ubuntu hoary and ubuntu breezy. Mplayer can play this mp3 and display it's id3 tags. ernstp@zapp ~ $ gst-launch-ext-0.8 /tmp/16\ Kim.mp3 Running command-line gst-launch-0.8 filesrc location="/tmp/16 Kim.mp3" ! mad ! alsasink ernstp@zapp ~ $ gst-launch-0.8 filesrc location="/tmp/16\ Kim.mp3" ! id3tag -t
Oh, too large to attach of cource. Here's a link to a pretty stable but not so fast webserver: http://www.oalex.net/~ernstp/16 Kim.mp3
Looks like a broken tag and/or a bug in libid3tag. The problem seems to be the TDRC tag at the beginning, which is a string list in UTF-16 encoding. The data to parse is 3 bytes: ff fe 30 The first two are a little endian byte-order marker (BOM), which libid3tag interprets correctly. That leaves one byte, which is not a valid UTF-16 character. This is where libid3tag goes into an endless loop. It basically does: while (end - *ptr > 0) { ucs4 = id3_parse_string (ptr, end - *ptr, *encoding, 0); if (ucs4) append_string_to_list (ucs4); } and id3_parse_string() will return an empty string without advancing the pointer, so that while (end - *ptr) is always 1 => endless loop => endless memory allocation. Cheers -Tim
I already send that fix to the id3tag maintainers two months ago.
http://bugzilla.gnome.org/show_bug.cgi?id=162647 That one.
Maybe re-send it to the mad-dev mailing list as well, so that packagers are at least aware about it and can incorporate the patch into their packages? Doesn't look like there's gonna be a new libid3tag version any time soon, does it? Did you get a response from Rob at all? Cheers -Tim
After 3 tries, yes. He's not very responsive. He said he would integrate it. Feel free to re-send to mad-dev.
*** This bug has been marked as a duplicate of 162647 ***