Bug 150471 - gam_server crashes constantly
Summary: gam_server crashes constantly
Alias: None
Product: Fedora
Classification: Fedora
Component: gamin
Version: 3
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Daniel Veillard
QA Contact:
URL: http://mijail.homelinux.com/gamin
Depends On:
TreeView+ depends on / blocked
Reported: 2005-03-07 14:11 UTC by miji piji
Modified: 2007-11-30 22:11 UTC (History)
5 users (show)

Clone Of:
Last Closed: 2005-03-15 13:00:28 UTC

Attachments (Terms of Use)
Fix for crash when unmonitored subdir contains monitored file/dir (703 bytes, patch)
2005-03-14 16:13 UTC, Dean Brettle
no flags Details | Diff
Patch to the test harness that allows cancelling to be tested (1.21 KB, patch)
2005-03-14 16:16 UTC, Dean Brettle
no flags Details | Diff
Test case (337 bytes, text/plain)
2005-03-14 16:18 UTC, Dean Brettle
no flags Details
Expected result (529 bytes, text/plain)
2005-03-14 16:18 UTC, Dean Brettle
no flags Details

Description miji piji 2005-03-07 14:11:02 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.6)
Gecko/20050302 Firefox/1.0.1 Fedora/1.0.1-1.3.2

Description of problem:
gam_server crashes constantly

some core files are on the url indicated previously.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. open gimp. 
2. try to open a file (in the network)
3. a core file is produced

Actual Results:  a core file is produced

Expected Results:  no core files

Additional info:

it also happens with other applications

Comment 1 Daniel Veillard 2005-03-07 15:19:36 UTC
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.


Comment 2 miji piji 2005-03-07 16:10:00 UTC
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)
failed to read() from server connection

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

Comment 3 miji piji 2005-03-07 16:32:24 UTC
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.


Comment 4 Peter van Hooft 2005-03-08 12:32:09 UTC
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
#6  0x0804cba3 in gam_poll_remove_subscription (sub=0x99b0440) at
#7  0x08051404 in gam_dnotify_remove_subscription (sub=0x0) at
#8  0x0804eaaf in gam_connection_data (conn=0x99aba48, len=19284) at
#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
#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

Comment 5 David Baron 2005-03-09 05:28:09 UTC
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.

Comment 6 Aleksey Nogin 2005-03-10 03:10:42 UTC
I also see

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

a lot.

Comment 7 Pawel Salek 2005-03-10 10:35:51 UTC
Seen over here with gamin-0.0.25-1.FC3.

Comment 8 Dean Brettle 2005-03-14 16:13:51 UTC
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.

Comment 9 Dean Brettle 2005-03-14 16:16:45 UTC
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.

Comment 10 Dean Brettle 2005-03-14 16:18:10 UTC
Created attachment 111990 [details]
Test case

Comment 11 Dean Brettle 2005-03-14 16:18:49 UTC
Created attachment 111991 [details]
Expected result

Comment 12 Daniel Veillard 2005-03-14 16:52:47 UTC
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 !


Comment 13 Daniel Veillard 2005-03-15 11:52:35 UTC
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,


Comment 14 Daniel Veillard 2005-03-15 13:00:28 UTC
Expected to be fixed in gamin-0.0.26-1 which was just pushed to rawhide,

  thanks !


Comment 15 Orion Poplawski 2005-04-08 17:26:16 UTC
gamin-0.0.26-1 appears to run fine here.  Can we get an update for FC3?

Note You need to log in before you can comment on or make changes to this bug.