EventEmitter memory leak error about ember-cli-babel

[stefanpenner]

ember-cli/ember-cli#5987

[denchen]

I'm getting a very similar error. I'm using ember-cli 2.5.0 with ember-cli-babel 5.1.6. I've seen this on OSX with Node 4.4.5 and RedHat with Node 0.12.

Here's my error:

% ember serve
(node) warning: possible EventEmitter memory leak detected. 11 exit listeners added. Use emitter.setMaxListeners() to increase limit.
Trace
    at process.addListener (events.js:239:17)
    at Object.<anonymous> (/Users/denchen/dev/ops-ui/node_modules/ember-cli-babel/node_modules/broccoli-babel-transpiler/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:449:9)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
    at Object.<anonymous> (/Users/denchen/dev/ops-ui/node_modules/ember-cli-babel/node_modules/broccoli-babel-transpiler/node_modules/broccoli-merge-trees/node_modules/can-symlink/index.js:1:73)
    at Module._compile (module.js:409:26)
    at Object.Module._extensions..js (module.js:416:10)
    at Module.load (module.js:343:32)
    at Function.Module._load (module.js:300:12)
    at Module.require (module.js:353:17)
    at require (internal/module.js:12:17)
   at Object.<anonymous> (/Users/denchen/dev/ops-ui/node_modules/ember-cli-babel/node_modules/broccoli-babel-transpiler/node_modules/broccoli-merge-trees/index.js:9:18) 
Environment: development
Livereload server on http://localhost:49153
Serving on http://localhost:3000/

Build successful - 6821ms.

I'm not sure if it's an issue with a node_module or my code, and I'm not fluent enough in the world of Node to even begin to debug this.

[stefanpenner]

Seems related to tmp, unsure what we can do on our end.

[denchen]

Speaking of /tmp, I only just noticed that a lot of directories are left over. After cleaning out /tmp and then starting Ember, there are 1700+ directories. After stopping & starting Ember again, there are 3400+ directories. Is this normal that files aren't being cleaned up?

[stefanpenner]

@denchen they should be cleaned up

[stefanpenner]

@denchen they should be cleaned up

Well, actually ones in system tmp are the result of persistent filters that do remain. project/tmp should be cleanedup

[denchen]

@stefanpenner Hmm, yeah, my <project>/tmp folder is not being cleaned up. For now, I'm rm -rf tmp/ before each time I start Ember. Is there anything I can do to help narrow down the root cause?

[stefanpenner]

Make a reproduction and share it as an issue

[denchen]

https://github.com/denchen/test-app

I've tried to remove as much fluff as possible and still have the /tmp and EventEmitter issue. I could probably pare it down by removing even more packages if you so desire. Again, I'm seeing this with OSX + Node 4.4.5.

[stefanpenner]

@denchen thanks

[stefanpenner]

still have the /tmp

doesn't sound like a problem, that is the persistent cache. OS cleans it up periodically

[stefanpenner]

node 4.4x and 5.x didn't seem to have the leak when tested on https://github.com/denchen/test-app

A reproduction would help diagnose, but seems so far as not to reproduce for me. Would love something, to debug. Any more details would be great.

[stefanpenner]

@denchen was able to provide me with an example.

The problem appears to be (still confirming):

• more then 10 dependencies try to do cleanup when the process exists, one of which is tmp (there may be duplicates.
• for some reason the limit of 10 is set, and is likely far to low a default

offenders:

./ember-suave/node_modules/temp/test/temp-test.js:process.addListener('exit', function() {
./ember-suave/node_modules/temp/lib/temp.js:    process.addListener('exit', cleanupSync);
./ember-cli-postcss/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-cli/node_modules/bower/lib/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-cli/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-cli/node_modules/temp/test/temp-test.js:process.addListener('exit', function() {
./ember-cli/node_modules/temp/lib/temp.js:    process.addListener('exit', cleanupSync);
./ember-component-css/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-intl/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-data/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-cli-qunit/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-cli-moment-shim/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-cli-babel/node_modules/broccoli-babel-transpiler/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {
./ember-cli-blanket/node_modules/broccoli-merge-trees/node_modules/can-symlink/node_modules/tmp/lib/tmp.js:process.addListener('exit', function _exit(code) {

[stefanpenner]

quick reproduction that also works on my machine..;

var count = 0;

for (var i = 0; i < 11; i++) {
        process.addListener('exit', function() {
                        console.log('didExit', count++);
        });
}

[stefanpenner]

I can think of two solutions:

1. ember-cli can just set process.setMaxListeners(1000);
2. we can create an add-on that wraps process.addListener and ensures we never add more then intended.

I'm likely going to role with 1. but would love input.

[Turbo87]

I tend to agree, although 1000 seems quite high as well.

[stefanpenner]

@Turbo87 is there a downside? I figure if someone has a real problem, it would need to grow behind that.

[Turbo87]

just the gut feeling that the 10 might be there for a reason...