glib trying to put inotify watch on old directory
Submitted by Patrick H
Link to original bug (#661619)
Description
Created attachment 198900 gdb stack trace of firefox being hung
I'm bringing this bug from firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=692545).
What appears to be happening is that when using a GTK file selection dialog, an inotify watch is being added to the directory, and then after the dialog is closed, glib still tries to keep the inotify watch on the directory as a result of im_scan_missing(). This can result in the application hanging if the inotify watch is being put on an autofs mount which is no longer available (the watch hangs until automount returns).
This behavior has been observed in firefox and evince.
I am including 3 attachments. The first is a stack trace of firefox being hung after the autofs mount becomes unavailable. The file selection dialog had been closed, and there are no open file handles on the mount point. I simulated the mount going unavailable by unmounting and then putting in an iptables DROP rule for traffic to the network share.
The second attachment is firefox opening the file selection dialog with a break point on ip_watched_dir_new.
The third attachment is also a break point on ip_watched_dir_new, but this break triggered a few seconds after the mount was unmounted and made unavailable.
Attachment 198900, "gdb stack trace of firefox being hung":
firefox_hang.txt
Version: 2.28.x