GNOME Bugzilla – Bug 336538
[gnomevfssrc?] rhythmbox crashed during NFS import
Last modified: 2008-05-06 12:16:33 UTC
Distribution: Fedora Core release 5 (Bordeaux) Package: rhythmbox Severity: critical Version: GNOME2.14.0 0.9.3 Gnome-Distributor: Red Hat, Inc Synopsis: rhythmbox crashed during NFS import Bugzilla-Product: rhythmbox Bugzilla-Component: Importing Bugzilla-Version: 0.9.3 BugBuddy-GnomeVersion: 2.0 (2.14.0) Description: Description of the crash: During an import of a library of ogg/vorbis files over NFS, rhythmbox crashed. The last thing rhythmbox displayed on the status line was "1144 songs". This is out of 13299 songs in my library. Steps to reproduce the crash: 1. Start rhythmbox, select Music -> Import Folder, select a folder (over NFS if that's relevant), and let rhythmbox do its job. 2. 3. Expected Results: Imported music. How often does this happen? Every time I try to import this library. Additional Information: All files have been created on FC4 using oggenc. I have been able to import this library on FC4 from the same NFS server (which has not yet been upgraded to FC5). Debugging Information: Backtrace was generated from '/usr/bin/rhythmbox' (no debugging symbols found) Using host libthread_db library "/lib/libthread_db.so.1". (no debugging symbols found) `shared object read from target memory' has disappeared; keeping its symbols. (no debugging symbols found) [Thread debugging using libthread_db enabled] [New Thread -1208321856 (LWP 23670)] [New Thread -1341297760 (LWP 6314)] [New Thread -1245803616 (LWP 23740)] [New Thread -1235313760 (LWP 23739)] (no debugging symbols found) 0x0089a402 in __kernel_vsyscall ()
+ Trace 67327
Thread 2 (Thread -1341297760 (LWP 6314))
------- Bug created by bug-buddy at 2006-03-29 20:47 -------
Can you run the import using the "-d" option to rhythmbox, i.e.: "rhythmbox -d" and attach the last part of that output to this bug. That should help identify which particular track might have caused the crash. In general things like this tend to be caused by a particular file. Also are you using 0.9.3 or 0.9.3.1?
Rhythmbox claims to be version 0.9.3.1. It's the version that came with Fedora Core 5. Of course when I try the import again (with a clean (i.e. removed) .gnome2/rhythmbox directory), this time with the -d option, things get imported properly. There was a pop-up window telling me about a bunch of .txt and .m3u (not even close to all of those) files it couldn't figure out the MIME type of, but that was it. There is another oddity. The command find . -name \*.ogg | wc -l finds 13299 files, whereas rhythmbox claims to have imported 13300.
Do any of the file names have ampersands in them? If so, could be an instance of bug #333998 which is fixed in CVS.
At least that canonicalisation in comment #3 issue might explain this oddity: > finds 13299 files, whereas rhythmbox claims to have imported 13300.
(In reply to comment #2) > Rhythmbox claims to be version 0.9.3.1. It's the version that came with Fedora > Core 5. > > Of course when I try the import again (with a clean (i.e. removed) > .gnome2/rhythmbox directory), this time with the -d option, things get imported > properly. There was a pop-up window telling me about a bunch of .txt and .m3u > (not even close to all of those) files it couldn't figure out the MIME type of, > but that was it. The fact that you are adding a large number of files and it works with the "-d" also makes me think that it might be related to bug #331876 which is about a hang when importing a large number of files. Although arguing against that case it hangs rather than crashes and if you are on FC-5 then you shouldn't have the problem with gnome-vfs which is mentioned on that bug.
(In reply to comment #3) > Do any of the file names have ampersands in them? If so, could be an instance > of bug #333998 which is fixed in CVS. > No. The set of ASCII characters is limited, although there are non-ASCII characters encoded as UTF-8 among the file names.
Can you reproduce without the "-d" option?
(In reply to comment #7) > Can you reproduce without the "-d" option? > Working on it. But I have to leave for work and I'm away the whole day tomorrow, so I may not be able to report today.
(In reply to comment #2) > There is another oddity. The command > find . -name \*.ogg | wc -l > finds 13299 files, whereas rhythmbox claims to have imported 13300. > Maybe this was caused by a file with a .ogg.vctemp extension which was less than half the size of the file without .vctemp. I removed it and started a fresh import.
Since the original crash was inside gnome-vfs (thread 2, the thread that crashed, was inside gnome_vfs_read), can you install the gnome-vfs debuginfo package (see http://fedoraproject.org/wiki/StackTraces)?
(In reply to comment #10) > Since the original crash was inside gnome-vfs (thread 2, the thread that > crashed, was inside gnome_vfs_read), can you install the gnome-vfs debuginfo > package (see http://fedoraproject.org/wiki/StackTraces)? > Here is the relevant part of the stack trace.
+ Trace 67374
Thread 2 (Thread -1374684256 (LWP 30098))
I tried importing the directory twice in quick succession. The first time it didn't crash, but the second time it did (with this stack trace). The difference between the two runs is that I restored the .ogg.vctemp file inbetween the runs. That file is probably a leftover from a failed attempt to run vorbiscomment to change a comment on the .ogg file. It is a lot smaller than the corresponding .ogg file.
Created attachment 62529 [details] Tail of the output of rhythmbox -d (In reply to comment #2) > Of course when I try the import again (with a clean (i.e. removed) > .gnome2/rhythmbox directory), this time with the -d option, things get imported > properly. There was a pop-up window telling me about a bunch of .txt and .m3u > (not even close to all of those) files it couldn't figure out the MIME type of, > but that was it. I tried running rhythmbox -d again, and this time I did get the crash. I'll attach the output (or what was still visible in my terminal window).
This appears to be a gnomevfssrc bug (or possibly a gnomevfs one, I guess), so reassigning there.
gnomevfssrc is in -base, reassigning.
I can confirm I've see similar behaviour elsewhere Using host libthread_db library "/lib/libthread_db.so.1". Core was generated by `python /home/bilboed/work/cvs/gst-media-test/gnltest.py --gst-fatal-warnings /m'. Program terminated with signal 5, Trace/breakpoint trap.
+ Trace 68344
what is the warning?
Ping? What is the warning it prints?
FWIW, I used to run into occasional IS_CANCELLABLE assertions (can't remember the exact look of it) ages ago, but haven't ever run into one since then, neither on ubuntu dapper nor on ubuntu edgy. So, does anyone still get this with an up-to-date GStreamer/GnomeVFS?
What warning are you referring to? Originally I reported a crash. I wouldn't call that a warning. FWIW, it seems the crash had to do with a corrupt ogg/vorbis file.
> What warning are you referring to? The one from Edward's stack trace. Both issues seem like they might be related. > Originally I reported a crash. I wouldn't call that a warning. > FWIW, it seems the crash had to do with a corrupt ogg/vorbis file. No, of course not :) Can you still reproduce the crash somehow? Have you ever seen it again since? (Not entirely sure why the content of a file would matter to gnome-vfs here though; maybe the file was being modified/truncated by another application?)
I *have* seen it since, and again there was a corrupt file involved. I don't have such a file currently (I didn't save the corrupt file), so I can't readily reproduce the problem. It could be that truncating a file does the trick. It's not up to me to decide whether or not the problem is in gnome-vfs, although in comment #11 you can see that a crash happened inside gnome_vfs_handle_do_read, which, I suppose, is a clue.
Ok, so it seems nobody can reproduce this anymore... let's just get this bug closed then until someone sees it again.