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 332392 - rhythmbox 0.9.3.1_p1 crashes on file import
rhythmbox 0.9.3.1_p1 crashes on file import
Status: RESOLVED DUPLICATE of bug 329198
Product: GStreamer
Classification: Platform
Component: gst-plugins-ugly
0.10.2
Other other
: High critical
: NONE
Assigned To: GStreamer Maintainers
GStreamer Maintainers
Depends on:
Blocks:
 
 
Reported: 2006-02-24 00:52 UTC by Manuel Friedli
Modified: 2006-03-11 12:54 UTC
See Also:
GNOME target: ---
GNOME version: 2.13/2.14



Description Manuel Friedli 2006-02-24 00:52:03 UTC
Distribution: Gentoo Base System version 1.12.0_pre16
Package: rhythmbox
Severity: critical
Version: GNOME2.13.91 0.9.x
Gnome-Distributor: Gentoo
Synopsis: rhythmbox 0.9.3.1_p1 crashes on file import
Bugzilla-Product: rhythmbox
Bugzilla-Component: Importing
Bugzilla-Version: 0.9.x
BugBuddy-GnomeVersion: 2.0 (2.13.3)
Description:
Description of the crash:
a few seconds after startup, when updating/refreshing the song db,
or when manually adding files to the song db, rhythmbox crashes
with the following error displayed on the console:

