What does "opening a file in the network" means ? Be very specific,
I don't see failure when opening files locally, so I can't reproduce
the problem. What is the file path you used ? How is it mounted ? 
What kind of filesystem ? 
The CIFS seems to have serious bugs in conjunction with dnotify,
this is all I can tell.

Daniel

Yes, sure.
I use NFS for accessing the files on my server (everything is ext3)
for instance, my home is on the server.

I tried to open a local file and it worked. I mean there was no core
file created.
but then I tried to access a file in an NFS share and there it was.

The core file is not always created, but the gam_server always
restarts (its pid changes).

some times the message is:
the connection with FAM is closed or lost or something like that.
some other times it's like this:

[mijail@ltspc55 ~]$ failed to read() from server connection

** ERROR **: file gam_tree.c: line 146 (gam_tree_remove): assertion
failed: (g_node_n_children(node->node) == 0)
aborting...
failed to read() from server connection

[mijail@ltspc55 ~]$ ll
-rw-------   1 mijail lts 2023424 Mar  7 16:44 core.12422
[mijail@ltspc55 ~]$

in fact, it also happens to me when I work in local...
exactly at the moment when i use the "open file" dialog.

I've tried with firefox also, the result is the same.


mi.

I have gam_server dumping cores as well. I can reliably reproduce it
when using the open file dialog in firefox as well:

#0  0x006f37a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
(gdb) bt
#0  0x006f37a2 in _dl_sysinfo_int80 () from /lib/ld-linux.so.2
#1  0x00815955 in raise () from /lib/tls/libc.so.6
#2  0x00817319 in abort () from /lib/tls/libc.so.6
#3  0x00ba4f7e in g_logv () from /usr/lib/libglib-2.0.so.0
#4  0x00ba4fb0 in g_log () from /usr/lib/libglib-2.0.so.0
#5  0x0804b237 in gam_tree_remove (tree=0x99a2510, node=0x99b0e20) at
gam_tree.c:146
#6  0x0804cba3 in gam_poll_remove_subscription (sub=0x99b0440) at
gam_poll.c:564
#7  0x08051404 in gam_dnotify_remove_subscription (sub=0x0) at
gam_dnotify.c:394
#8  0x0804eaaf in gam_connection_data (conn=0x99aba48, len=19284) at
gam_connection.c:342
#9  0x0804e2c3 in gam_client_conn_read (source=0x99ab9f0,
condition=19284, info=0x99aba48) at gam_channel.c:237
#10 0x00bc09c7 in g_vasprintf () from /usr/lib/libglib-2.0.so.0
#11 0x00b9c7bb in g_main_context_dispatch () from
/usr/lib/libglib-2.0.so.0
#12 0x00b9e242 in g_main_context_acquire () from /usr/lib/libglib-2.0.so.0
#13 0x00b9e4ef in g_main_loop_run () from /usr/lib/libglib-2.0.so.0
#14 0x0804ac86 in main (argc=1, argv=0xbfe9ae54) at gam_server.c:353
#15 0x00802e33 in __libc_start_main () from /lib/tls/libc.so.6
#16 0x08049ec1 in _start ()

gdb) print *node
$3 = {path = 0x9e4f540 "/usr/local", subs = 0x0, data = 0x0,
data_destroy = 0, flags = 0, node = 0x9e5b630, is_dir = 1}
(gdb) print node->node
$4 = (GNode *) 0x9e5b630
(gdb) print *(node->node)
$5 = {data = 0x9e5dcd0, next = 0x0, prev = 0x9e5b5e0, parent =
0x9e5b5cc, children = 0x9e5b644}


Version is gamin-0.0.25-1.FC3 on kernel-2.6.10-1.770_FC3.i686.rpm

I've been seeing this for the past week or so.  Maybe a little longer -- I may
have deleted a bunch of core files and forgotten that I did so.  The only
symptom that I've noticed is the accumulation of core files.

However, one data point:  I was thinking that the problem was triggered by the
recent gamin update.  However, my /var/log/yum.log shows:

# grep gamin /var/log/yum.log
Dec 31 13:47:11 Updated: gamin.i386 0.0.17-1.FC3
Dec 31 13:47:58 Updated: gamin-devel.i386 0.0.17-1.FC3
Feb 18 13:23:42 Updated: gamin.i386 0.0.24-1.FC3
Feb 18 13:23:42 Updated: gamin-devel.i386 0.0.24-1.FC3
Mar 02 14:09:47 Updated: gamin.i386 0.0.25-1.FC3
Mar 02 14:09:48 Updated: gamin-devel.i386 0.0.25-1.FC3

(those times are local (they could be GMT (per /etc/localtime rather than $TZ)
except that that would imply updating in the middle of the night when the
machine was turned off), timezone varies, but either GMT-0800 or GMT-0500) but
the timestamp on the oldest of the core files that I have accumulated (unless I
deleted some, which I may have) is Mar  1 23:50.

I also see

** ERROR **: file gam_tree.c: line 146 (gam_tree_remove): assertion
failed: (g_node_n_children(node->node) == 0) 
aborting...

a lot.

Seen over here with gamin-0.0.25-1.FC3.

Created attachment 111988 [details]
Fix for crash when unmonitored subdir contains monitored file/dir

This patch fixes the problem for me.  The problem occurs when you cancel
monitoring on a directory that contains an unmonitored subdirectory which in
turn contains a monitored directory or file.  The code which cancels the
monitoring of  a directory was attempting to remove the subdir because it
wasn't itself being monitored.

I'll also attach a test case shortly.

Created attachment 111989 [details]
Patch to the test harness that allows cancelling to be tested

You'll need this additional patch to run the test I'm about to attach.

Created attachment 111990 [details]
Test case

Created attachment 111991 [details]
Expected result

Cool ! 
The patch makes sense.
Apparently it fixes the problem for the MandrakeSoft guys :-)
I will try to push this tonight or tomorrow,

  thanks a lot !

Daniel

I had to revisit the patch a bit, fixing the problem at a different 
place too. Thanks a lot for the patch and the regression tests
they are applied upstream, a new release should come soon,

Daniel

Expected to be fixed in gamin-0.0.26-1 which was just pushed to rawhide,

  thanks !

Daniel 

gamin-0.0.26-1 appears to run fine here.  Can we get an update for FC3?