search

gruntjs / grunt-contrib-watch

Run tasks whenever watched files change.
http://gruntjs.com/
MIT License
1.98k stars 356 forks source link

Watch Error: FSEventStreamFlushSync(): failed assertion #415

Open tbremer opened 9 years ago

tbremer commented 9 years ago

I am getting the following error after Running "watch" task restarts

2015-03-02 11:19 grunt[7732] (FSEvents.framework) FSEventStreamFlushSync(): failed assertion '(SInt64)last_id > 0LL'

Happens with these versions:

$ node 0.11.6 - 0.12.0
$ npm 2.5.1

Related Grunt Config:

...
watch: {
  sass: {
    files: [
      '<%= configs.sassPaths.answ_sass + configs.minimatch %>',
      '<%= configs.sassPaths.sass_lib + configs.minimatch %>'
    ],
    options: {
      nospawn: true
    }
  }
}
...
crimann commented 9 years ago

Get exactly the same message when watch restarts. Happens on several projects with different configurations and on two different Macs.

Tested with those versions:

$ node v0.12.0
$ npm 2.3.0, 2.5.0, 2.7.0, 2.7.1
tannerlinsley commented 9 years ago

This happens for me too

TheBox193 commented 9 years ago

+1 Ditto

lancepadgett commented 9 years ago

Same here. Can't seem to find a solution...

alphanull commented 9 years ago

+1 Yeah, same here. Watch task seems to actually work, but nonetheless the message is a bit annoying. I am on Yosemite 10.10.2

greenchapter commented 9 years ago

Same here...

I think the problem is node.js in v0.12.0, on an older version no problems..

infinityplusone commented 9 years ago

Same problem. Upgraded to node.js v0.12.1, and it is still there.

ThomasHoadley commented 9 years ago

Same problem.

greenchapter commented 9 years ago

Does anyone write an bugreport to the nodejs guys?

vemec commented 9 years ago

Same here

$ node v0.12.2
$ npm 2.7.4
OSX 10.10.2 (14C1514)
grunt[22532] (FSEvents.framework) FSEventStreamFlushSync(): failed assertion '(SInt64)last_id > 0LL'
vladikoff commented 9 years ago

If anyone wants to try this in io.js, should be fixed there.

of6 commented 9 years ago

Still happening for me as well

node v0.12.2 npm 2.7.5 grunt-contrib-watch 0.6.1 OS X 10.10.3

This seems to happen more when it has to run an uglify or concat task. But both are at the latest version.

woerndl commented 9 years ago

Same here on

node v0.12.0 and v0.12.2 npm 2.5.1 and 2.7.4 grunt-contrib-watch 0.6.1 OS X 10.9.5

Happens only if I set the option spawn: false or nospawn: true. The tasks don't run correctly, it's not just the message for me.

Seams to work with node v0.10.26.

SudoCat commented 9 years ago

Same problem - Seems to be functioning fine, but always gives this error.

Node: v0.12.2,
NPM: 2.7.5,
grunt: 0.4.5,
grunt-contrib-concat: 0.5.1,
grunt-contrib-imagemin: 0.9.4,
grunt-contrib-uglify: 0.9.1,
grunt-contrib-watch: 0.6.1,
grunt-sass: 0.18.1,
OS X 10.10.2
(FSEvents.framework) FSEventStreamFlushSync(): failed assertion '(SInt64)last_id > 0LL'
jwgmeligmeyling commented 9 years ago

Can confirm.

yumyo commented 9 years ago

same here

Node v0.12.2
grunt-cli v0.1.13
grunt v0.4.5
grunt-contrib-watch 0.6.1
OS X 10.10.3
paulhayes commented 9 years ago

I'm also experiencing this issue

OSX: v10.10.2
Node v0.12.2
Npm v2.7.5
Packages:
├── grunt@0.4.5
├── grunt-contrib-connect@0.10.1
├── grunt-contrib-copy@0.8.0
├── grunt-contrib-less@1.0.1
├── grunt-contrib-uglify@0.9.1
├── grunt-contrib-watch@0.6.1
├── grunt-exec@0.4.6
└── grunt-express-server@0.5.1
digitalcraftco commented 9 years ago

