Comment 67 for bug 36581

Ok, caught it again, this time on gamin-0.0.14-1 (which is current
rawhide AFAIK)

Using your fancy new SIGUSR2 debug trick, I get a quickly growing
file with this line repeated forever:

node_remove_subscription()

It's nice that another SIGUSR2 turns it off again, because it was
threatening to fill my disk :O

Interestingly, now strace shows nothing, nada, nichts, rien. (well
it shows the debug prints if that's enabled). Different problem
causing the same high CPU usage, or just difference due to code
changes you've made?

Latest gdb backtrace, this time with debuginfo installed:

#0 0x00135e42 in __i686.get_pc_thunk.bx ()
from /usr/lib/libglib-2.0.so.0
#1 0x00155944 in g_node_is_ancestor (node=0x8123018,
descendant=0x8058498) at gnode.c:413
#2 0x0804af3a in gam_tree_remove (tree=0x80583c8, node=0x8123018) at
gam_tree.c:144
#3 0x0804b7d3 in remove_directory_subscription (node=0x8123018,
sub=0x811c4e8) at gam_poll.c:507
#4 0x0804cd56 in gam_poll_consume_subscriptions () at gam_poll.c:918
#5 0x0804fc64 in gam_dnotify_consume_subscriptions_real (data=0x0)
at gam_dnotify.c:212
#6 0x0014e848 in g_idle_dispatch (source=0x8129f00,
callback=0x8123018, user_data=0x8058498) at gmain.c:3802
#7 0x0014b4fb in g_main_context_dispatch (context=0x8057ee8) at
gmain.c:1942
#8 0x0014cf82 in g_main_context_iterate (context=0x8057ee8, block=1,
dispatch=1, self=0x8053018) at gmain.c:2573
#9 0x0014d22f in g_main_loop_run (loop=0x8059908) at gmain.c:2777
#10 0x0804aa28 in main (argc=1, argv=0xfefffa54) at gam_server.c:330
#11 0x001b7b03 in __libc_start_main (main=0x804a8f7 <main>, argc=1,
ubp_av=0xfefffa54, init=0x8050304 <__libc_csu_init>,
    fini=0xfefff9e0, rtld_fini=0xfefffa54, stack_end=0xfefffa4c)
at ../sysdeps/generic/libc-start.c:209
#12 0x08049fa1 in _start ()

Stepping through it in ddd/gdb, I notice that in gam_tree_remove, the
g_node_is_ancestor sanity check seems to be consistently failing. To
be specific, in g_node_is_ancestor, descendent->parent seems to
always be null (only data and next are non-null). Somewhere the
trees aren't getting built right, or are being systematically
corrupted...

I'm not resetting gam_server for the moment; email me if you want to
telnet in and gdb it or X ddd out to your host to check it out, since
it seems to be difficult to reproduce...