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 0x 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 = 0xb74812a0, open_mode = 3085955824}
The buffer had binary data in it..maybe gorp, not sure if it had somehow
read something from somewhere..
BACKTRACE OF ANOTHER THREAD DOING VFS WORK
-
[Switching to thread 5 (process 28302)]#0 0xe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xe410 in __kernel_vsyscall ()
#1 0xb7c9c428 in connect () from /lib/tls/i686/cmov/libpthread.so.0
#2 0xb735582a in gnome_vfs_inet_connection_create_from_address (
connection_return=0x822b940, address=0x8b85ba8, host_port=80,
cancellation=0x8a76ce0) at gnome-vfs-inet-connection.c:176
#3 0xb238f1ed in ne_sock_connect ()
from /usr/lib/gnome-vfs-2.0/modules/libhttp.so
#4 0xb2382777 in ?? () from /usr/lib/gnome-vfs-2.0/modules/libhttp.so
#5 0x0822b940 in ?? ()
#6 0x08b85ba8 in ?? ()
#7 0x0050 in ?? ()
#8 0x081e71b0 in ?? ()
#9 0xb238ff42 in ?? () from /usr/lib/gnome-vfs-2.0/modules/libhttp.so
#10 0x in ?? ()
Since I don't know how VFS works, I'm not sure if this is a "worker"
thread which actually makes the connections, or whether this is
something totally unrelated. However, if it is, I assume this is
supposed to be the thread making the connection to the URI.. I tried to
dig around and find the address, but I ran out of time to look into
this.. if someone wants the core file, let me know and I can attach.
(gdb) print *address
$10 = {sa = 0x8b85130}
(gdb) print *address->sa
$11 = {sa_family = 2, sa_data = "\000\000H\025�\b\000\000\000\000\000\000\000"}
(gdb) print *address
(gdb) x/32x address->sa->sa_data
0x8b85132: 0x1548 0x08cf 0x 0x0018
0x8b85142: 0x0031 0x7061 0x63696c70 0x6f697461
0x8b85152: 0x6e762f6e 0x61