GNOME Bugzilla – Bug 86254
gnome_vfs_monitor_add hanging at random directories
Last modified: 2004-12-22 21:47:04 UTC
gnome_vfs_monitor_add seems to hang at seemingly random directories, every time i run the testcase (which i will attach here) it hangs at a different dir. Redhat 7.3 with its stock FAM. Using gnome-2-0-0 branch since i can't get HEAD to compile.
Created attachment 9406 [details] testcase
Do you have a stack trace of where its hanging? Do you know if its hanging in the fam library?
Created attachment 9436 [details] trace
Alex, from the stack trace it look like this is happening in the fam library. Are you still hacking on that these days?
How many directories does it monitor before it hangs? Someone else reported a problem with fam hanging when opening > 200 directories or so.
Yeah, it hangs between the 170th and 250th dir.
So I'm marking this 'high' out of principle... but if core apps aren't monitoring 200+ dirs I'm not entirely sure this should be 'high.'
So, my crack-laiden fix to disconnected NFS blocking stats (bug 74371) also wraps libFAM hangs, which can happen when FAM is used to monitor a disconnected NFS server or when it has exceeded the allowed number of system monitors. Btw, Alex, is there a way to remove this limit on the number of active FAM monitors?
There really should be no such limit, but i haven't yet had time to track that bug down.
AlexG: please don't NEEDINFO on questions to other devels. Also reopening since it seems the question was answered.
Okay, so just had a thought... if FAM is falling back to stat() after not finding the required kernel extensions, perhaps it is hitting the max number of simultaneous poll() fds, or something similar? AlexL, this is total conjecture as I've never looked at the FAM code, but what do you think?
It could be related to # of fds. But 200 sounds a bit low for that.
Putting this on the 2.2 milestone.
Any further thinking Alex (L :-). This is preventing us from using file monitoring in RhythmBox, which was a very nice feature (you could add music to your library just by dropping it inside the ~/Music folder).
I think this is a deadlock. the process keeps feeding fam requests, and not reading replys, while fam seemingly stops reading request once it's output buffer for the client is full. This leads to the process being ignored by fam, and the process blocking on a full pipe.
Ok. I think the best solution here is to make the gnome-vfs monitor requests read all pending fam events and queue them up for later processing before sending a new monitor request. Just make sure no events are reordered or missed.
Fixed in 2.2.1.