stack build --file-watch fails sometimes

[charles-cooper]

Leaving stack build --file-watch on in a local project intermittently results in the following message:

removeWatch: invalid argument (Invalid argument)
Type help for available commands. Press enter to force a rebuild.

The solution is to restart stack. This seems to have appeared since upgrading to 1.0.4.

$ stack --version
Version 1.0.4, Git revision cf18703b1392a96a5a4896a560309e501af63260 (3220 commits) x86_64
$ uname -a
Linux ip-172-31-43-180 3.13.0-79-generic #123-Ubuntu SMP Fri Feb 19 14:27:58 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux

[mgsloan]

I've also encountered this, but only after hours of usage. I haven't investigated it yet. I've dug into the related code a bit, though:

We're using the high level fsnotify watchDir function from fileWatch, so I think that the issue is either there or the hinotify package it uses on linux. Here's the definition of removeWatch in hinotify:

removeWatch :: WatchDescriptor -> IO ()
removeWatch (WatchDescriptor (INotify _ fd _ _ _) wd) = do
    _ <- throwErrnoIfMinus1 "removeWatch" $
      c_inotify_rm_watch (fromIntegral fd) wd
    return ()

So, when the c function returns an exit code, it throws an invalid argument exception. This can happen in the following cases (from here):

EBADF
fd is not a valid file descriptor.
EINVAL
The watch descriptor wd is not valid; or fd is not an inotify file descriptor.

I'm not sure why this would happen. Maybe it's sufficient to catch the exception?

[kadoban]

I've noticed this before as well, but haven't been able to isolate what's going wrong. One correlation I noticed (that may or may not actually exist) is that it seems to happen after deleting directories with code in them that was being watched.

[charles-cooper]

@mgsloan good info!

@kadoban that's a good insight. I was able to reproduce the bug here: https://github.com/charles-cooper/watchDir-bug

@mgsloan Another interesting thing I noticed is that running rm src/Data/Foo.hs in that project results in a stack running a rebuild .. and exiting successfully. Not sure if this is a bug. Looks like the object files are getting over-optimistically cached in .stack-work.

[mgsloan]

I've also recently gotten a stack: c_poll: permission denied (Operation not permitted), but operation continued.

@charles-cooper Yup, that's a bug. I've opened #1841

[charles-cooper]

is it possible to work around this in stack by catching the exception and restarting the file watcher?

[mgsloan]

Yup, seems to be straightforward to catch and ignore it. Fixed!