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 328452 - Rhytmbox crashes with 0.10.1
Rhytmbox crashes with 0.10.1
Status: RESOLVED FIXED
Product: GStreamer
Classification: Platform
Component: gst-plugins-good
0.10.1
Other All
: Normal critical
: 0.10.2
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-01-24 17:24 UTC by Ernst Sjöstrand
Modified: 2006-02-08 17:27 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14


Attachments
Debug output (119.16 KB, application/x-gzip)
2006-01-24 17:25 UTC, Ernst Sjöstrand
Details

Description Ernst Sjöstrand 2006-01-24 17:24:04 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.

Thread NaN (LWP 6072)

  • #0 gconv
    from /usr/lib/gconv/ISO8859-1.so
  • #1 iconv_close
    from /lib/tls/i686/cmov/libc.so.6
  • #2 iconv
    from /lib/tls/i686/cmov/libc.so.6
  • #3 g_iconv
    from /usr/lib/libglib-2.0.so.0
  • #4 g_convert_with_iconv
    from /usr/lib/libglib-2.0.so.0
  • #5 g_convert
    from /usr/lib/libglib-2.0.so.0
  • #6 id3demux_id3v2_parse_frame
    from /usr/lib/gstreamer-0.10/libgstid3demux.so
  • #7 id3demux_read_id3v2_tag
    from /usr/lib/gstreamer-0.10/libgstid3demux.so
  • #8 gst_id3demux_get_type
    from /usr/lib/gstreamer-0.10/libgstid3demux.so
  • #9 simple_find_peek
    from /usr/lib/gstreamer-0.10/libgstid3demux.so
  • #10 gst_pad_set_active
    from /usr/lib/libgstreamer-0.10.so.0
  • #11 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #12 gst_iterator_fold
    from /usr/lib/libgstreamer-0.10.so.0
  • #13 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #14 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #15 gst_element_lost_state
  • #16 gst_id3demux_get_type
    from /usr/lib/gstreamer-0.10/libgstid3demux.so
  • #17 gst_element_continue_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #18 gst_element_lost_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #19 gst_element_set_state
    from /usr/lib/libgstreamer-0.10.so.0
  • #20 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #21 ??
  • #22 ??
  • #23 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #24 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #25 ??
  • #26 ??
  • #27 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #28 ??
  • #29 ??
  • #30 ??
  • #31 g_log_domain_gstreamer
    from /usr/lib/libgstreamer-0.10.so.0
  • #32 g_log_domain_gstreamer
    from /usr/lib/libgstreamer-0.10.so.0
  • #33 ??
  • #34 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #35 ??
    from /usr/lib/libgstreamer-0.10.so.0
  • #36 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #37 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #38 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #39 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #40 ??
    from /usr/lib/libgstreamer-0.10.so.0
  • #41 ??
  • #42 ??
    from /usr/lib/libgstreamer-0.10.so.0
  • #43 ??
  • #44 gst_element_get_static_pad
    from /usr/lib/libgstreamer-0.10.so.0
  • #45 ??
    from /usr/lib/gstreamer-0.10/libgstdecodebin.so
  • #46 ??
  • #47 ??

Other information:
Comment 1 Ernst Sjöstrand 2006-01-24 17:25:17 UTC
Created attachment 58031 [details]
Debug output
Comment 2 Jan Schmidt 2006-01-25 09:37:56 UTC
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.
Comment 3 Ernst Sjöstrand 2006-01-25 17:08:19 UTC
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.
Comment 4 Ernst Sjöstrand 2006-01-25 17:24:16 UTC
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!
Comment 5 Jan Schmidt 2006-01-25 18:26:01 UTC
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)