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 = 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 0xffffe410 in __kernel_vsyscall ()
(gdb) bt
#0 0xffffe410 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 0x00000050 in ?? ()
#8 0x081e71b0 in ?? ()
#9 0xb238ff42 in ?? () from /usr/lib/gnome-vfs-2.0/modules/libhttp.so
#10 0x00000000 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: 0x15480000 0x000008cf 0x00000000 0x00180000
0x8b85142: 0x00310000 0x70610000 0x63696c70 0x6f697461
0x8b85152: 0x6e762f6e 0x616f2e64 0x2e736973 0x6e65706f
0x8b85162: 0x75636f64 0x746e656d 0x7865742e 0x00000074
0x8b85172: 0x00218000 0x70610000 0x63696c70 0x6f697461
0x8b85182: 0x6e762f6e 0x736d2e64 0x6378652d 0x65006c65
0x8b85192: 0x00116964 0x6d690000 0x2f656761 0x66666974
0x8b851a2: 0x00190000 0x138c0000 0x234808c8 0x00000817
If the IP is in there somewhere, and it is somewhere on amazon.com, then
I assume this is the cover art loading plugin..
Anyway, now that my network problem is resolved, as I said, I can't
generate the crash. Also, it looks like most of my albums have cover
art now, so I wonder if this is why the original bug creator hasn't
shown back up :) Once you get past any issues with album art
collection, this code probably rarely runs anymore.
--
after a while (five minutes) listening music, it closes
https://bugs.launchpad.net/bugs/112950
You received this bug notification because you are a member of Ubuntu
Bugs, which is the bug contact for Ubuntu.
--
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
