[16:12] <DV> okay
[16:12] <foser> (gdb) bt
[16:12] <foser> #0  0xffffe410 in ?? ()
[16:12] <foser> #1  0xbfffd458 in ?? ()
[16:12] <foser> #2  0x00000024 in ?? ()
[16:12] <foser> #3  0xbfffd4b0 in ?? ()
[16:12] <foser> #4  0x40d662a3 in __write_nocancel () from /lib/libpthread.so.0
[16:12] <foser> #5  0x413ce6ab in gamin_write_byte (fd=18, data=0xbfffd4b0 "$",
len=36)
[16:12] <foser>     at gam_api.c:475
[16:12] <foser> #6  0x413cee46 in gamin_try_reconnect (conn=0x817f148, fd=18) at
gam_api.c:768
[16:12] <foser> #7  0x413cf96b in FAMPending (fc=0x817d540) at gam_api.c:1227
[16:12] <foser> #8  0x413bc1ad in fam_do_iter_unlocked () at file-method.c:2148
[16:12] <foser> #9  0x413bc3c0 in fam_callback (source=0x817d9c0, condition=17,
data=0x817d540)
[16:12] <foser>     at file-method.c:2163
[16:12] <foser> #10 0x40db750d in g_io_unix_dispatch (source=0x817da18,
[16:12] <foser>     callback=0x413bc370 <fam_callback>, user_data=0xfffffe00) at
giounix.c:161
[16:12] <foser> #11 0x40d916fd in g_main_context_dispatch (context=0x80e17d0) at
gmain.c:1942
[16:12] <foser> #12 0x40d932bd in g_main_context_iterate (context=0x80e17d0,
block=1,
[16:12] <foser>     dispatch=1, self=0x80c0370) at gmain.c:2573
[16:12] <foser> #13 0x40d9357f in g_main_loop_run (loop=0x8259848) at gmain.c:2777
[16:12] <foser> #14 0x408c6d23 in gtk_main () at gtkmain.c:1173
[16:12] <foser> #15 0x0806337d in main (argc=36, argv=0xbffff7c4) at main.c:99
[16:12] <foser> (gdb) continue
[16:12] <foser> Continuing.
[16:13] <DV> it's blocked on a write descriptor, when trying to restart the
connections
[16:13] <DV> so the problem should be server side
[16:14] <DV> so gdb attach the gam_server and see what it's doing
[16:14] <foser> a sec
[16:15] <DV> np
[16:15] <foser> (gdb) bt
[16:15] <foser> #0  0xffffe410 in ?? ()
[16:15] <foser> #1  0xbfffe4e8 in ?? ()
[16:15] <foser> #2  0x00000036 in ?? ()
[16:15] <foser> #3  0xbfffe520 in ?? ()
[16:15] <foser> #4  0x40146553 in __write_nocancel () from /lib/libc.so.6
[16:15] <foser> #5  0x0804d9e0 in gam_client_conn_write (source=0xfffffe00,
fd=14, data=0xbfffe520, len=54) at gam_channel.c:770
[16:15] <foser> #6  0x0804e8a4 in gam_send_event (conn=0x805b680, reqno=-512,
event=-1073748704,
[16:15] <foser>     path=0x805dda0
"/usr/share/gnome/vfolders/Settings.directory", len=44) at gam_connection.c:509
[16:15] <foser> #7  0x0804a9f4 in gam_server_emit_event (path=0x805dda0
"/usr/share/gnome/vfolders/Settings.directory", event=GAMIN_EVENT_EXISTS,
[16:16] <foser>     subs=0x8058b04) at gam_server.c:250
[16:16] <foser> #8  0x0804c3fc in gam_poll_scan_directory_internal
(dir_node=0x0, exist_subs=0x8058c0c, scan_for_new=1) at gam_poll.c:468
[16:16] <foser> #9  0x0804ce7c in gam_poll_consume_subscriptions () at
gam_poll.c:855
[16:16] <foser> #10 0x0805028f in gam_dnotify_consume_subscriptions_real
(data=0x0) at gam_dnotify.c:212
[16:16] <foser> #11 0x4004bd71 in g_idle_dispatch (source=0x805c778,
callback=0x36, user_data=0xfffffe00) at gmain.c:3802
[16:16] <DV> cool ! a deadlock ...
[16:16] <foser> #12 0x400486fd in g_main_context_dispatch (context=0x8059a28) at
gmain.c:1942
[16:16] <foser> #13 0x4004a2bd in g_main_context_iterate (context=0x8059a28,
block=1, dispatch=1, self=0x8054048) at gmain.c:2573
[16:16] <foser> #14 0x4004a57f in g_main_loop_run (loop=0x805b428) at gmain.c:2777
[16:16] <foser> #15 0x0804abd3 in main (argc=1, argv=0xbffff834) at gam_server.c:330
[16:17] <foser> i expected something like that, but what gives it away here
exactly ?
[16:18] <DV> I think I unerstand the issue ... however it's unclear how best fix
it ... probably with a protocol update
[16:18] <DV> for some reason the gam_server restarted
[16:19] <DV> the client had pushes all the open monitors back on the new server
[16:19] <DV> the server sent a lot of data as a result
[16:19] <DV> none of them are in read mode
[16:19] <DV> pipe is full in both directions, both stucks on write

Best way is probably to change the protocol on reconnects.

Daniel

Okay, I think I was seeing something like this when recursively monitoring a
large directory. Here's what I said in a mail:

What happens is we iterate down over the homedir pumping "monitor directory"
requests down a blocking socket to gam_server. On the other side gam_server is
busily processing those requests, polling the contents of the directory and
pumping back "exists" messages down its side of the blocking socket. Both the
client and server are hung while writing to the socket, so I can only assume
their buffers are full and they're deadlocked waiting for the other to read.

I guess the solution would be to either use non-blocking sockets or for the
server to queue up requests rather than processing them immediately.
Non-blocking sockets would probably be better because the client would naturally
be rate-limited by the server.

gamin is not under active development anymore and has not seen code changes for many years.
Its codebase has been archived: https://gitlab.gnome.org/Archive/gamin/commits/master

Closing this report as WONTFIX as part of Bugzilla Housekeeping to reflect reality. Please feel free to reopen this ticket (or rather transfer the project to GNOME Gitlab, as GNOME Bugzilla is deprecated) if anyone takes the responsibility for active development again.