GNOME Bugzilla – Bug 533917
nautilus blocks on named pipe
Last modified: 2010-07-01 11:15:11 UTC
Please describe the problem: The entire application blocks when a named pipe is opened in the 'file properties' dialog Steps to reproduce: 1. Select a named pipe in the file browser 2. open the properties dialog 3. Actual results: The entire application, including all windows and the fake root window, blocks while waiting for input from the pipe Expected results: Nautilus would first read the attributes from the file system, determining that the file was a named pipe before trying to read from it. Does this happen every time? yes Other information: problem may be resolved by catting something to pipe.
Confirming, it happens here. I think this might be a GIO bug rather than a Nautilus one, as I seem to reproduce it also with Epiphany and gvfs-less.
Additionally, copying (maybe moving too?) just stops, if there's a named pipe. Nautilus doesn't hang, it's just the progress bar that stops moving, the harddisk going to sleep, ... Propably a gvfs bug with handling fifos in general, because with gnome-vfs I didn't experience these problems.
This is a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=549298 and they claim it's fixed over there.
Actually, it might not be a literal duplicate, so I won't mark this as such. But the problem is related to that other bug.
Yes, it's a duplicate. *** This bug has been marked as a duplicate of 549298 ***
Not a dup, i can reproduce here. Its the evince plugin hanging on reading from the pipe:
+ Trace 214122
So, there is a multitude of issues here: * You're doing sync i/o on the main thread in nautilus, which is strictly forbidden. * You're loading the file even though it might not be a regular file (a pipe in this case) * You're doing mime sniffing yourself instead of looking at the mime type nautilus already sniffed for you in the NautilusFileInfo object.
Well, rework will require significant effort since get_document code is shared across nautilus plugin and Evince itself. I'd better expect to get correct mime type from a named pipe :)
What do you mean by "get correct mime type from a named pipe"? Getting a mimetype from a named pipe using the gio calls works nicely. And nautilus will get the correct mimetype too. However, the evince plugin doesn't use those calls, instead it unconditionally ignores the already sniffed mimetime for all files passed to it by nautilus and instead uses ev-file-helpers.c::get_mime_type_from_data() which tries to manually (and sync!) load 1K of the file, which of course will block forever on a named pipe with no writer.
Fixed in both trunk(3595) anf gnome-2-26(3596) branches. It still loads the document in the main thread, which is fast for most of the documents, but I think we cannot avoid it since the nautilus get_pages method is sync.
Whats wrong with using the mimetype that nautilus has already detected? I.e. nautilus_file_info_get_mime_type().
That's exactly what we are doing: 2009-04-10 Carlos Garcia Campos <carlosgc {at} gnome.org> * properties/ev-properties-main.c: (ev_properties_get_pages): Create and load the document based on the mime-type provided by nautilus instead of using our own documents factory. Fixes bug #533917. http://svn.gnome.org/viewvc/evince/branches/gnome-2-26/properties/ev-properties-main.c?r1=3596&r2=3595&pathrev=3596
In evince itself though we still use the blocking call to sniff the mime type, and so will deadlock on the pipe, won't we?
but in evince we never use the document factory from the main thread.
But it will hang the thread, so it's a ressource leak, no?
ah!, yes of course, if the factory method hangs while reading the pipe, the thread will hang, which would make impossible to run any other job, since we use only one thread (and the main thread, of course)
*** Bug 580590 has been marked as a duplicate of this bug. ***
this happens with firefox, chrome and eog. I think this is a gtk bug.
No, it's a separate bug in each of these.