Bug 75055

*** This bug has been marked as a duplicate of 74696 ***

Yup same here,
upgrade from rh7.3 to rh8.0. My scenario is as follows (maybe it helps to have a
second scenario). /me start gnome in runlevel 5

1) error notification in /var/log/messages

Oct  6 10:51:11 sahara xinetd[10889]: libwrap refused connection to sgi_fam from
<no address>
Oct  6 10:51:11 sahara xinetd[10890]: warning: can't get client address:
Transport endpoint is not connected

2) Stopped the sgi_fam service in /etc/xinetd.d
3) get this when running gedit

FAMOpen failed, FAMErrno=0

Cheers bernard

I had the same problem.  In Failsafe, I ran gnome-panel stand-alone
and saw the same problem.  It appears to be a race condition with fam.
Running "./gnome-panel" would usually hang.  Running "gdb ./gnome-panel"
would always succeed (slows down gnome-panel significantly)

Rebuilt the gnome-panel with "-g3 -O2", ran until the hang, then
attached with gdb and got the following stack:

Scattered in g_print()'s , and it hangs in menu-fentry.c in
     if (gnome_vfs_get_file_info
	  (muri, info, GNOME_VFS_FILE_INFO_DEFAULT)
	       != GNOME_VFS_OK) {

#0  0x420cdb84 in write () from /lib/i686/libc.so.6
#1  0x4083eb44 in __JCR_LIST__ () from /lib/i686/libpthread.so.0
#2  0x40d49b54 in completed.1 () from /usr/lib/libfam.so.0
#3  0x40d4c891 in FAMClose () from /usr/lib/libfam.so.0
#4  0x40d4c945 in FAMMonitorDirectory () from /usr/lib/libfam.so.0
#5  0x40d09716 in do_monitor_add () from /usr/lib/gnome-vfs-2.0/modules/libfile.so
#6  0x406b1321 in gnome_vfs_monitor_do_add () from /usr/lib/libgnomevfs-2.so.0
#7  0x406b2579 in gnome_vfs_monitor_add () from /usr/lib/libgnomevfs-2.so.0
#8  0x40cf9fe8 in monitor_setup () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#9  0x40cfd1d7 in get_vfolder_info_unlocked () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#10 0x40cfd3ca in get_vfolder_info () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#11 0x40cfffa3 in do_get_file_info () from
/usr/lib/gnome-vfs-2.0/modules/libvfolder-desktop.so
#12 0x4069e28c in gnome_vfs_get_file_info_uri_cancellable () from
/usr/lib/libgnomevfs-2.so.0
#13 0x406b1cb5 in gnome_vfs_get_file_info_uri () from /usr/lib/libgnomevfs-2.so.0
#14 0x406b1c66 in gnome_vfs_get_file_info () from /usr/lib/libgnomevfs-2.so.0
#15 0x0809b250 in fr_read_dir (dr=0x406c3078, muri=0x80aa69c "applications:/",
mtime=0, sublevels=2) at menu-fentry.c:416
#16 0x0808fe34 in init_menus () at menu.c:169
#17 0x0806b430 in session_load () at session.c:335
#18 0x0805ace9 in main (argc=-512, argv=0xbffffaa4) at main.c:199
#19 0x420158d4 in __libc_start_main () from /lib/i686/libc.so.6


