maemo.org Bugzilla – Bug 3590
gnomevfs code enables infinite loop
Last modified: 2009-06-30 17:56:09 UTC
You need to log in before you can comment on or make changes to this bug.
sample code: get_deadlocked (GnomeVFSURI *uri) { GnomeVFSDirectoryHandle *handle; GnomeVFSResult result; GnomeVFSFileInfo *file_info; result = gnome_vfs_directory_open_from_uri ( &handle, uri, GNOME_VFS_FILE_INFO_FORCE_FAST_MIME_TYPE ); if (result != GNOME_VFS_OK) { return NULL; } file_info = gnome_vfs_file_info_new (); while (1) { result = gnome_vfs_directory_read_next ( handle, file_info ); if (result == GNOME_VFS_ERROR_EOF) { break; } else if (result != GNOME_VFS_OK) { /* Couldn't read. */ continue; ... the problem case is that gnomevfs could fail because there are too many open files. if it fails, it doesn't increment a counter such that it could reach EOF, but instead should fail exactly the same way the next time.
read one ,close one
Can you give more information about that!Is it your test code ? If it's your test code. you could implement this function to use another way. For example, you could read a file .and then close it.
Jianjun Yu, Fangjun.Peng: Please avoid repeating what is already clear, or non-understandable comments like "read one, close one". This helps nobody and just adds clutter and noise here. If you are confused then please don't comment. Thanks.
According to Richard this is "not a bug in gnomevfs but in the app code."
ask Richard to explain precisely which line in the cited code is buggy (by citing API documentation indicating what should be done in response to a given return value). That code (plus a sufficiently large number of open file handles) is sufficient to create such a loop. If necessary I'm sure we could write such a program.
Please provide a full self contained test case then that shows the issue then, not just a snippet, including what kind of input is used to reproduce (like the URIs and how the filesystem looks, i.e. symlinks, "weird" filenames/paths with characters that could trigger any escaping bugs, etc).
so, i actually did some testing with this (well, remotely), all sorts of things blew up amusingly. and i was supposed to get someone to file bugs against something. to be honest- I don't care enough. after all gnomevfs is EOLd. mostly while we use the gnomevfs code, we need to make sure that the consumers don't implement get_deadlocked (which was based on the backup code).
(In reply to comment #7) > after all gnomevfs is EOLd. that's true for upstream, unfortunately it's not true for Fremantle as far as I know, even though it will ALSO include gvfs.
(In reply to comment #6) > Please provide a full self contained test case then that shows the issue then -> moreinfo
Closing this bug report as no further information has been provided. Please feel free to reopen this bug if you can provide the information asked for. Thanks!