Crashes reported for 271ef97 about libinotify-kqueue HOT 10 CLOSED

Could not reproduce on my NetBSD-CURRENT'13.

from libinotify-kqueue.

I know of it and it stated at line 137 of README in wulf7/integrate-dmatveev branch:

**** Libinotify-kqueue behaves as IN_EXCL_UNLINK flag is always set

Most probably it started with commit 9d09b2c
Bad thing here that i dont know easy way to implement behavior of inotify watch created with IN_EXCL_UNLINK flag unset without introducing memory leaks

I can tell you whats going on here in details but not just now due to ENOTIME. Maybe tomorrow or in a few days

Do you now any practical use of running inotify with IN_EXCL_UNLINK flag unset?

P.S. And it not crashes for me. Just sends IN_IGNORE and stops watching as intended

from libinotify-kqueue.

Hmm. Are you asked about crash or about inability of receiving events from deleted but still opened files?

from libinotify-kqueue.

Ooops. Sorry. I misunderstood a code in test case. My comment is correct but irrelevant to issue

from libinotify-kqueue.

Hi Vladimir, glad to hear from you.

Actually, there was an e-mail thread and you had been put into copy, though Mikhail (the reporter) said that messages are not delivered to you. Can you please recheck?

Mikhail reported that after commit 271ef97 (where some loops were modified as in worker_add_or_modify) he started to observe crashes in some apps which use libinotify.

This test should prove that, though I failed to reproduce anything, I am trying to get more details now.

from libinotify-kqueue.

Got it! Try following patch:

diff --git a/worker-sets.c b/worker-sets.c
index 504b8cf..442adf5 100644
--- a/worker-sets.c
+++ b/worker-sets.c
@@ -83,7 +83,6 @@ worker_sets_extend (worker_sets *ws,
             return -1;
         }
         ws->watches = ptr;
-        ws->watches[0] = NULL;

         ws->allocated = to_allocate;
     }

from libinotify-kqueue.

Actually, there was an e-mail thread and you had been put into copy, though Mikhail (the reporter) said that messages are not delivered to you. Can you please recheck?

Unfortunately, my personal mail server lost rackspace in datacentre about month ago so I cant respond on any mails till I find another place for it

from libinotify-kqueue.

One should set a watch on directory with number of entries more than WS_RESERVED (10) to trigger this issue. That`s why it was not discovered with test suite

from libinotify-kqueue.

Really, the issue was there. Thanks!

BTW, how do you debug libinotify? I do not remember if I had any issues four years ago, but in my current NetBSD installations I just can not hook into library's functions with gdb for step-by-step debugging (it can not find any debug symbols), though all flags required for that are present.

from libinotify-kqueue.

how do you debug libinotify?

I replace -DNDEBUG with -DDEBUG in Makefile.am to enable assertions then set environment variables CFLAGS=-g -O0 CXXFLAGS=-g -O0 before configure stage to add debugging info and then run configure with --enable-perrors. Sometimes I run tests under valgrind control but not very often as it requires some level of source patching to workaround some valgrind porting deficiencies and FreeBSD lpthread bugs
And I'm using post-mortem analysis of core dumps and debugging printfs mostly rather then step-by-step tracing as code base and execution paths are not very complex

from libinotify-kqueue.