Stopped where it hung in fr_read_dir()
(gdb) p muri
$1 = 0x80aa69c "applications:/"
(gdb) p *info
$3 = {name = 0x1 <Address 0x1 out of bounds>, valid_fields = 135118184, type =
GNOME_VFS_FILE_TYPE_UNKNOWN, 
  permissions = 135108008, flags = 1087387776, device = 580274477103841280,
inode = 135108240, link_count = 0, uid = 0, 
  gid = 0, size = 171798691872, block_count = 73149552272, io_block_size =
1107326060, atime = 1108521492, 
  mtime = 1869506351, ctime = 17, symlink_name = 0x4212003c "", mime_type =
0x4212b1dc "", refcount = 1819632751, 
  reserved1 = 0x11, reserved2 = 0x4200746c, reserved3 = 0x4212b1f4, reserved4 =
0x65642d72, reserved5 = 0x11}
(gdb) p/x *info
$4 = {name = 0x1, valid_fields = 0x80dbd68, type = 0x0, permissions = 0x80d95a8,
flags = 0x40d03880, 
  device = 0x80d8c9000000000, inode = 0x80d9690, link_count = 0x0, uid = 0x0,
gid = 0x0, size = 0x2800000020, 
  block_count = 0x11080d9690, io_block_size = 0x4200746c, atime = 0x4212b214,
mtime = 0x6f6e672f, ctime = 0x11, 
  symlink_name = 0x4212003c, mime_type = 0x4212b1dc, refcount = 0x6c75646f,
reserved1 = 0x11, reserved2 = 0x4200746c, 
  reserved3 = 0x4212b1f4, reserved4 = 0x65642d72, reserved5 = 0x11}
(gdb) p *dr
$6 = {frec = {type = 220956, name = 0x40654268 "", comment = 0x4000a180
"PQR\213T$\020\213D$\f&#65533;\200&#65533;&#65533;&#65533;ZY\207\004$&#65533;\b", 
    fullname = 0x40695f72 "h", name_collate_key = 0x40897520 "U\211&#65533;\203&#65533;\030
\211]&#65533;\213U\b\215E\f&#65533;\020Y&#65533;&#65533;\201&#65533;p2\003", 
    icon = 0x40695f92 "h\020", exec = 0x40695fa2 "h\030", tryexec_path =
0x40695fb2 "h ", parent = 0x40695fc2, 
    mtime = 1080647634, last_stat = 1080647650}, ditemmtime = 1080647666,
ditemlast_stat = 1080647682, tryexecs = 0x40696012, 
  recs = 0x40696022, mfl = 0x406a6db0}
(gdb) p/x *dr
$7 = {frec = {type = 0x35f1c, name = 0x40654268, comment = 0x4000a180, fullname
= 0x40695f72, name_collate_key = 0x40897520, 
    icon = 0x40695f92, exec = 0x40695fa2, tryexec_path = 0x40695fb2, parent =
0x40695fc2, mtime = 0x40695fd2, 
    last_stat = 0x40695fe2}, ditemmtime = 0x40695ff2, ditemlast_stat =
0x40696002, tryexecs = 0x40696012, recs = 0x40696022, 
  mfl = 0x406a6db0}
(gdb) 


Nautilus didn't seem to have this problem using fam, only gnome-panel.

Looks like the problem is really down in gnome-vfs and it's interaction
with fam.  Probably related to the gnome-vfs deadlock noted in bug 86254

http://bugzilla.gnome.org/show_bug.cgi?id=86254

Hope this helps,
-Bob Arendt

rda: I would say you aren't having the same problem. If you get the libwrap
warnings you won't ever connect to fam, and therefore you won't be able to add
any fam monitor and therefore not deadlock.

I also wonder why you got the deadlock. You have to monitor about 200 dirs
without ever idling inbetween in order to get it.

Agreed, not the same problem .. but title fits fits the symptom
exactly - with sgi_fam present gnome fails to run.
Doing a 'ls -1 |wc -l' in HOME yields 354 dirs+files.  Does nautilus
try to monitor all files?  Also, it seems nautilus comes up but
login freezes on gnome-panel (in fact without nautilus (running FailSafe
session), gnome-panel can freeze in this manner).  And it's only during
gnome-panel startup.  If I run gnome-panel using gdb, it always succeeds.
Please feel free to shift this to a more appropriate bug, but there's
certainly a flaw in the interaction.
Please let me know if there's any rebuild/debug I should try.
Right now my workaround is to add "disable=yes" to /etc/xinetd.d/sgi_fam.
-Bob Arendt

I filed the deadlock issue as bug 75425