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 323226 - block/crash on id3 v2 tags when using big blocksize
block/crash on id3 v2 tags when using big blocksize
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.9.7
Other All
: Normal normal
: 0.10.1
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2005-12-04 21:44 UTC by Senko Rasic
Modified: 2006-01-13 15:37 UTC
See Also:
GNOME target: ---
GNOME version: 2.11/2.12



Description Senko Rasic 2005-12-04 21:44:45 UTC
Please describe the problem:
The pipeline blocks (see below for example) or crashes (in Diva / Gdv)
when invoked on a mp3 file with id3 v2 tag set, if the blocksize
argument is bigger than the file size.
From the debug output, it seems like something in gstid3tag.c (I've been
unable to pinpoint the culprit) is trying to seek forward by a blocksize
bytes. If blocksize is very large, it seeks beyond the end of the file, and
subsequent read returns 0 bytes, and gstid3tag reports EOS.

When not using blocksize (or when setting blocksize to some smaller number),
no problems occurr.

Steps to reproduce:
1. Download trunk/Diva/tests/Media/mp3_tagged.mp3 from Diva svn:
http://forge.novell.com/modules/xfmod/svn/svnbrowse.php?uri=filedetails.php%3Frepname%3Ddiva%26path%3D%252Ftrunk%252FDiva%252Ftests%252Fmedia%252Fmp3_tagged.mp3%26rev%3D0%26sc%3D0
2. Try to play it:
gst-launch-0.9 --gst-debug-level=4 filesrc location="mp3_tagged.mp3"
blocksize=1000000 ! decodebin ! osssink



Actual results:
The pipeline hangs. The debugging output snippet:
DEBUG (0x80cfbe8 - 0:00:00.829809000)               id3tag(16006)
gstid3tag.c(844):gst_id3_tag_sink_event:<id3demux0> Have new segment event in mode 1
DEBUG (0x80cfbe8 - 0:00:00.829891000)              basesrc(16006)
gstbasesrc.c(853):gst_base_src_get_range:<filesrc0> reading offset 161920,
length 1000000, size 161920, segment.stop -1, maxsize 161920     
GST_PADS(16006) gstpad.c(3767):gst_pad_pause_task:<id3demux0:sink> pad has no task
DEBUG (0x80cfbe8 - 0:00:00.829961000)              basesrc(16006)
gstbasesrc.c(929):gst_base_src_get_range:<filesrc0> unexpected length 0
(offset=161920, size=161920)ally linked pads
DEBUG (0x80cfbe8 - 0:00:00.830020000)              basesrc(16006)
gstbasesrc.c(1008):gst_base_src_loop:<filesrc0> going to EOS, getrange returned
UNEXPECTED



Expected results:
The tag is found and the playback continues normally

Does this happen every time?
Yes

Other information:
Comment 1 Edward Hervey 2005-12-10 11:23:20 UTC
Why are you using such a big blocksize anyway ?
Comment 2 Tim-Philipp Müller 2005-12-10 11:35:17 UTC
id3demux knows nothing about filesrc's blocksize. The debug snippet you quoted
is perfectly normal when filesrc operates in push mode. I think id3demux
probably gets confused if it gets an EOS event before having pushed out any data
or something.

I'm redoing id3demux a bit at the moment and will try to fix this as well in the
process.
Comment 3 Edward Hervey 2006-01-07 18:17:54 UTC
This works fine with latest id3demux in cvs.