After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 533917 - nautilus blocks on named pipe
nautilus blocks on named pipe
Status: RESOLVED FIXED
Product: evince
Classification: Core
Component: general
2.26.x
Other All
: Normal minor
: ---
Assigned To: Evince Maintainers
Evince Maintainers
Depends on:
Blocks:
 
 
Reported: 2008-05-19 20:33 UTC by David R. Hoskin
Modified: 2010-07-01 11:15 UTC
See Also:
GNOME target: ---
GNOME version: 2.21/2.22



Description David R. Hoskin 2008-05-19 20:33:05 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.
Comment 1 Cosimo Cecchi 2008-05-19 23:33:28 UTC
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.
Comment 2 Florian Kisser 2008-06-12 14:37:03 UTC
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.
Comment 3 Bernhard Koenig 2009-04-02 01:03:13 UTC
This is a duplicate of http://bugzilla.gnome.org/show_bug.cgi?id=549298 and they claim it's fixed over there.
Comment 4 Bernhard Koenig 2009-04-02 01:07:18 UTC
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.
Comment 5 Cosimo Cecchi 2009-04-02 08:39:13 UTC
Yes, it's a duplicate.

*** This bug has been marked as a duplicate of 549298 ***
Comment 6 Alexander Larsson 2009-04-02 11:18:07 UTC
Not a dup, i can reproduce here. Its the evince plugin hanging on reading from the pipe:
  • #0 open64
    from /lib64/libpthread.so.0
  • #1 g_local_file_read
    at glocalfile.c line 1284
  • #2 get_mime_type_from_data
    at ev-file-helpers.c line 270
  • #3 get_document_from_uri
    at ev-document-factory.c line 118
  • #4 ev_document_factory_get_document
    at ev-document-factory.c line 220
  • #5 ev_properties_get_pages
    at ev-properties-main.c line 104
  • #6 append_extension_pages
    at fm-properties-window.c line 4884
  • #7 create_properties_window
    at fm-properties-window.c line 5209
  • #8 is_directory_ready_callback
    at fm-properties-window.c line 5348

Comment 7 Alexander Larsson 2009-04-02 11:22:49 UTC
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.
Comment 8 Nickolay V. Shmyrev 2009-04-04 23:17:46 UTC
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 :)
Comment 9 Alexander Larsson 2009-04-06 08:08:27 UTC
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.
Comment 10 Carlos Garcia Campos 2009-04-10 10:46:21 UTC
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. 
Comment 11 Alexander Larsson 2009-04-16 09:24:07 UTC
Whats wrong with using the mimetype that nautilus has already detected?
I.e. nautilus_file_info_get_mime_type().
Comment 12 Carlos Garcia Campos 2009-04-16 12:31:02 UTC
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
Comment 13 Christian Persch 2009-04-16 14:13:17 UTC
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?
Comment 14 Carlos Garcia Campos 2009-04-16 15:38:20 UTC
but in evince we never use the document factory from the main thread. 
Comment 15 Christian Persch 2009-04-16 16:36:44 UTC
But it will hang the thread, so it's a ressource leak, no?
Comment 16 Carlos Garcia Campos 2009-04-16 16:59:59 UTC
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) 
Comment 17 Emmanuel Fleury 2009-11-06 10:50:50 UTC
*** Bug 580590 has been marked as a duplicate of this bug. ***
Comment 18 Massimo Cora' 2010-07-01 08:03:30 UTC
this happens with firefox, chrome and eog. I think this is a gtk bug.
Comment 19 Christian Persch 2010-07-01 11:15:11 UTC
No, it's a separate bug in each of these.