GStreamer-CRITICAL **: gst_pad_activate_pull: assertion `old ==
GST_ACTIVATE_NONE' failed
aborting...

the window remains open and an error dialog pops up, saying

rhythmbox has crashed unexpectedly
[restart app] [close] [report bug]

if a song is playing while RB crashes, the song will continue to play,
but after it is finished, the next song is not played. this crash has also
happened when no song was played at all and the song db was getting
refreshed.

Steps to reproduce the crash:
1. start rhythmbox, it will refresh the song database
2. play a song, or simply wait
3. wait for the crash

Expected Results:
rhythmbox should import songs/refresh the database without crashing.

How often does this happen?
it happens everytime, sometimes after just a few seconds (2-3),
sometimes after a little longer, maybe 30,40 seconds.

Additional Information:
distro: Gentoo
versions of installed software
rhythmbox: 0.9.3.1_p1
gstreamer: 0.8.11, 0.10.3 (RB was built against 0.10.3)
gst-plugins: 0.8.11
gst-plugins-base: 0.10.3
gst-plugins-good: 0.10.2
gst-plugins-ugly: 0.10.1
gst-plugins-a52dec: 0.8.11, 0.10.1
gst-plugins-alsa: 0.8.11, 0.10.3
gst-plugins-cdparanoia: 0.8.11, 0.10.3
gst-plugins-dvdnav: 0.8.11
gst-plugins-dvdread: 0.8.11
gst-plugins-esd: 0.8.11, 0.10.2
gst-plugins-faad: 0.8.11, 0.10.0
gst-plugins-ffmpeg: 0.8.7-r1, 0.10.0-r1
gst-plugins-flac: 0.8.11, 0.10.2
gst-plugins-gnomevfs: 0.8.11, 0.10.3
gst-plugins-mad: 0.8.11, 0.10.1
gst-plugins-mpeg2dec: 0.8.11, 0.10.1
gst-plugins-ogg: 0.8.11, 0.10.3
gst-plugins-pango: 0.8.11, 0.10.3
gst-plugins-pitfdll: 0.8.1-r1
gst-plugins-theora: 0.8.11, 0.10.3
gst-plugins-vorbis: 0.8.11, 0.10.3
gst-plugins-xvideo: 0.8.11, 0.10.3



Debugging Information:

Backtrace was generated from '/usr/bin/rhythmbox'

Using host libthread_db library "/lib/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its
symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1225066832 (LWP 20882)]
[New Thread -1290679376 (LWP 20925)]
[New Thread -1243972688 (LWP 20895)]
[New Thread -1264583760 (LWP 20892)]
[New Thread -1243497552 (LWP 20884)]
[New Thread -1235104848 (LWP 20883)]
0xffffe410 in __kernel_vsyscall ()
  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/libc.so.6
  • #2 g_main_context_acquire
    from /usr/lib/libglib-2.0.so.0
  • #3 ??
  • #4 ??
  • #5 ??
  • #6 ??
  • #7 ??
  • #8 ??
  • #9 ??
  • #10 ??
    from /usr/lib/libglib-2.0.so.0
  • #11 ??
  • #12 ??
  • #13 ??
  • #14 g_main_loop_run
    from /usr/lib/libglib-2.0.so.0
  • #15 ??
  • #16 ??
  • #17 bonobo_main
    from /usr/lib/libbonobo-2.so.0
  • #18 ??
  • #19 main
    at main.c line 398




------- Bug created by bug-buddy at 2006-02-24 00:52 -------

Comment 1 Alex Lancaster 2006-02-24 01:39:13 UTC
Thanks for the bug report. Unfortunately, that stack trace is not very useful in determining the cause of the crash. Can you get us one with debugging symbols? Please see http://live.gnome.org/GettingTraces for more information on how to do so.

It is probably something specifically related to one or more of your music files.  Can you narrow down the list of files to determine which one might be causing the problem?  I suggest backing-up your ~/.gnome/rhythmbox/rhythmdb.xml and then reimporting directories and/or files until you can narrow it down to a specific file or files.  There were some problems with OGG files that have been fixed in CVS, IIRC.
Comment 2 Alex Lancaster 2006-02-24 01:40:06 UTC
(In reply to comment #1)
 
> It is probably something specifically related to one or more of your music
> files.  Can you narrow down the list of files to determine which one might be
> causing the problem?  I suggest backing-up your ~/.gnome/rhythmbox/rhythmdb.xml

That should be ~/.gnome2/rhythmbox/rhythmdb.xml.
Comment 3 Manuel Friedli 2006-02-24 02:32:36 UTC
i've found a file that causes a crash, it's an MP3. should i attach it here (it's 5.5 MB!)? or is there some kind of tool that can extract valuable information from the harmful MP3?
mplayer tells me this:

AUDIO: 44100 Hz, 2 ch, s16le, 192.0 kbit/13.61% (ratio: 24000->176400)
Selected audio codec: [mp3] afm:mp3lib (mp3lib MPEG layer-2, layer-3)

i'm compiling all necessary packages with debug symbols; right now i'm re-compiling GTK+, so it will take a while till i've got a complete backtrace. what i've got so far is this:

Backtrace was generated from '/usr/bin/rhythmbox'

Using host libthread_db library "/lib/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1225582928 (LWP 31607)]
[New Thread -1244013648 (LWP 31609)]
[New Thread -1235620944 (LWP 31608)]
0xffffe410 in __kernel_vsyscall ()
  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/libc.so.6
  • #2 _XWaitForReadable
    at XlibInt.c line 498
  • #3 _XRead
    at XlibInt.c line 1080
  • #4 _XReply
    at XlibInt.c line 1712
  • #5 XGetWindowProperty
    at GetProp.c line 64
  • #6 gdk_window_get_frame_extents
    from /usr/lib/libgdk-x11-2.0.so.0
  • #7 ??

it's strange, even though in the console it complains about a gstreamer error, here it looks like it's related to gdk/gtk/X/whatever. but i'm no expert at these things...

i'll post a complete backtrace once i've got all necessary packages compiled with debug symbols. thanks for taking care of this bug!
Comment 4 Manuel Friedli 2006-02-24 03:01:48 UTC
ok, here we go, i hope this helps:

Backtrace was generated from '/usr/bin/rhythmbox'

Using host libthread_db library "/lib/libthread_db.so.1".
`system-supplied DSO at 0xffffe000' has disappeared; keeping its symbols.
[Thread debugging using libthread_db enabled]
[New Thread -1226283344 (LWP 5190)]
[New Thread -1244714064 (LWP 5192)]
[New Thread -1236321360 (LWP 5191)]
0xffffe410 in __kernel_vsyscall ()
  • #0 __kernel_vsyscall
  • #1 poll
    from /lib/libc.so.6
  • #2 _XWaitForReadable
    at XlibInt.c line 498
  • #3 _XRead
    at XlibInt.c line 1080
  • #4 _XReply
    at XlibInt.c line 1712
  • #5 XkbGetState
    at XKB.c line 493
  • #6 update_direction
    at gdkkeys-x11.c line 499
  • #7 _gdk_keymap_state_changed
    at gdkkeys-x11.c line 573
  • #8 gdk_event_translate
    at gdkevents-x11.c line 2050
  • #9 _gdk_events_queue
    at gdkevents-x11.c line 2225
  • #10 gdk_event_dispatch
    at gdkevents-x11.c line 2285
  • #11 IA__g_main_context_dispatch
    at gmain.c line 1916
  • #12 g_main_context_iterate
    at gmain.c line 2547
  • #13 IA__g_main_loop_run
    at gmain.c line 2751
  • #14 bonobo_main
    at bonobo-main.c line 312
  • #15 main
    at main.c line 398

