GNOME Bugzilla – Bug 328452
Rhytmbox crashes with 0.10.1
Last modified: 2006-02-08 17:27:10 UTC
Steps to reproduce: I don't belive this is the cause of a specific file. It crashes at different points all the time. It wasn't solved by upgrading to ugly-0.10.1. gst-inspect-0.10 | grep id3 id3demux: id3demux: ID3 tag demuxer typefindfunctions: application/x-id3: mp3, mp2, mp1, mpga, ogg, flac, tta mad: id3mux: id3 muxer I'll attach the output of GST_DEBUG=*:5 rhythmbox > rbcrash.txt 2>&1 also. This is on Ubuntu Dapper. Stack trace: Program received signal SIGSEGV, Segmentation fault.
+ Trace 65559
Thread NaN (LWP 6072)
Other information:
Created attachment 58031 [details] Debug output
Is it possible to get say, the first 64KB of: file:///media/mp3/Musik/H%C3%A5kan%20Lidbo%20feat.%202KHZ/=%20OTHER%20II%20=/08%20Bad%20girls%20go%20to%20hell%20(original%20mi.mp3 ? That's the file that debug output crashed on. dd if=/media/mp3/Musik/.. bs=1024 count=64 of=bad-id3v2.mp3 should do the trick. Either mail the file, or provide a link to an uploaded location would be best, rather than placing it in bugzilla.
Ah, I've found something interesting. So I removed the song, but RB still crashed. Ok? I tried gst-launch ... id3demux on it, and that worked fine. I removed all my songs by Håkan Lidbo, and now rb worked. What gives? It was the directory! The = signs in the dir name causes the crash. They don't affect gst-lauch but when rb runs the pipeline it crashes. It's easily reproduced, just add a = to any dir, let RB rescan it and it crashes. The backtrace puts the crash in gst code so it shouldn't be a rhythmbox bug, specially since Rhythmbox tought this dir was ok with the old id3demux.
Oops, rhythmbox fooled me. Must have been the 10 second delay in rescanning songs that synced with my changes. :-) Ok, so it's not the = signs, it's the songs. Both songs in that dir crashes RB. I'll mail the file-segements to you right away!
Thanks for the sample files. Fixed in CVS: * gst/id3demux/id3v2frames.c: (id3demux_id3v2_parse_frame): Never trust ANY information encoded in a media file, especially when it's giving you sizes. (Fixes #328452)