warning: possible EventEmitter memory leak detected about execa HOT 12 CLOSED

Fixed in tapjs/signal-exit@395ccc8 🎉

from execa.

@perry-mitchell Ah! You're right. process is not the event emitter in question. My mental model of my own code was out of date. My apologies!

If you're spawning 11 or more child processes, and execa is setting a signal-exit handler for each one, then you'll definitely encounter this warning. You could work around it by calling process.__signal_exit_emitter__.setMaxListeners(..), but this is obviously diving into a (pseudo-)private API surface, and so probably not the best idea.

I think for cases like this, we're going to have to just allow unlimited event handlers. Since the emitter is global rather than tied to a specific workload, it's unlikely to be indicative of a problem. The alternative would be to maintain our own array of callbacks that we iterate in a single event handler, but that's just moving the problem around, and effectively the same solution anyway.

Look for a signal-exit PR shortly to fix this.

from execa.

Hi, I have the same warning when trying to compress 11 files with imagemin (using Promise.all). node --trace-warnings test.js points to an event emitter in signal-exit

(node:42081) Warning: Possible EventEmitter memory leak detected. 11 exit listeners added. Use emitter.setMaxListeners() to increase limit
    at _addListener (events.js:259:19)
    at EventEmitter.addListener (events.js:275:10)
    at module.exports (node_modules/signal-exit/index.js:41:11)
    at module.exports.err (node_modules/exec-buffer/node_modules/execa/index.js:146:23)
    at fsP.writeFile.then (node_modules/exec-buffer/index.js:35:15)

from execa.

/cc @sindresorhus

from execa.

@evilebottnawi See: tapjs/signal-exit#44

from execa.

It looks like you should be passing in parsed.opts.cleanup to make it clean up its signal-exit handler after it's done.

Why is this opt-in? It seems like it should be the default, or else this will happen. This is a legitimate event emitter memory leak caused by not cleaning up unneeded exit handlers.

from execa.

@isaacs I'm sorry, but it's not clear for me, where is the best place to handle such clean up? should it be the module which uses execa?

from execa.

@havenchyk It looks like cleanup: true should be passed into the call to execa. But, if I'm reading the code properly, that's already the default, so it's unclear if that's not already happening?

If you are not overriding the cleanup default, then perhaps you're just running more than 10 concurrent child processes with execa at once? In which case, you can avoid the warning by calling process.setMaxListeners(<number>) to increase the limit before the warning is printed.

from execa.

@isaacs Calling process.setMaxListeners() is troublesome when using tools like webpack/parallel-webpack further up the chain.. Even on a single process (like webpack) these warnings are visible (from image-webpack-loader). So if it occurs even on a single thread, would it not be best to address the issue at this level?

from execa.

@perry-mitchell I'm not sure I understand your question. Are you saying that the warnings are not coming from execa, but rather from the processes that execa is execing?

If so, then the bug is not in execa but rather in those other programs.

It looks from this like there's a way to make execa do the right thing (and it does it by default), so I'm not too keen on changing the warning. It's entirely possible that something else is creating an abundance of duplicate handlers elsewhere in the program.

from execa.

Sorry @isaacs - I guess I didn't quite understand the issue so well myself. It runs quite deep.

I get it when running my webpack or parallel-webpack scripts, building a ~1mb library (raw). I've narrowed the warnings down to image-webpack-loader when it calls compressors like pngquant. Those compressors call exec-buffer, which call execa, and then obviously signal-exit. I'm trying to find the best place to address this warning, because I know that what I'm doing with my build script isn't incorrect and I probably shouldn't be seeing warnings. The amount of spawned listeners for a single execution of webpack+imagemin-pngquant is about 11-13 max, so I don't think there's any issue here like the warning would have you believe.

Signal-exit has an internal emitter here which I can use to silence the warnings by setting emitter.setMaxListeners(0). If this can't/won't be resolved here, do you have any idea where the right place to tackle this would be? Using process.setMaxListeners(0) has no effect in execa or any other downstream packages.

from execa.

thank you @ALL

from execa.