Segmentation fault

[es128]

var fsevents = require('./');

var watcher = fsevents('../jquery/node_modules').start().on('change', console.log);

cd ../jquery && rm-rf node_modules && npm i

I used jquery's repo as the example because it has enough deps to trigger the issue reliably, none of which compile anything with gyp - ruling that out as being related to the cause. That said, YMMV, it may take more than one attempt to trigger the segfault.

Adding https://www.npmjs.com/package/segfault-handler to the test script yields the following stack trace:

PID 20242 received SIGSEGV for address: 0x10
0   segfault-handler.node               0x0000000100cef90f _ZL16segfault_handleriP9__siginfoPv + 287
1   libsystem_platform.dylib            0x00007fff8d776f1a _sigtramp + 26
2   ???                                 0x00007fff5fbf6278 0x0 + 140734799766136
3   CoreFoundation                      0x00007fff91f7fe68 __CFArrayReleaseValues + 264
4   CoreFoundation                      0x00007fff91fa3398 CFArrayRemoveAllValues + 120
5   fse.node                            0x0000000100cf2b55 _Z15async_propagateP10uv_async_s + 217
6   node                                0x000000010051b7af uv__async_event + 62
7   node                                0x000000010051b922 uv__async_io + 136
8   node                                0x000000010052937d uv__io_poll + 1491
9   node                                0x000000010051bd92 uv_run + 267
10  node                                0x00000001004be8b8 _ZN4node5StartEiPPc + 336
11  node                                0x00000001000011f4 start + 52

cc/ @bajtos @bnoordhuis

paulmillr/chokidar#219

[bajtos]

Cross-posting from paulmillr/chokidar#219:

I just got it to happen once with io.js (1.0.1), but that was like 1 of 10 attempts. I can make it happen pretty consistently with node 0.10

[es128]

Actually I may need to test that out again. At the time I may have fallen into the trap of forgetting to npm rebuild after switching node/io versions. This causes the fsevents binaries to fail, but it's easy to not notice in chokidar because it silently falls back to the fs.watchFile-based watching method.

It's likely that the segfault is easily reproducible on any node/io version following the above procedure.

[es128]

Using the procedure at the top of this issue, I just had it happen 9 out of 10 times in io.js 1.0.4. If I split apart the commands, it appears to never have an issue with the rm -rf command, the segfault only seems to happen during the npm install, however that's only the case if the same watcher instance has been running during both operations.

[noahgrant]

Thank you for taking a look at this! This happens often for me using Gaze or Chokidar watchers when using gulp. At the end of the gulp series of tasks, the watch task is launched, and ~30% of the time it ends in a segfault (and I have to relaunch the ~40s long build process).

[es128]

Reopening issue as it was auto-closed by a commit that provides partial resolution.

[ansman]

I appear to still be getting this:

PID 5491 received SIGSEGV for address: 0xa41d29f
0   segfault-handler.node               0x0000000100afb91a _ZL16segfault_handleriP9__siginfoPv + 282
1   libsystem_platform.dylib            0x00007fff83549f1a _sigtramp + 26
2   ???                                 0x1baddead0baddeaf 0x0 + 1994495044801650351
3   CoreFoundation                      0x00007fff8120c278 __CFArrayReleaseValues + 264
4   CoreFoundation                      0x00007fff8122f738 CFArrayRemoveAllValues + 120
5   fse.node                            0x00000001029d5bba _Z15async_propagateP10uv_async_s + 224
6   node                                0x0000000100494301 uv__async_event + 65
7   node                                0x0000000100494484 uv__async_io + 136
8   node                                0x00000001004a20e3 uv__io_poll + 1579
9   node                                0x00000001004948e9 uv_run + 276
10  node                                0x0000000100435a48 _ZN4node5StartEiPPc + 344
11  node                                0x0000000100002134 start + 52

[pmq20]

It was observed from the core dump file that the crash occurred at __CFArrayReleaseValues of CFArrayRemoveAllValues. Analysis shows that when large number of items were added to a CFMutableArray, resizing of the container occurred. The resizing lead to FSEventRelease being prematurely called, causing the crash.

Therefore we store pointers in a plain vector to solve this problem.

#74