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 300791 - gstreamer grows until the linux OOM killer steps in with one mp3
gstreamer grows until the linux OOM killer steps in with one mp3
Status: RESOLVED DUPLICATE of bug 162647
Product: GStreamer
Classification: Platform
Component: gst-plugins
0.8.9
Other Linux
: Normal critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-04-15 20:11 UTC by Ernst Sjöstrand
Modified: 2005-04-17 20:44 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Ernst Sjöstrand 2005-04-15 20:11:16 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
Comment 1 Ernst Sjöstrand 2005-04-15 20:15:32 UTC
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
Comment 2 Tim-Philipp Müller 2005-04-16 11:15:56 UTC
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
Comment 3 Ronald Bultje 2005-04-16 12:11:24 UTC
I already send that fix to the id3tag maintainers two months ago.
Comment 4 Ronald Bultje 2005-04-16 12:12:36 UTC
http://bugzilla.gnome.org/show_bug.cgi?id=162647

That one.
Comment 5 Tim-Philipp Müller 2005-04-16 12:51:56 UTC
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
Comment 6 Ronald Bultje 2005-04-16 13:18:30 UTC
After 3 tries, yes. He's not very responsive. He said he would integrate it.
Feel free to re-send to mad-dev.
Comment 7 Ronald Bultje 2005-04-17 20:44:14 UTC

*** This bug has been marked as a duplicate of 162647 ***