Preserve default install prefix seen in process.config, but use DESTDIR
for installing to deliniate 32/64 versions, avoid conflicts with PREFIX
settings in config.mk
Change vcbuild.bat to ignore VCINSTALLDIR environment variable,
always check for specific VS version and set GYP_MSVS_VERSION
accordingly. Otherwise GYP generates project files in format
that cannot be compiled by VS2012.
When developer calls setBreakpoint with an unknown script name,
we convert the script name into regular expression matching all
paths ending with given name (name can be a relative path too).
To create such breakpoint in V8, we use type `scriptRegEx`
instead of `scriptId` for `setbreakpoint` request.
To restore such breakpoint, we save the original script name
send by the user. We use this original name to set (restore)
breakpoint in the new child process.
This is a back-port of commit 5db936d from the master branch.
After much investigation it turns out that the affected servers are
buggy. user-service.condenastdigital.com:443 in particular seems to
reject large TLS handshake records. Cutting down the number of
advertised ciphers or disabling SNI fixes the issue.
Similarly, passing { secureOptions: constants.SSL_OP_NO_TLSv1_2 }
seems to fix most connection issues with IIS servers.
Having to work around buggy servers is annoying for our users but not
a reason to downgrade OpenSSL. Therefore, revert it.
This reverts commit 4fdb8acdae.
Several people have reported issues with IIS and Resin servers (or maybe
SSL terminators sitting in front of those servers) that are fixed by
downgrading OpenSSL. The AESNI performance improvements were nice but
stability is more important. Downgrade OpenSSL from 1.0.1e to 1.0.0f.
Fixes#5360 (and others).
Fixed a bug in debugger repl where `restart` command did not work
when a custom debug port was specified via command-line option
--port={number}.
File test/simple/helper-debugger-repl.js was extracted
from test/simple/test-debugger-repl.js
The uname function can return any non-negative int to indicate success.
Strange, but that's how it is documented. This also fixes a similar
buffer overflow in the even more unlikely event that info.release is
> 255 characters, similar to how 78c5de5 did for info.sysname.
Fixes#3740
In the case of pipelined requests, you can have a situation where
the socket gets destroyed via one req/res object, but then trying
to destroy *another* req/res on the same socket will cause it to
call undefined.destroy(), since it was already removed from that
message.
Add a guard to OutgoingMessage.destroy and IncomingMessage.destroy
to prevent this error.
It needs to apply the Transform class when the _readableState,
_writableState, or _transformState properties are accessed,
otherwise things like setEncoding and on('data') don't work
properly.
Also, the methods wrappers are no longer needed, since they're only
problematic because they access the undefined properties.
4716dc6 made assert.equal() and related functions work better by
generating a better toString() from the expected, actual, and operator
values passed to fail(). Unfortunately, this was accomplished by putting
the generated message into the error's `name` property. When you passed
in a custom error message, the error would put the custom error into
`name` *and* `message`, resulting in helpful string representations like
"AssertionError: Oh no: Oh no".
This commit resolves that issue by storing the generated message in the
`message` property while leaving the error's name alone and adding
a regression test so that this doesn't pop back up later.
Closes#5292.
I broke dgram.Socket#bind(port, cb) almost a year ago in 332fea5a but
it wasn't until today that someone complained and none of the tests
caught it because they all either specify the address or omit the
callback.
Anyway, now it works again and does what you expect: it binds the
socket to the "any" address ("0.0.0.0" for IPv4 and "::" for IPv6.)
process.stdout isn't fully initialized yet by the time the test starts
when invoked with `python tools/test.py`. Use process.stdin instead and
force initialization with process.stdin.resume().
Fix a NULL pointer dereference in src/handle_wrap.cc which is really a
use-after-close bug.
The test checks that unref() after close() works on process.stdout but
this bug affects everything that derives from HandleWrap. I discovered
it because child processes would sometimes quit for no reason (that is,
no reason until I turned on core dumps.)
When LD_LIBRARY_PATH is overriden for custom builds we need to preserve
it for child processes. To be sure we preserve whole environment of
parent process and just add TEST_INIT variable to it.
When LD_LIBRARY_PATH is overriden for custom builds we need to preserve
it for forked process. There are possibly other environment variables
that could cause test failures so we preserve whole environment of
parent process.
Fix a (rather academic) buffer overflow. MAXHOSTNAMELEN is 256 on most
platforms, which means the buffer wasn't big enough to hold the
trailing nul byte on a system with a maximum length hostname.
Fix#5272
The consumption of a readable stream is a dance with 3 partners.
1. The specific stream Author (A)
2. The Stream Base class (B), and
3. The Consumer of the stream (C)
When B calls the _read() method that A implements, it sets a 'reading'
flag, so that parallel calls to _read() can be avoided. When A calls
stream.push(), B knows that it's safe to start calling _read() again.
If the consumer C is some kind of parser that wants in some cases to
pass the source stream off to some other party, but not before "putting
back" some bit of previously consumed data (as in the case of Node's
websocket http upgrade implementation). So, stream.unshift() will
generally *never* be called by A, but *only* called by C.
Prior to this patch, stream.unshift() *also* unset the state.reading
flag, meaning that C could indicate the end of a read, and B would
dutifully fire off another _read() call to A. This is inappropriate.
In the case of fs streams, and other variably-laggy streams that don't
tolerate overlapped _read() calls, this causes big problems.
Also, calling stream.shift() after the 'end' event did not raise any
kind of error, but would cause very strange behavior indeed. Calling it
after the EOF chunk was seen, but before the 'end' event was fired would
also cause weird behavior, and could lead to data being lost, since it
would not emit another 'readable' event.
This change makes it so that:
1. stream.unshift() does *not* set state.reading = false
2. stream.unshift() is allowed up until the 'end' event.
3. unshifting onto a EOF-encountered and zero-length (but not yet
end-emitted) stream will defer the 'end' event until the new data is
consumed.
4. pushing onto a EOF-encountered stream is now an error.
So, if you read(), you have that single tick to safely unshift() data
back into the stream, even if the null chunk was pushed, and the length
was 0.
Timothy J Fontaine
Kevin Locke
Miroslav Bajtoš
Sam Roberts
isaacs
Ben Noordhuis
mscdex
Sean Silva
Ryan Doenges
Trevor Norris
Kelly Gerber
Ryan Graham
Stanislav Ochotnicky