When there is an error that is thrown in a nextTick function, which is
then handled by a domain or other process.on('uncaughtException')
handler, if the error handler *also* adds a nextTick and triggers
multiple MakeCallback events (ie, by doing some I/O), then it would
skip over the tickDepth check, resulting in an infinite spin.
Solution: Check the tickDepth at the start of the tick processing, and
preserve it when we are cleaning up in the error case or exiting early
in the re-entry case.
In order to make sure that tick callbacks are *eventually* handled, any
callback triggered by the underlying spinner in libuv will be processed
as if starting from a tick depth of 0.
This is rewrite of #3701 and #3603 before.
This patch introduce `util.inspect.styles`
and `util.inspect.colors` objects, which enables customization
of color sequences.
This reverts commit 928ea564d1.
Keeping the original Array instance in-place essentially causes a memory leak
on EventEmitters that use an infinite number of event names (an incrementing
counter, for example), which isn't an unreasonable thing to want to do.
Fixes#3702.
Before this commit, `fs.unwatchFile(path)` removed *all* listeners for `path`.
The function is overloaded now: `fs.unwatchFile(path)` still removes all
listeners, but `fs.unwatchFile(path, cb)` lets you remove a specific listener.
Fixes#3660.
Don't use the double-negate trick to coalesce the timeout argument into a
number, it produces the wrong result for very large timeouts.
Example:
setTimeout(cb, 1e10); // doesn't work, ~~1e10 == 1410065408
Wrong order of operands was causing problems while trying to use command
buffering:
> {
... a: 3,
...
repl.js:284
if (cmd.trim().match(/^npm /) && !self.bufferedCommand) {
^
TypeError: Cannot call method 'trim' of undefined
at finish (repl.js:284:17)
at REPLServer.self.eval (repl.js:118:5)
at rli.on.e (repl.js:260:20)
at REPLServer.self.eval (repl.js:118:5)
at Interface.<anonymous> (repl.js:250:12)
at Interface.EventEmitter.emit (events.js:88:17)
at Interface._onLine (readline.js:183:10)
at Interface._line (readline.js:502:8)
at Interface._ttyWrite (readline.js:720:14)
at ReadStream.<anonymous> (readline.js:105:12)
Test included.
Closes#3515.
Closes#3517.
Closes#3621.
For some reason, though, it looks like EnvGetter is not called for the
key `__proto__`, so I can't make the info->Data() accessible. However,
putting the Object.prototype keys there, in such a way that they are not
OwnProperties, and are supersceded by environs, makes process.env much
less weird.
There is no need for fs.readFile() to be using pread rather than read.
The default semantics of read() are such that subsequent reads are where
we want them anyway.