versions of the software:
glib: 2.9.6
libX11: 1.0.0 (gentoo numbering scheme: 1.0.0-r1)
gtk+: 2.8.12
libbonobo: 2.13.1
Comment 5 James "Doc" Livingston 2006-02-24 03:20:10 UTC
Manuel: can you get the backtrace with "thread apply all bt" instead?
Comment 6 Manuel Friedli 2006-02-24 10:34:26 UTC
(In reply to comment #5)
> Manuel: can you get the backtrace with "thread apply all bt" instead?
> 

well that doesn't say much, only this:

gdb> thread apply all bt
  3 Thread -1235649616 (LWP 22746)  0xffffe410 in __kernel_vsyscall ()
  2 Thread -1244042320 (LWP 22747)  0xffffe410 in __kernel_vsyscall ()
  1 Thread -1225611600 (LWP 22745)  0xffffe410 in __kernel_vsyscall ()

Comment 7 Jonathan Matthew 2006-03-09 09:46:21 UTC
Can you try running 'gst-launch-0.10 -t filesrc location=/path/to/broken.mp3 ! decodebin ! fakesink'?  If this crashes, it's definitely a gstreamer issue.  If not, it's something more interesting, and we'll have to figure out why 'thread apply all bt' isn't working properly for you.
Comment 8 Manuel Friedli 2006-03-11 10:45:57 UTC
you're right, it crashes with the following error:

Setting pipeline to PAUSED ...

GStreamer-CRITICAL **: gst_pad_activate_pull: assertion `old == GST_ACTIVATE_NONE' failed
aborting...
Trace/Breakpoint ausgelöst

(the last message is german, in english it would be something like "Triggered Trace/Breakpoint")
Comment 9 Alex Lancaster 2006-03-11 11:21:17 UTC
Refiling it as a gst-plugins-ugly crash (since it's an mp3 file).
Comment 10 Tim-Philipp Müller 2006-03-11 12:54:11 UTC
This happens when GStreamer doesn't recognise the file as mp3 file (either through the typefind element, or when doing secondary typefinding in the id3demux element). Usually this happens when there's a lot of "garbage" at the beginning of an mp3 file before the mpeg audio data (and possibly after any ID3 tags), like with AlbumWrap'ed files.

The recognition issue should be fixed when using GStreamer core 0.10.4, -base 0.10.4 and id3demux/apedemux from gst-plugins-good CVS.

The assertion should still not be triggered of course, see bug #329198.


*** This bug has been marked as a duplicate of 329198 ***