Sometimes, when there is no instance of nautilus running, trying to launch an instance of it, you will have to wait exactly 1 minute for the window to appear. Similarly, when I click "Reply" in Evolution, the Evolution UI freezes for 30 seconds to 1-2 minutes until the message window shows up. There is no CPU usage going on when these things happen. I'm wondering if GTK or GDK or something else is the culprit. For what it's worth, this is on an Intel i915 GPU, and it doesn't seem to happen on my other computer that has a radeon r600. I know for one thing that the intel drivers seem to have a weird bug where glyphs get corrupted (Bug #708849) so I'm wondering if it is the driver causing all this crap (including bug #711251) on that particular machine.
I'm quite sure it's not the driver's fault but rather the kernel or the toolkit (GTK). This is a standard response we use for Xorg bugs, maybe there is something useful in the logs: Thanks for the bug report. We have reviewed the information you have provided above, and there is some additional information we require that will be helpful in our diagnosis of this issue. Please add drm.debug=0x04 to the kernel command line, restart computer, and attach * your X server config file (/etc/X11/xorg.conf, if available), * X server log file (/var/log/Xorg.*.log) * output of the dmesg command, and * system log (/var/log/messages) to the bug report as individual uncompressed file attachments using the bugzilla file attachment link above. We will review this issue again once you've had a chance to attach this information. Thanks in advance. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
Hi Elad, I just had this happen on my r600 too, so the driver hypothesis is probably out then. The only hint I have so far is that this problem seems to affect nautilus and evolution simultaneously (ie: when it happens, both applications seem to be unresponsive). It's as if it was waiting on dbus or something. How should I troubleshoot such a vague problem?
I have no idea, moving to gtk. -- Fedora Bugzappers volunteer triage team https://fedoraproject.org/wiki/BugZappers
It's more likely to be driver related, try to ssh remotely and see what's going on (top, strace, dmesg). All GPU are know to be prone to lockup and sometimes completely freeze a box, there is no way easy to debug this beside hopping that some dev face the same issue and spend time on it.
Hi Jerome, the things that make me a bit skeptical about this are: - it happens on both an Intel i915 and a Radeon HD 2600 (r600 running the opensource "radeon" drivers), though much more often on the Intel GPU - it does not freeze or lockup the whole desktop, just nautilus and evolution seem to hang as if waiting for something - there is no CPU usage (or disk I/O) going on when these things happen, and I haven't noticed a correlation with network availability Can it still be a GPU driver problem? It seems to happen semi-randomly, and only once in a while... but when it happens, you can guess how annoying it is :) So, when I can finally manage to hit the bug again, simply running "strace -p id_of_the_evolution_process" and pasting the output would work?
Does the freeze also after other application, ie are other application responsive ? strace on xorg server too
Created attachment 514576 [details] strace on nautilus after trying to launch it Here's a trace for nautilus. The gedit one will probably be better.
Created attachment 514577 [details] strace on gedit when calling the "Save as" dialog This strace is probably much better, as it was already attached to the process while I was triggering the hang, so it should be more complete.
Created attachment 514579 [details] partial xorg strace When trying to attach strace to xorg as root, the computer immediately locks up completely (cannot switch with ctrl+alt+F1/F2, caps lock key does not toggle the indicator LED).
I'm suspecting that this happens when you have gtk trying to acces gvfs remote folders that were previously mounted but that the user did not bother manually unmounting. For example, I often access sftp://kusanagi.local in Nautilus when I'm at home. There are many ways I can be left with a "ghost" remote folder mount in nautilus: - "Kusanagi" goes to sleep automatically after 60 minutes - My laptop (the one who tries to access kusanagi) leaves the premises and connects to a different network - My laptop goes to sleep and comes back? I'm not 100% sure, but that might be the cause...
Waiting for exactly one minute sounds more like a DNS timeout. And in particular, like you're timing out trying to resolve a hostname that's no longer valid because you switched networks. Which means I would like very much if you would try this test build and see if the problem still occurs: http://koji.fedoraproject.org/koji/taskinfo?taskID=3892684
Ah-ha! I've been able to trigger this empirically. Switching networks is not required, sleep/resume is not required. 1. connect to the desktop from the laptop with nautilus through sftp 2. leave Evolution etc open 3. block SSH on the desktop with a firewall 4. on the laptop, try to reply to a mail (or use something that calls the file chooser or nautilus) Result: the app hangs. As soon as you disable the firewall, the app unfreezes. Could you tell me how to get your rpm package from koji? I'd try it, but somehow the website UI is really labyrinthine/non-obvious and I can't find the actual rpm. Also, I can understand that it blocks the filechooser and nautilus, but not Evolution. Do you think I should also file a bug on Evolution? Thanks
Behavior still reproducible in Fedora 17, awaiting your precisions on how to actually get the rpm package from koji to test. Filed a bug in Evolution too: https://bugzilla.gnome.org/show_bug.cgi?id=673780
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Seems to be fixed when using Fedora 17 as the host trying to access a mounted share on the firewalled remote host.