New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

stack build --file-watch fails sometimes #1838

charles-cooper opened this Issue Feb 24, 2016 · 6 comments


None yet
3 participants

charles-cooper commented Feb 24, 2016

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

This comment has been minimized.


mgsloan commented Feb 25, 2016

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):

fd is not a valid file descriptor.
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?


This comment has been minimized.


kadoban commented Feb 25, 2016

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.


This comment has been minimized.

charles-cooper commented Feb 25, 2016

@mgsloan good info!

@kadoban that's a good insight. I was able to reproduce the bug here:

@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.


This comment has been minimized.


mgsloan commented Feb 26, 2016

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

@mgsloan mgsloan added this to the P2: Should milestone Mar 18, 2017


This comment has been minimized.

charles-cooper commented Mar 21, 2017

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

mgsloan added a commit that referenced this issue Mar 27, 2017


This comment has been minimized.


mgsloan commented Mar 27, 2017

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

@mgsloan mgsloan closed this Mar 27, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment