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 332964 - random crashes in mp3_type_find
random crashes in mp3_type_find
Product: GStreamer
Classification: Platform
Component: gst-plugins-base
Other Linux
: Normal normal
: 0.10.4
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Reported: 2006-03-01 08:14 UTC by Gordon Messmer
Modified: 2006-03-09 16:30 UTC
See Also:
GNOME target: ---
GNOME version: ---

The text of two separate backtraces generated from gdb (7.60 KB, text/plain)
2006-03-01 08:15 UTC, Gordon Messmer
Another backtrace, and some variable values (4.54 KB, text/plain)
2006-03-02 08:37 UTC, Gordon Messmer
sample that demonstrates the bug (128.00 KB, application/octet-stream)
2006-03-09 16:09 UTC, Tim-Philipp Müller

Description Gordon Messmer 2006-03-01 08:14:52 UTC
I'm running FC5 test3, so I don't have any MP3 plugins loaded.

When importing a large library of ogg and mp3 files, rhythmbox will crash while loading arbitrary ogg files.  The crash appears to occur consistently in the mp3_type_find function.

I've removed rhythmbox's configuration files and run it in gdb several times in order to get a backtrace.  Each time I do this, the trace shows a different file open, and a SEGV in mp3_type_find.
Comment 1 Gordon Messmer 2006-03-01 08:15:58 UTC
Created attachment 60377 [details]
The text of two separate backtraces generated from gdb
Comment 2 Michael Smith 2006-03-01 10:10:38 UTC
If this crash is reproducible on those files, could you provide a sample file that causes it? Thanks.
Comment 3 Gordon Messmer 2006-03-01 17:08:46 UTC
It's not reproducible on specific files.  I'm able to play the two indicated in the backtraces, for instance, using "gst-launch".  Importing the same library repeatedly will crash on different files each time, but always at the same line of the same function.
Comment 4 Gordon Messmer 2006-03-02 08:37:13 UTC
Created attachment 60465 [details]
Another backtrace, and some variable values
Comment 5 Gordon Messmer 2006-03-02 08:43:44 UTC
Hoping that it helps, I ran the import again and let Rhythmbox crash.  This time in addition to the bt, I printed the values of most of the relevant variables.

It looks like maybe the logic for determining head_data is flawed?  If I'm reading this correctly, "(offset + 4 <= skipped + size)" evaluates true, so head_data is assigned a pointer value that begins before data, which would explain why reading from that pointer would cause a SEGV.

I guess my question would be why mp3_type_find is called on ogg files?

I'm not really using rhythmbox at the moment, so I'll just leave the gdb session running in its current state for a while.  Let me know if there's other data you want me to extract.  I'm not well versed with gdb, so the more explicit you can be with requests, the better for me.
Comment 6 Tim-Philipp Müller 2006-03-09 13:45:12 UTC
mp3_type_find is called on ogg files and other files precisely to find out what type of file a certain file is. That's pretty normal. GStreamer doesn't take the filename extension into account, as it often enough is wrong or misleading.

I've seen this myself in valgrind - confirming bug.
Comment 7 Tim-Philipp Müller 2006-03-09 16:09:22 UTC
Created attachment 60984 [details]
sample that demonstrates the bug

Sample data (for posterity), shows the bug in valgrind when using

  gst-launch-0.10 playbin uri=file:///path/to/

==27584== Invalid read of size 4
==27584==    at 0x4FE3F5F: mp3_type_find_at_offset (gsttypefindfunctions.c:629)
==27584==    by 0x4FE46C8: mp3_type_find (gsttypefindfunctions.c:718)
==27584==    by 0x4075FA2: gst_type_find_factory_call_function (gsttypefindfactory.c:243)
==27584==    by 0x4699C8A: gst_type_find_helper_get_range (gsttypefindhelper.c:223)
==27584==    by 0x4D19ECB: gst_type_find_element_activate (gsttypefindelement.c:673)
==27584==    by 0x405D732: gst_pad_set_active (gstpad.c:638)
==27584==    by 0x404BEA8: activate_pads (gstelement.c:2250)
==27584==    by 0x4056A53: gst_iterator_fold (gstiterator.c:503)
==27584==    by 0x404BF49: iterator_fold_with_resync (gstelement.c:2268)
==27584==    by 0x404C0E0: gst_element_pads_activate (gstelement.c:2317)
==27584==    by 0x404C41F: gst_element_change_state_func (gstelement.c:2354)
==27584==    by 0x4D1A168: gst_type_find_element_change_state (gsttypefindelement.c:722)
==27584==  Address 0x4FEDBE6 is 2 bytes before a block of size 2,048 alloc'd
==27584==    at 0x401B422: malloc (vg_replace_malloc.c:149)
==27584==    by 0x412AF36: g_malloc (gmem.c:131)
==27584==    by 0x403EE43: gst_buffer_new_and_alloc (gstbuffer.c:284)
==27584==    by 0x46C71D6: gst_gnome_vfs_src_create (gstgnomevfssrc.c:991)
==27584==    by 0x46907DE: gst_base_src_get_range (gstbasesrc.c:1195)
==27584==    by 0x4691497: gst_base_src_pad_get_range (gstbasesrc.c:1263)
==27584==    by 0x4061086: gst_pad_get_range (gstpad.c:3427)
==27584==    by 0x4050EB4: gst_proxy_pad_do_getrange (gstghostpad.c:220)
==27584==    by 0x469981B: helper_find_peek (gsttypefindhelper.c:107)
==27584==    by 0x4075B6E: gst_type_find_peek (gsttypefind.c:117)
==27584==    by 0x4FE3E96: mp3_type_find_at_offset (gsttypefindfunctions.c:604)
==27584==    by 0x4FE46C8: mp3_type_find (gsttypefindfunctions.c:718)
Comment 8 Tim-Philipp Müller 2006-03-09 16:30:48 UTC
Fixed in CVS:

2006-03-09  Tim-Philipp Müller  <tim at centricular dot net>

       * gst/typefind/gsttypefindfunctions.c: (mp3_type_find_at_offset):
         Fix invalid memory access to region before peek'd data (#332964).