after a while (five minutes) listening music, it closes

[mvtti]

Binary package hint: rhythmbox

When I listen music while working in my computer, after 2 songs rythmbox closes, so I have to open again the program if I want lo listen more music, I really wonder why is this happening because is very uncomfortable opening the program several times

ProblemType: Bug
Architecture: i386
Date: Sun May 6 16:57:04 2007
DistroRelease: Ubuntu 7.04
ExecutablePath: /usr/bin/rhythmbox
Package: rhythmbox 0.10.0-0ubuntu2
PackageArchitecture: i386
ProcCmdline: rhythmbox
ProcCwd: /home/vitti
ProcEnviron:
 LANGUAGE=es_MX:es
 PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games
 LANG=es_MX.UTF-8
 SHELL=/bin/bash
SourcePackage: rhythmbox
Uname: Linux vitti-laptop 2.6.20-15-generic #2 SMP Sun Apr 15 07:36:31 UTC 2007 i686 GNU/Linux

[Karl Hegbloom (karl.hegbloom)]

Please run the program from a terminal and see if it prints anything when it exits. Before you run it, execute the command:

 ulimit -c unlimited

... so that it will produce a 'core' file if it crashes. If it does, then you should post that core dump to this bug ticket by using the 'apport-retrace' program, provided that you have it installed. If that is way beyond your present level, then please simply attach the "core" file itself to this ticket using the Launchpad web interface.

[Sebastien Bacher (seb128)]

Thanks for your bug report. Please try to obtain a backtrace http://wiki.ubuntu.com/DebuggingProgramCrash and attach the file to the bug report. This will greatly help us in tracking down your problem.

[mvtti (marcos-vitti)]

Thank you very much, I'll try to do all the instructions you gave me.

[Phil Estes (estesp)]

i'm having the same issue after upgrading to 7.04 (i386) yesterday. I use rhythmbox daily to listen to hours of music, so this is definitely a huge change with feisty as I can't get through 10 minutes or more of music. I will try and generate a core file and get a backtrace for the problem

[Phil Estes (estesp)]

Well, that was interesting--I'm not sure if I am having the same issue as the original submitter, but I can at least give details on what I found. I believe (and I'm ignoring other crash bugs related to gstreamer or specific songs/files that crash..) in my case this problem was exacerbated by a network that was in a weird state, and the fact that this was my first time with rhythmbox with album art fetching enabled (it wasn't in the standard edgy rhythmbox version).

I'll explain more:
1. I tripped over the fact that my network was partially misconfigured yesterday during the time I experienced the problem.. rather than being down, it was up with a valid IP on my home network, but I was VPN'ed into my work account (which adds routes for all internal networks), but I did *not* have my default route (through my home network gateway). Not sure how that happened, but that meant as I was working away (on work networks) it wasn't until hours later I tried to get to google and my webmail and found nothing outside my companies network was reachable. At this point I had already gathered the crash info.. since fixing this problem I can't generate the crash..
2. After fixing my network, I grabbed several debug sym debs for the memory regions showing up in the backtraces (rhythmbox and gnome-vfs). This seemed to point to the fact that rhythmbox was trying to use gnome-vfs to grab album art (someone more aware of the code could verify this).. but I was able to verify gnome-vfs is what crashed on a read(), and it was trying to reach a URL and make a connection. I assume if my network had been really down (eg. eth0 ifdown'ed) it wouldn't be trying to do any of that, but with the strange state my network was in, something couldn't handle the errors gracefully and ended up in a SIGSEGV

Here is some relevant data:

BACKTRACE OF THE THREAD IN SIGSEGV
------------------------------------------------
Core was generated by `rhythmbox'.
Program terminated with signal 11, Segmentation fault.
#0 0xb7354bdc in _gnome_vfs_handle_do_read (handle=0xb738e3e8,
    buffer=0x8cbe018, num_bytes=4096, bytes_read=0x88b7ac0, context=0x8a73610)
    at gnome-vfs-handle.c:132
132 gnome-vfs-handle.c: No such file or directory.
        in gnome-vfs-handle.c
(gdb) bt
#0 0xb7354bdc in _gnome_vfs_handle_do_read (handle=0xb738e3e8,
    buffer=0x8cbe018, num_bytes=4096, bytes_read=0x88b7ac0, context=0x8a73610)
    at gnome-vfs-handle.c:132
#1 0xb734fd18 in gnome_vfs_read_cancellable (handle=0xb738e3e8,
    buffer=0x8cbe018, bytes=4096, bytes_read=0x88b7ac0, context=0x8a73610)
    at gnome-vfs-cancellable-ops.c:135
#2 0xb7356fed in _gnome_vfs_job_execute (job=0x8fe6598)
    at gnome-vfs-job.c:1232
#3 0xb73562aa in thread_entry_point (data=0x8fe6598, user_data=0x0)
    at gnome-vfs-job-queue.c:65
#4 0xb703a4d8 in ?? () from /usr/lib/libglib-2.0.so.0
#5 0x08fe6598 in ?? ()
#6 0x00000000 in ?? ()

A couple of the structures:

(gdb) print *job
$2 = {handle = 0xb738e3e8, cancelled = 0, failed = 1, job_lock = 0x8192e10,
  notify_ack_condition = 0x8178528, op = 0x8406b70, job_handle = 0x3a,
  priority = 0}

(gdb) print *job->handle
$3 = {uri = 0x571e4, method_handle = 0xb74...

[Sebastien Bacher (seb128)]

the backtrace looks like bug #94893