events: make memory leak warning more programatically accessible #8298

addaleax · 2016-08-27T08:57:12Z

Checklist

make -j4 test (UNIX), or vcbuild test nosign (Windows) passes
tests and/or benchmarks are included
documentation is changed or added
commit message follows commit guidelines

Affected core subsystem(s)

events

Description of change

This makes the famous EventEmitter memory leak warnings occurring when the listener count for a given event exceeds a specified number more programatically accessible, by giving them properties referring to the event emitter instance and the event itself.

This can be useful for debugging the origins of such a warning when the stack itself doesn’t reveal enough information about the event emitter instance itself, e.g. when manual inspection of the
already-registered listeners is expected to be useful.

~~(It seems CI on this has to wait until Jenkins is running smoothly again…)~~
CI: https://ci.nodejs.org/job/node-test-commit/4794/

This makes the famous `EventEmitter memory leak` warnings occurring when the listener count for a given event exceeds a specified number more programatically accessible, by giving them properties referring to the event emitter instance and the event itself. This can be useful for debugging the origins of such a warning when the stack itself doesn’t reveal enough information about the event emitter instance itself, e.g. when manual inspection of the already-registered listeners is expected to be useful.

cjihrig · 2016-08-27T12:45:01Z

LGTM

jasnell · 2016-08-27T13:09:45Z

lib/events.js

                            `${existing.length} ${type} listeners added. ` +
                            'Use emitter.setMaxListeners() to increase limit');
+        w.name = 'Warning';


Assigning a specific warning name would make differentiating a bit easier as well.

+1 … but that would be a semver-major change?

Yeah, good point. Nevermind then

On Saturday, August 27, 2016, Anna Henningsen [email protected]
wrote:

In lib/events.js
#8298 (comment):

`${existing.length} ${type} listeners added. ` + 'Use emitter.setMaxListeners() to increase limit');

w.name = 'Warning';

+1 … but that would be a semver-major change?

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/nodejs/node/pull/8298/files/802e6be4c7e2bfd08224fb6769fbe7b2d8ed0239#r76515949,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAa2eW6tZ7CDeSmG54J9RAysM9fS9TBZks5qkDgHgaJpZM4Jupwl
.

jasnell · 2016-08-27T13:13:31Z

Couple of suggestions but otherwise LGTM

Fishrock123 · 2016-08-27T20:25:23Z

LGTM if CI is green

addaleax · 2016-08-30T15:12:57Z

Landed in 932c824

This makes the famous `EventEmitter memory leak` warnings occurring when the listener count for a given event exceeds a specified number more programatically accessible, by giving them properties referring to the event emitter instance and the event itself. This can be useful for debugging the origins of such a warning when the stack itself doesn’t reveal enough information about the event emitter instance itself, e.g. when manual inspection of the already-registered listeners is expected to be useful. PR-URL: #8298 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>

Switch from a generic `Warning` to the more specific `MaxListenersExceededWarning`. Ref: nodejs#8298

Switch from a generic `Warning` to the more specific `MaxListenersExceededWarning`. Ref: #8298 PR-URL: #8341 Reviewed-By: James M Snell <[email protected]> Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: Evan Lucas <[email protected]>

This makes the famous `EventEmitter memory leak` warnings occurring when the listener count for a given event exceeds a specified number more programatically accessible, by giving them properties referring to the event emitter instance and the event itself. This can be useful for debugging the origins of such a warning when the stack itself doesn’t reveal enough information about the event emitter instance itself, e.g. when manual inspection of the already-registered listeners is expected to be useful. PR-URL: nodejs#8298 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>

This makes the famous `EventEmitter memory leak` warnings occurring when the listener count for a given event exceeds a specified number more programatically accessible, by giving them properties referring to the event emitter instance and the event itself. This can be useful for debugging the origins of such a warning when the stack itself doesn’t reveal enough information about the event emitter instance itself, e.g. when manual inspection of the already-registered listeners is expected to be useful. PR-URL: #8298 Reviewed-By: Colin Ihrig <[email protected]> Reviewed-By: James M Snell <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>

