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 569229 - gvfs-fuse-daemon halted with futex_wait signal, and kills other programs
gvfs-fuse-daemon halted with futex_wait signal, and kills other programs
Status: RESOLVED NOTGNOME
Product: gvfs
Classification: Core
Component: fuse
unspecified
Other All
: Normal critical
: ---
Assigned To: gvfs-maint
gvfs-maint
Depends on:
Blocks:
 
 
Reported: 2009-01-26 18:26 UTC by Mike
Modified: 2009-03-05 19:29 UTC
See Also:
GNOME target: ---
GNOME version: 2.23/2.24


Attachments
Screenshot of gnome-system-monitor at the time of a freeze (83.13 KB, image/png)
2009-01-26 18:27 UTC, Mike
Details

Description Mike 2009-01-26 18:26:56 UTC
Steps to reproduce:
1. Start computer
2. Wait
3. Sooner or later, something will freeze


Stack trace:
Unfortunately, I haven't yet been able to get a stack trace for this error. As I described at https://bugs.launchpad.net/ubuntu/+source/gvfs/+bug/320581 (and they asked me to post here):

Since installing intrepid, I have had trouble with programs freezing. From what I have determined, it is caused by thread locking, and gvfs-fuse-daemon.

The way to make it happen seems to be to use my computer for a while, and then sooner or later, a program freezes. When it does, if I open system monitor, it will show the waiting signal for the frozen program to be futex_wait, and will show the waiting signal for gvfs-fuse-daemon to be futex_wait.

I've tried to find information about futexes, but the web is pretty quiet on the matter.

The only solution I have found to this bug is to kill the application that is frozen. This has happened to:
 - gnome-panel
 - gnome-do
 - firefox
 - eclipse
 - python
 - getty (I think)
 - and a few others

Every now and then my entire computer freezes, and I think this is the culprit because if this happened to a process like gdm or X, it would cause me to be unable to figure out the waiting channel, and would force a reset of the whole computer.

Also, I'm not sure if this helps, but I installed Ubuntu with the encrypted drive option via the alternate installer.

I've attached a screenshot of gnome-system-monitor at the time of the current futex_wait lock-up, and will try to get a stack trace as soon as possible. I'm not sure bug-buddy is going to catch the crash though because the program doesn't crash, it just freezes (and then _I_ crash it). So far, bug buddy has never detected one of these crashes.

Other information:
Comment 1 Mike 2009-01-26 18:27:47 UTC
Created attachment 127275 [details]
Screenshot of gnome-system-monitor at the time of a freeze
Comment 2 Alexander Larsson 2009-03-02 08:55:55 UTC
I'm not sure exactly why you think this is related to gvfs-fuse-daemon? (Not saying its not, it just doesn't seem obvious).

In the screenshot both gvfs-fuse-daemon and gnome-panel are blocking in futex_wait, which means they are waiting for some lock. However, futexes are not generally used cross-process, so they are unlikely to be waiting on the same lock.

Comment 3 Mike 2009-03-02 18:01:53 UTC
That's interesting. I assumed it was gvfs-fuse-daemon because that was the program that was most often involved in the problem. Whenever there was a freeze of any program, gvfs-fuse-daemon would also be frozen. Both with a futex-wait. 

I don't know the first thing about futexes, but I was guessing they were some kind of kernel lock for multi-threading between processes (or something similar). This hasn't been a problem for a while, so I guess we could close this bug. I don't know why it stopped.
Comment 4 Alexander Larsson 2009-03-04 19:03:01 UTC
A futex is the lowlevel kernel primitive used for implementing locks. It is possible to make locks cross-process, but most ones are normal in-process locks.
Comment 5 Alexander Larsson 2009-03-05 13:11:00 UTC
Anyway, it was probably something else weird happening. I'm closing this since it seems to have disappeared and since its likely not a gvfs issue.
Comment 6 Tom 2009-03-05 17:21:08 UTC
I see the same problem.  From what I have noticed the problem occurs when multiple application are trying to all play audio.  It can be one after another, it doesn't have to be at the same time.  For example if I watch something on youtube, then play a song using Amarok, then try to watch another thing on youtube firefox will freeze up and be in a futex_wait.  And if I try to play a song on Amarok while firefox is in a futex_wait Amarok will freeze up and be in a futex_wait.  Any application I try to listen to audio on this will happen to once one has gone into a futex_wait.  The way I have been fixing this is to kill (not End process because is doesn't work) all the processes in the futex_wait.  Then I can restart whatever application I want to use for audio and listen to it.  Also gvfs-fuse-daemon is sometimes, but not everytime, in the futex_wait when all of this is going on.
Comment 7 Mike 2009-03-05 18:34:38 UTC
Well, this bug is closed now since I can't get this problem to occur anymore, but I'm still interested in finding out what's causing it. This makes it sound like a pulseaudio problem. What are you using in Amarok for your audio engine? I have mine set to Xine and Alsa, if that makes any difference.
Comment 8 Tom 2009-03-05 19:25:15 UTC
In Amarok my sound system is set to xine Engine, and my Output plugin is set to Autodetect.
Comment 9 Mike 2009-03-05 19:29:13 UTC
Try switching to alsa, and see if the error stops.