Same here. node: v0.12.0

Removing spawn from Watch > Scripts > Options:{ } stops the error. What is spawn anyway again?

mikehdt commented 9 years ago

Might this potentially be why? https://github.com/bdkjones/fseventsbug/wiki/realpath()-And-FSEvents

juanbrujo commented 9 years ago

@digitalcraftco solution worked with v0.12.7, removing all spawns from watch: {} task (even if they're false)

digitalcraftco commented 9 years ago

@juanbrujo Thanks for the follow up. Indeed this has fixed the issue for newer versions.

Fishrock123 commented 9 years ago

Interesting. Is 0.11.6 the earliest node version this manifests in? We've had the above linked io.js issue for this for a while but haven't really been able to debug it.

flekschas commented 9 years ago

@digitalcraftco It defines whether a new task should be spawned or not. See https://github.com/gruntjs/grunt-contrib-watch#optionsspawn

Removing spawn from options does avoid but not fix the issue.

tconroy commented 9 years ago

+1 getting this as well still.

teejayhh commented 9 years ago

Interesting to note, as soon as you remove the spawn = false property the compile time jumps up dramatically, in my case from 0.3sec to 4.3sec !!

I just came across this error (with spawn set to false) maybe this is of help ->

(node) warning: possible EventEmitter memory leak detected. 11 change listeners added. Use emitter.setMaxListeners() to increase limit. Trace at StatWatcher.addListener (events.js:179:15) at Object.fs.watchFile (fs.js:1289:8) at Gaze._pollFile (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:329:10) at /Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:411:12 at Array.forEach (native) at /Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:409:11 at iterate (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/helper.js:52:5) at Object.forEachSeries (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/helper.js:66:3) at Gaze._initWatched (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:354:10) at Gaze._internalAdd (/Applications/MAMP/htdocs/bla/node_modules/grunt-contrib-watch/node_modules/gaze/lib/gaze.js:193:10)

jlujan commented 9 years ago

I see similar messages in a C app using libuv and uv_fs_event* I wrote as well. Linked to https://github.com/nodejs/node/issues/854 which mentions this issue.

maruf89 commented 8 years ago

Absolutely nothing changed in my dependencies for the last month at least and I randomly just started seeing this

Fishrock123 commented 8 years ago

@maruf89 Did you change OS X versions?

maruf89 commented 8 years ago

No, I'm still on Yosemite 10.10.3 - The only thing that changed is I got a hard drive cable replaced but no software/npm deps changed

ogmios2 commented 8 years ago

+1 having same issue

tuffz commented 8 years ago

@maruf89, same by me, i had only changed the hard drive cable.

Pedder commented 7 years ago

+1

ourcore commented 7 years ago

What are the side-effects to this error? It started occurring in my project after I added imagemin

Fishrock123 commented 7 years ago

What are the side-effects to this error?

Unknown, probably nothing impactful? I think the OS just retries or something.

Strange that multiple people would see it after a harddrive cable, maybe it's an odd apple hardware issue?

alphanull commented 7 years ago

Am sure it has nothing to do with hardware. As Fishrock123 said, no apparent(!) sideeffects, but still annoying. So a fix definetly would be nice, since also a lot of systems seem to be affected.

ekkis commented 7 years ago

I'm having this issue with node v7.3.0 on OSX 10.11.6 (El Capitan) and grunt v0.4.5, grunt-cli v1.2.0

cwklausing commented 7 years ago

I can't make sense of why this worked, but I was having the exact same issue, and adding more specific selectors for the files I was watching resolved the issue. Here's a sample of my old Gruntfile:

watch: {
    css: {
        files: '**/*.scss',
        tasks: ['sass']
    },
    js: {
        files: '**/*.js',
        tasks: ['rollup']
    }
}

and here's my new Gruntfile

watch: {
    css: {
        files: './assets/**/*.scss',
        tasks: ['sass']
    },
    js: {
        files: './assets/**/*.js',
        tasks: ['rollup']
    }
}

What's more--my old grunt process was using a huge chunk of my CPU, and with my more specific file selection, I use only 2-3%.