GNOME Bugzilla – Bug 332964
random crashes in mp3_type_find
Last modified: 2006-03-09 16:30:48 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.
Created attachment 60377 [details] The text of two separate backtraces generated from gdb
If this crash is reproducible on those files, could you provide a sample file that causes it? Thanks.
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.
Created attachment 60465 [details] Another backtrace, and some variable values
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.
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.
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/foo.data ==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)
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).