(node:20446) Warning: Possible EventEmitter memory leak detected. 11 error listeners added. Use emitter.setMaxListeners() to increase limit

[francoisromain]

• Version: 6.4
• Platform: mac os 10.11.6
• Subsystem: (homebrew ?)

when doing npm install on a web project, it shows this error many times:

(node:20446) Warning: Possible EventEmitter memory leak detected. 11 error listeners added. Use emitter.setMaxListeners() to increase limit

[bnoordhuis]

You are probably filing this against the wrong project. "Possible EventEmitter memory leak detected" is not normally an issue with node.js itself, it's issuing the diagnostic to help you (generic you) track down resource leaks.

[francoisromain]

Ok sorry, I read here this could be related to node core: http://stackoverflow.com/a/16222062/2112538

[Fishrock123]

@francoisromain you're getting that from npm itself? or from running your project with node?

If it's your own project producing it, tracking should be easy: run with --trace-warnings.

if it's npm... that will be a bit more complex to set up but you can probably still narrow it down using that too. Although, you should probably report this to the npm repo then: https://github.com/npm/npm

[francoisromain]

@Fishrock123 This from doing npm install on a project. (for example this one: https://github.com/vuejs-templates/webpack-simple-2.0). This makes many errors like this one. I don't know if it is from npm or something else and --trace-warning didn't provide more infos.

[ChALkeR]

Is this reproducible with npm install --ignore-scripts?

[francoisromain]

@ChALkeR this is doing the same with --ignore-scripts.
Do you guys have the same error when you do this for example?
npm v 3.10.7, node 6.4.0

$ npm install -g vue-cli
$ vue init webpack-simple-2.0 my-project
$ cd my-project
$ npm install

[addaleax]

With --trace-warnings:

(node:19182) Warning: Possible EventEmitter memory leak detected. 11 error listeners added. Use emitter.setMaxListeners() to increase limit
    at _addListener (events.js:259:17)
    at TLSSocket.addListener (events.js:270:10)
    at TLSSocket.Readable.on (_stream_readable.js:688:35)
    at Request.<anonymous> (/home/xxxx/.nvm/versions/node/v6.4.0/lib/node_modules/npm/node_modules/npm-registry-client/lib/request.js:153:7)
    at emitOne (events.js:96:13)
    at Request.emit (events.js:188:7)
    at ClientRequest.<anonymous> (/home/xxxx/.nvm/versions/node/v6.4.0/lib/node_modules/npm/node_modules/request/request.js:791:10)
    at emitOne (events.js:101:20)
    at ClientRequest.emit (events.js:188:7)
    at tickOnSocket (_http_client.js:562:7)

The problem is that request uses an HTTP agent which reuses sockets, so the error handlers registered in these lines in npm-registry-client just pile up and keep being attached over the entire lifetime of the socket:

  req.on('socket', function (s) {
    s.on('error', cb)
  })

I am not actually a 100 % sure myself what is correct here. Should npm-registry-client not touch the underlying socket? Should http.Agents remove all user-provided event handlers when reusing a socket? Both?

/cc @nodejs/http

[jasnell]

Looks like an error in npm-registry-client. It's feasible that we could add an API for telling the agent to reset the listeners on a socket but that seems a bit dangerous. It's better to let npm-registry-client clean up after itself. Perhaps open an issue on that repo?

[addaleax]

Perhaps open an issue on that repo?

Will do! (edit: npm/npm-registry-client#142)

[mscdex]

-1 to removing user-added events in core. I would label this as a bug in userland IMHO.