Notable changes: * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark) #8304 * events: Made the "max event listeners" memory leak warning more accessible. (Anna Henningsen) #8298 * promises: Unhandled rejections now emit a process warning after the first tick. (Benjamin Gruenbaum) #8223 * repl: Added auto alignment for `.editor` mode. (Prince J Wesley) #8241 * util: Some functionality has been added to `util.inspect()`: - Returning `this` from a custom inspect function now works. (Anna Henningsen) #8174 - Added support for Symbol-based custom inspection methods. (Anna Henningsen) #8174 Refs: #8428 Refs: #8457 PR-URL: #8466

Notable changes: * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark) nodejs#8304 * events: Made the "max event listeners" memory leak warning more accessible. (Anna Henningsen) nodejs#8298 * promises: Unhandled rejections now emit a process warning after the first tick. (Benjamin Gruenbaum) nodejs#8223 * repl: Added auto alignment for `.editor` mode. (Prince J Wesley) nodejs#8241 * util: Some functionality has been added to `util.inspect()`: - Returning `this` from a custom inspect function now works. (Anna Henningsen) nodejs#8174 - Added support for Symbol-based custom inspection methods. (Anna Henningsen) nodejs#8174 Refs: nodejs#8428 Refs: nodejs#8457 PR-URL: nodejs#8466

Notable changes: * crypto: Added `crypto.timingSafeEqual()`. (not-an-aardvark) nodejs/node#8304 * events: Made the "max event listeners" memory leak warning more accessible. (Anna Henningsen) nodejs/node#8298 * promises: Unhandled rejections now emit a process warning after the first tick. (Benjamin Gruenbaum) nodejs/node#8223 * repl: Added auto alignment for `.editor` mode. (Prince J Wesley) nodejs/node#8241 * util: Some functionality has been added to `util.inspect()`: - Returning `this` from a custom inspect function now works. (Anna Henningsen) nodejs/node#8174 - Added support for Symbol-based custom inspection methods. (Anna Henningsen) nodejs/node#8174 Signed-off-by: Ilkka Myller <[email protected]>

addaleax added events Issues and PRs related to the events subsystem / EventEmitter. semver-minor PRs that contain new features and should be released in the next minor version. labels Aug 27, 2016

jasnell reviewed Aug 27, 2016
View reviewed changes

[squash] add note about --trace-warnings to docs

473c38d

addaleax closed this Aug 30, 2016

addaleax deleted the events-warning branch August 30, 2016 15:17

addaleax added a commit to addaleax/node that referenced this pull request Aug 30, 2016

events: make memory leak warning name more verbose

a6b6114

Switch from a generic `Warning` to the more specific `MaxListenersExceededWarning`. Ref: nodejs#8298

addaleax mentioned this pull request Aug 30, 2016

events: make memory leak warning name more verbose #8341

Closed

4 tasks

Fishrock123 mentioned this pull request Sep 6, 2016

v6.6.0 pre-proposal #8428

Closed

Fishrock123 mentioned this pull request Sep 9, 2016

v6.6.0 proposal #8466

Merged

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

events: make memory leak warning more programatically accessible #8298

events: make memory leak warning more programatically accessible #8298

addaleax commented Aug 27, 2016 •

edited

Loading

cjihrig commented Aug 27, 2016

jasnell Aug 27, 2016

addaleax Aug 27, 2016

jasnell Aug 27, 2016

jasnell commented Aug 27, 2016

Fishrock123 commented Aug 27, 2016

addaleax commented Aug 30, 2016

events: make memory leak warning more programatically accessible #8298

events: make memory leak warning more programatically accessible #8298

Conversation

addaleax commented Aug 27, 2016 • edited Loading

Checklist

Affected core subsystem(s)

Description of change

cjihrig commented Aug 27, 2016

jasnell Aug 27, 2016

Choose a reason for hiding this comment

addaleax Aug 27, 2016

Choose a reason for hiding this comment

jasnell Aug 27, 2016

Choose a reason for hiding this comment

jasnell commented Aug 27, 2016

Fishrock123 commented Aug 27, 2016

addaleax commented Aug 30, 2016

addaleax commented Aug 27, 2016 •

edited

Loading