GNOME Bugzilla – Bug 352494
RB crashed while starting up
Last modified: 2006-11-25 05:32:57 UTC
Steps to reproduce: As I recall, this crash happened when starting up with my music shared over NFS. It was during a stretch of time when I wasn't connected to the internet, so that may have been a factor as well. Stack trace: See attached. Other information:
Created attachment 71435 [details] Backtrace
So, it created a few hundred threads for some reason, then ran out of address space and died. It looks like this happened because we were getting a lot of directory create events. When we get one of these, we create a thread to add the files in the directory. Maybe we need to use a thread pool to limit that.
Created attachment 71496 [details] [review] use thread pool for adding directories
Will this make any difference to bug #331876?
No, they're completely separate issues
committed to cvs.
Thanks very much!
*** Bug 356210 has been marked as a duplicate of this bug. ***
(In reply to comment #8) > *** Bug 356210 has been marked as a duplicate of this bug. *** I'm still experiencing this behavior on 0.9.5-1ubuntu5; does this version have this fix in it?
No, ubuntu's rhythmbox packages does not include this fix.
I built CVS from source today and am still experiencing this freeze. Here is what info I could glean; I couldn't get strace to attach to the running process. (Any ideas on that would be most welcome.) Also, running this within gdb causes gdb to close immediately. I'll attach the core dump, but I'm not sure it will be useful. # ls -l /proc/9169/fd total 23 lrwx------ 1 andrew andrew 64 2006-09-20 00:16 0 -> /dev/pts/0 lrwx------ 1 andrew andrew 64 2006-09-20 00:16 1 -> /dev/pts/0 lrwx------ 1 andrew andrew 64 2006-09-20 00:16 10 -> socket:[1782387] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 11 -> socket:[1782390] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 12 -> socket:[1782392] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 13 -> socket:[1782395] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 14 -> socket:[1782396] lr-x------ 1 andrew andrew 64 2006-09-20 00:16 15 -> pipe:[1782398] l-wx------ 1 andrew andrew 64 2006-09-20 00:16 16 -> pipe:[1782398] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 17 -> socket:[1782400] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 18 -> socket:[1782402] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 19 -> socket:[1782404] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 2 -> /dev/pts/0 lrwx------ 1 andrew andrew 64 2006-09-20 00:16 20 -> socket:[1782417] lrwx------ 1 andrew andrew 64 2006-09-20 00:16 21 -> socket:[1782634] lr-x------ 1 andrew andrew 64 2006-09-20 00:16 22 -> inotify lrwx------ 1 andrew andrew 64 2006-09-20 00:16 3 -> socket:[1782382] lr-x------ 1 andrew andrew 64 2006-09-20 00:16 4 -> pipe:[1782384] l-wx------ 1 andrew andrew 64 2006-09-20 00:16 5 -> pipe:[1782384] lr-x------ 1 andrew andrew 64 2006-09-20 00:16 6 -> pipe:[1782385] l-wx------ 1 andrew andrew 64 2006-09-20 00:16 7 -> pipe:[1782385] lr-x------ 1 andrew andrew 64 2006-09-20 00:16 8 -> pipe:[1782386] l-wx------ 1 andrew andrew 64 2006-09-20 00:16 9 -> pipe:[1782386]
The file's a bit large (45 MB) so I put it on a filehosting site: http://s11.quicksharing.com/v/3104993/core.25983.html Just check it out within a month. ;)
A core file is only useful if one also has the binary from which it was generated. You should be able to get a stack trace yourself by running 'gdb /path/to/rhythmbox core.25983'. If it's freezing now, rather than crashing, it sounds like it may be a different issue. What happens when you try to attach strace to the frozen rhythmbox process?
This is what happens in gdb: [Thread debugging using libthread_db enabled] [New Thread -1228417360 (LWP 13981)] [New Thread -1241883744 (LWP 13988)] [Thread -1241883744 (LWP 13988) exited] [New Thread -1241883744 (LWP 13992)] [Thread -1241883744 (LWP 13992) exited] [New Thread -1241883744 (LWP 13995)] [New Thread -1269826656 (LWP 13996)] [New Thread -1278219360 (LWP 13999)] [New Thread -1286612064 (LWP 14000)] [New Thread -1295004768 (LWP 14001)] [New Thread -1303397472 (LWP 14002)] [Thread -1278219360 (LWP 13999) exited] [Thread -1241883744 (LWP 13995) exited] [Thread -1269826656 (LWP 13996) exited] [Thread -1286612064 (LWP 14000) exited] Segmentation fault (core dumped) ...but it returns me to my bash prompt, not a gdb one, so I can't get a backtrace. Turns out it's a core file from another crashing program; I feel silly.... With strace, I was getting "Operation not permitted" or something like that.... This time, it worked; I'll attach the output.
Created attachment 73086 [details] strace output when running CVS RB
If that is the complete gdb output, then this is definitely a different problem.
Created attachment 73125 [details] Better backtrace of crash on CVS HEAD Here's a better backtrace, made possible through an older version of gdb. I'm not sure if I'm seeing a different issue or not, but here it is. Let me know if there's anything else I can do to help.
This is definitely a different problem. The original crash occurred when rhythmbox started >100 threads, which it's not doing here. It's hard to tell why exactly gdb is stopping there. It's probably not due to rhythmbox crashing. There are a number of threads missing from the 'thread apply all bt' output. Could you try the gdb commands 'handle SIG33 nostop pass' and 'handle SIGPIPE nostop pass' before running rhythmbox? This may get past where it's stopping now.
Actually... starting RB with a different DB seems to have made a big difference. I haven't deleted my old one, so let me know if there's anything else I can do to track down any problems. I'm assuming, based on your last comment, that this particular bug is fixed then, after the patch was applied to CVS?
OK, running 0.9.6 as released by Ubuntu Edgy, and RB doesn't crash, it just freezes. How can I track down why that is happening?
Run rhythmbox in gdb, hit ctrl-c once it's frozen, then 'thread apply all bt'. Output from 'rhythmbox -d' might also be useful, but a stack trace is usually more helpful.
Created attachment 74250 [details] Backtrace when frozen Here's the requested backtrace when Rhythmbox is frozen.
This is probably the same issue as bug 331876. Can you try stracing rhythmbox and famd once rhythmbox is frozen, just to make sure? (strace -p `pidof rhythmbox` and strace -p `pidof famd`). If it is the same issue, rhythmbox will be stuck in a write() (or was it read()? I forget) and famd will be too.
I don't know my strace, but it looks like that's what's happening: strace -p `pidof rhythmbox` Process 1680 attached - interrupt to quit write(22, "_\0\1\0\360\1\2\0U\0/home/music/Strauss/Ho"..., 95 andrew:~ strace -p `pidof gam_server` Process 5621 attached - interrupt to quit write(3, "B\0\1\0r\0\10\0008\0Bernard Herrmann - 11."..., 66 So since this looks like that other bug, should this one be closed? And should I post any information (versions, etc.) on bug 331876?
Thanks. This confirms that the issue you're seeing is the same as bug 331876, so I'm marking this bug as a duplicate. There isn't any more information you can provide that would help. We know what the problem is, and there isn't really a good solution. Disabling file monitoring (you may need to use gconf-editor to do this if rhythmbox won't start) or upgrading to a version of gnome-vfs that uses inotify directly should help. *** This bug has been marked as a duplicate of 331876 ***
(In reply to comment #25) > Disabling file monitoring (you may need to use gconf-editor to do this if > rhythmbox won't start) or upgrading to a version of gnome-vfs that uses inotify > directly should help. OK. I'm using Ubuntu Edgy on GNOME/gnome-vfs 2.16.1; does this not use inotify directly? Thanks for your help and patience with all this!
I forgot your music was on an NFS share. In that case, inotify won't work, so gnome-vfs will use fam/gamin for file monitoring.
*** Bug 379027 has been marked as a duplicate of this bug. ***