A ReadableStream with a base64 StringDecoder backed by only
one or two bytes would fail to output its partial data before
ending. This fix adds a check to see if the `read` was triggered
by an internal `flow`, and if so, empties any remaining data.
fixes#7914.
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Previously v8's WriteUtf8 function would produce invalid utf-8 output
when encountering unmatched surrogate code units [1]. The new
REPLACE_INVALID_UTF8 option fixes that by replacing invalid code points
with the unicode replacement character.
[1]: JS Strings are defined as arrays of 16 bit unsigned integers. There
is no unicode enforcement, so one can easily end up with invalid unicode
code unit sequences inside a string.
The test cases are still essentially the same, but now all possible ways
of writing a buffer into the decoder are tested, which has exposed a few
failing scenarios that had not been discovered so far!
Ensure TypeError is thrown, fix a bug where `env` option was
assuming the option was actually an object.
This case is especially bad because it then sets `env == null`
instead of using `process.env`.
Fix#7456
Signed-off-by: Fedor Indutny <fedor@indutny.com>
Before this commit the EventEmitter methods were anonymous functions.
V8 tries to infer names for anonymous functions based on the execution
context but it frequently gets it wrong and when that happens, the
stack trace is usually confusing and unhelpful. This commit names all
methods so V8 can fall back to the method.name property.
The above gotcha applies to all anonymous functions but is exacerbated
for EventEmitter methods because those are invoked with a plenitude of
different receivers.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
Fix possible deadlock, when handles are sent in both direction
simultaneously. In such rare cases, both sides may queue their
`NODE_HANDLE_ACK` replies and wait for them.
fix#7465
Socket may become not `readable`, but http should not rely on this
property and should not think that it means that no data will ever
arrive from it. In fact, it may arrive in a next tick and, since
`this.push(null)` was already called, it will result in a error like
this:
Error: stream.push() after EOF
at readableAddChunk (_stream_readable.js:143:15)
at IncomingMessage.Readable.push (_stream_readable.js:123:10)
at HTTPParser.parserOnBody (_http_common.js:132:22)
at Socket.socketOnData (_http_client.js:277:20)
at Socket.EventEmitter.emit (events.js:101:17)
at Socket.Readable.read (_stream_readable.js:367:10)
at Socket.socketCloseListener (_http_client.js:196:10)
at Socket.EventEmitter.emit (events.js:123:20)
at TCP.close (net.js:479:12)
fix#6784
If two timers run on the same tick, and the first timer uses a domain,
and then catches an exception and disposes of the domain, then the
second timer never runs. (And even if the first timer does not dispose
of the domain, the second timer could run under the wrong domain.)
This happens because timer.js uses "process.nextTick()" to schedule
continued processing of the timers for that tick. However, there was
an exception inside a domain, then "process.nextTick()" runs under
the domain of the first timer function, and will do nothing if
the domain has been disposed.
To avoid this, we temporarily save the value of "process.domain"
before calling nextTick so that it does not run inside any domain.
Previously if you cached process.nextTick and then require('domain')
subsequent nextTick() calls would not be caught because enqueued
functions were taking the wrong path. This keeps nextTick to a single
function reference and changes the implementation details after domain
has been required.
This makes it so that the user may pass in a
`createConnection()` option, and they don't have
to pass `agent: false` at the same time.
Also adding a test for the `createConnection` option,
since none was in place before.
See #7014.
Ensure that the behavior of `assert.deepEqual` does not depend on
argument ordering when comparing an `arguments` object with a
non-`arguments` object.
The reason this wasn't working was because after restart, when restoring
breakpoints the scripts wasn't loaded, so the breakpoint.script was
undefined. As a fix I added another check to use breakpoint.scriptReq
instead of breakpoint.script, which is the same except when the
breakpoint is a function.
fixes#7027
Even if stdio streams are opened as file streams, we should not ever try
to close them. This could be accomplished by passing `autoClose: false`
in options on their creation.
The test was calling server.close() after write on the socket
had completed. However the fact that the write had completed was
not valid indication that the server had received the data.
This would result in a premutaure closing of the server and
an ECONNRESET event on the client.
domain.create().exit() should not clear the domain stack if the domain
instance does not exist within the stack.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
If a write is above the highWaterMark, _write still manages to
fully send it synchronously, _writableState.length will be adjusted down
to 0 synchronously with the write returning false, but 'drain' will
not be emitted until process.nextTick.
If another small write which is below highWaterMark is issued before
process.nextTick happens, _writableState.needDrain will be reset to false,
and the drain event will never be fired.
So we should check needDrain before setting it up, which prevents it
from inproperly resetting to false.
When `symlink`, `link` or `rename` report EEXIST, ENOTEMPTY or EPERM -
the destination file name should be included in the error message,
instead of source file name.
fix#6510
NOTE: Also removed `.receivedShutdown` method of `Connection` it wasn't
documented anywhere, and was rewritten with `true` after receiving
`close_notify`.
fix#6638
When calling `encOut` in loop, `maybeInitFinished()` may invoke
`clearOut`'s loop, leading to the writing of interleaved data
(encrypted and cleartext) into the one shared pool.
Move `maybeInitFinished()` out of the loop and add assertion for
future.
The null signal test existed, but only tested the case where the target
process existed, not when it did not exist.
Also clarified that SIGUSR1 is reserved by Node.js only for receiveing,
its not at all reserved when sending a signal with kill().
kill(pid, 'O_RDWR'), or any other node constant, "worked". I fixed this
by also checking for 'SIG'. The same as done in the isSignal() function.
Now the signal names supported by process.kill() are the same as those
supported by process.on().
Check that `listeners` is actually an array before trying to manipulate it
because it won't be if no regular event listeners have been registered yet
but there are 'removeListener' event listeners.
v8's `messages.js` file's `CallSiteGetMethodName` is running through all
object properties and getter to figure out method name of function that
appears in stack trace. This run-through will also read `fd` property of
`UDPWrap` instance's javascript object, making `UNWRAP()` fail.
As a simple alternative to the test case above, one could just keep
reference to the dgram handle and try accessing `handle.fd` after it has
been fully closed.
fix#6536
Fedor Indutny
Chris Dickinson
Felix Geisendörfer
Greg Sabia Tucker
Ben Noordhuis
Rod Vagg
isaacs
Fedor Indutny
Benoit Vallée
Greg Brail
Timothy J Fontaine
Nathan Rajlich
Mike Pennisi
Farid Neshat
Kenan Sulayman
iamdoron
Jun Ma
Alexis Campailla
Ryan Graham
ayanamist
Kai Groner
Sam Roberts
Jeremy Martin