-
Notifications
You must be signed in to change notification settings - Fork 30k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
events: make memory leak warning more programatically accessible #8298
Conversation
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.
LGTM |
`${existing.length} ${type} listeners added. ` + | ||
'Use emitter.setMaxListeners() to increase limit'); | ||
w.name = 'Warning'; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Assigning a specific warning name would make differentiating a bit easier as well.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 … but that would be a semver-major change?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, good point. Nevermind then
On Saturday, August 27, 2016, Anna Henningsen notifications@github.com
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
.
Couple of suggestions but otherwise LGTM |
LGTM if CI is green |
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 <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <Fishrock123@rocketmail.com>
Switch from a generic `Warning` to the more specific `MaxListenersExceededWarning`. Ref: nodejs#8298
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 <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <Fishrock123@rocketmail.com>
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 <cjihrig@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Jeremiah Senkpiel <Fishrock123@rocketmail.com>
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 <ilkka.myller@nodefield.com>
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 <ilkka.myller@nodefield.com>
Checklist
make -j4 test
(UNIX), orvcbuild test nosign
(Windows) passesAffected 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/