Master was disconnecting its workers as soon as they both started up.
Meanwhile, the workers were trying to listen. Its a race, sometimes the
disconnect would happen between when worker gets the response message,
and acks that message with a 'listening'. This worked OK after v0.11
introduced a behaviour where disconnect would always exit the worker,
but once that backwards-incompatible behaviour is removed, the worker
lives long enough to try and respond to the master, and child_process
errors at the attempt to send from a disconnected child.
This is a problem present in both v0.10, and v0.11, where the 'setup'
event is synchronously emitted by `cluster.setupMaster()`, a mostly
harmless anti-pattern.
Fix inadvertent v0.11 changes to the definition of suicide, particularly
the relationship between suicide state, the disconnect event, and when
exit should occur.
In v0.10, workers don't forcibly exit on disconnect, it doesn't give
them time to do a graceful finish of open client connections, they exit
under normal node rules - when there is nothing left to do. But on
unexpected disconnect they do exit so the workers aren't left around
after the master.
Note that a test as-written was invalid, it failed against the v0.10
cluster API, demonstrating that it was an undocumented API change.
Fixes issue in 0.11 where callback doesn't occur if worker count is
currently zero. In 0.10 callback occurs after worker count is zero, and
occurs in next tick if worker count is currently zero.
QueryString.stringify() allowed a fourth argument that was used as a
conditional in the return value, but was undocumented, not used by core
and always was always false/undefiend. So the argument and conditional
have been removed.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
The test is expecting an invalid result for the loopback
interface network mask, but this issue was fixed in
libuv commit 1d5c61a8b31257733c41fb507762d3eb56eecb2d
Closes#5262#6673
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
FSEventStream may emit events that happened right before it has started.
Ignore changes emitted for the directory itself, since they may come
from the stale events.
This was failing if the file didn't already exist.
Fixes unit tests on Windows:
* test\simple\test-http-curl-chunk-problem.js
* test\simple\test-pipe-file-to-http.js
This adds two new member functions getAuthTag and setAuthTag that
are useful for AES-GCM encryption modes. Use getAuthTag after
Cipheriv.final, transmit the tag along with the data and use
Decipheriv.setAuthTag to have the encrypted data verified.
1. Swallow errors when sending internal NODE_HANDLE_ACK messages, so
they don't crash the process.
2. Queue process.disconnect() if there are any pending queued messages.
Fixes test-child-process-fork-net2.js on win.
Wildcard server names should not match subdomains.
Quote from RFC2818:
...Names may contain the wildcard
character * which is considered to match any single domain name
component or component fragment. E.g., *.a.com matches foo.a.com but
not bar.foo.a.com. f*.com matches foo.com but not bar.com.
fix#6610
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().
HTTP Parser instance was freed twice, leading to the reusal of it
in several different requests simultaneously.
The flow:
`socketCloseListener` is firing, which calls `socket.read()` to flush
any queued data, `socket.buffer` has data which emits and fires
`socketOnData` in sync, this triggers a parser error which frees the
parser, `socketCloseListener` resumes execution only to have the wrong
parser associated with the socket.
The fix is to only cache the parser after the flushing from the socket,
and to assert in `socketOnData` that `socket === parser.socket`
fix#6451
Add a 'serialNumber' property to the object that is returned by
tls.CryptoStream#getPeerCertificate(). Contains the certificate's
serial number encoded as a hex string. The format is identical to
`openssl x509 -serial -in path/to/certificate`.
Fixes#6583.
Format negative zero as '-0' instead of as '0', as it does not behave
identically to positive zero. ((-0).toString() still returns '0' as
required by ES5 9.8.1.2).
Fixesjoyent/node#6548.
Closesjoyent/node#6550.
context._asyncQueue shouldn't be exposed as asyncQueue, as it allows
modification of queues already attached to an event. Which is not
supposed to happend. Instead context._asyncQueue should be copied.
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.
Removing the depth counter while processing the nextTickQueue made it
possible to run out of memory if in an infinite recursive loop using
nextTick(). There was also an edge case where too many callbacks were
pushed onto the nextTickQueue, while not actually being recursive.
This is being done to prevent possible cryptic FATAL ERROR messages from
popping up, and issues being posted about them.
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
Before this commit, passing --debugger and other V8 debug switches to
node.js made node print a usage message and exit.
Rewrite the debug argument parser so it only consumes switches that we
understand and pass everything else as-is to V8.
A side effect of this change is that switches like --debugger_agent and
--debugger_port now work. That kind of obsoletes our debugger switches
because they implement pretty much the same functionality but let's
leave them in for now for the sake of convenience and backwards
compatibility.
Fixes#6526.
Emitting an event within a `EventEmitter#once` callback of the same
event name will cause subsequent `EventEmitter#once` listeners of the
same name to be called multiple times.
var emitter = new EventEmitter();
emitter.once('e', function() {
emitter.emit('e');
console.log(1);
});
emitter.once('e', function() {
console.log(2);
});
emitter.emit('e');
// Output
// 2
// 1
// 2
Fix the issue, by calling the listener method only if it was not
already called.
Fix invalid `hasOwnProperty` function usage.
For example, before in the REPL:
```
> Ar<Tab>
Array
Array ArrayBuffer
```
Now:
```
> Ar<Tab>
Array
ArrayBuffer
```
Fixes#6255.
Closes#6498.
This commit removes the simple/test-event-emitter-memory-leak test for
being unreliable with the new garbage collector: the memory pressure
exerted by the test case is too low for the garbage collector to kick
in. It can be made to work again by limiting the heap size with the
--max_old_space_size=x flag but that won't be very reliable across
platforms and architectures.
Otherwise the string triggers an assertion error in node_http_parser.c,
line 370:
assert(Buffer::HasInstance(args[0]) == true);
because the first argument is not a Buffer object.
When socket, passed in `tls.connect()` `options` argument is not yet
connected to the server, `_handle` gets assigned to a `net.Socket`,
instead of `TLSSocket`.
When socket is connecting to the remote server (i.e. not yet connected,
but already past dns resolve phase), derive `_connecting` property from
it, because otherwise `afterConnect()` will throw an assertion.
fix#6443
Tuğrul Topuz
Timothy J Fontaine
Sam Roberts
Fedor Indutny
Yorkie
Vladimir Kurchatkin
Trevor Norris
Alexis Campailla
Cam Swords
Yorkie
Lalit Kapoor
Ingmar Runge
Kai Groner
Ben Noordhuis
David Chan
Jeremy Martin
Tim Wood
Maciej Małecki
isaacs
fengmk2