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 132343 - rhythmbox crashes after switching songs
rhythmbox crashes after switching songs
Status: RESOLVED DUPLICATE of bug 120125
Product: rhythmbox
Classification: Other
Component: general
0.6.4
Other other
: High critical
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 128162 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2004-01-23 23:28 UTC by russell
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description russell 2004-01-23 23:29:06 UTC
Distribution: Debian testing/unstable
Package: rhythmbox
Severity: critical
Version: GNOME2.4.1 0.6.4
Gnome-Distributor: Debian
Synopsis: rhythmbox crashes after switching songs
Bugzilla-Product: rhythmbox
Bugzilla-Component: General
Bugzilla-Version: 0.6.4
BugBuddy-GnomeVersion: 2.0 (2.4.0.1)
Description:
Description of the crash:

After playing several songs, the program crashes when attempting to load
a new song with the message:

	Xlib: unexpected async reply (sequence 0xe3d3)!

Steps to reproduce the crash:
1. start rhythmbox
2. skip to the next song
3. repeat from (2) until crash

Expected Results:

Well, one would expect the program not to crash, generally. 
(sorry, just filling in the BugBuddy fields!  ^_^ )

How often does this happen?

Sometimes immediately, somtimes after dozens or hundreds of songs.
Usually after ten or fifteen, though that is only a guess.

So far, it happens every time I use rhythmbox, although with variable
intervals between crashes. I suspected at first that it was due to corrupt mp3
files, but I've made note of the current song and next song, and been able to
sucessfully repeat the song skip without a crash. I've never seen the Xlib error in
my experience with GTK programming, but it may also be a red herring. 

Additional Information:

I've tried this with local and NFS mounted filesystems, and noted the
same crash.

Debugging Information:

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

(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...[New Thread 1087898272 (LWP 3772)]
[New Thread 1136348080 (LWP 3804)]
[New Thread 1087898272 (LWP 3772)]
[New Thread 1136348080 (LWP 3804)]
[New Thread 1087898272 (LWP 3772)]
[New Thread 1136348080 (LWP 3804)]
[New Thread 1124043696 (LWP 3776)]
[New Thread 1115655088 (LWP 3775)]
[New Thread 1107266480 (LWP 3774)]
[New Thread 1098877872 (LWP 3773)]
(no debugging symbols found)...(no debugging symbols found)...(no
debugging symbols found)...(no debugging symbols found)...(no debugging
symbols found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...(no debugging symbols found)...(no debugging symbols
found)...0x40b93787 in select () from /lib/tls/libc.so.6

Thread 2 (Thread 1136348080 (LWP 3804))

  • #0 __waitpid_nocancel
    from /lib/tls/libpthread.so.0
  • #1 libgnomeui_module_info_get
    from /usr/lib/libgnomeui-2.so.0
  • #2 <signal handler called>
  • #3 gst_mad_get_type
    from /usr/lib/gstreamer-0.6/libgstmad.so
  • #4 gst_mad_get_type
    from /usr/lib/gstreamer-0.6/libgstmad.so
  • #5 gst_mad_get_type
    from /usr/lib/gstreamer-0.6/libgstmad.so
  • #6 gst_pad_push
    from /usr/lib/libgstreamer-0.6.so.0
  • #7 ??
    from /usr/lib/gstreamer-0.6/libgstoptscheduler.so
  • #8 ??
  • #9 ??




------- Bug moved to this database by unknown@bugzilla.gnome.org 2004-01-23 18:29 -------

The original reporter (russell@ccs.neu.edu) of this bug does not have an account here.
Reassigning to the exporter, unknown@bugzilla.gnome.org.
Reassigning to the default owner of the component, rhythmbox-maint@bugzilla.gnome.org.

Comment 1 Elijah Newren 2004-02-12 03:48:42 UTC
*** Bug 128162 has been marked as a duplicate of this bug. ***
Comment 2 Elijah Newren 2004-02-12 03:54:02 UTC
Thread 2 (gst_mad_get_type) makes this look somewhat like bug 120125,
but since the reporter noted that the error they saw in the terminal was
  Xlib: unexpected async reply (sequence 0xe3d3)!
That makes me think that thread 2 isn't the important one.  But I
mention it because bug 123368 basically had a stack trace like this
one and it was marked as a dup of 120125 due to some non-main thread
having gst_mad_get_type in it.

Hopefully the steps the reporter gave are enough to track this down;
I'm just going to tack on the bugsquad keyword and set some fields
appropriately.
Comment 3 Colin Walters 2004-04-13 03:24:03 UTC
I believe this is actually the same as bug 120125.  The Xlib error could happen
with bug-buddy being called from a separate thread.

Elijah: Thread 2 is definitely the important one, because that's where you see
<signal handler called>, meaning the error originated in there.  

Without more information it's hard to be sure it's a duplicate of 120125, but it
seems likely.



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