It's not obvious to me why this commit is causing a memory leak error. Can someone else spot it?

Could be a missing call to uv_fs_req_cleanup(&request) in mch_isdir().
http://nikhilm.github.io/uvbook/filesystem.html#reading-writing-files

@tarruda Do you know if it's the same memory leak as described in #306?
How can I invoke valgrind locally with the correct options to see the memory leak? Does it occur while running make test or make unittest.

According to docs and as oni-link: Callbacks should free the uv_fs_t argument using uv_fs_req_cleanup().

The header uv.h describes under File System Mehtods, that after every uv_fs_* function completion a call to uv_fs_req_cleanup() is necessary, to free memory in the uv_fs_t object.

I am sorry for this. Obviously didn't read the documentation well enough. Somehow thought the call is just necessary when asynchronously invoking uv_fs_* functions. I hope that's the cause of the leak. How to proceed now? Should we revert the whole commit or does it suffice if I add another pull request adding the uv_fs_req_cleanup call?

@lslah don't worry, it can happen to anyone, actually it's my own fault for disabling valgrind check by travis.

To run valgrind you have to invoke cmake and the test target with the environment variable VALGRIND_CHECK=1(just export the variable in your shell). This is because cmake needs to define EXITFREE to ensure vim will always free everything before it exists. I dont recommend using this during development because it takes a long time to run, just let travis do the work for us.

I dont think its the same problem in #306 because this is just a memory leak

As for what to do, let me try to fix it myself, obviously I need to fix the travis script to make sure it wont timeout. I will send updates with rebase/squashs to this PR

@oni-link and @kans you were right, calling uv_fs_req_cleanup did the trick. If travis successfully completes the build I will merge this

Ok, now travis will properly check against memory leaks