This handles the fact that stream.Writable inherits from the Stream class,
meaning that it has the legacy pipe() method. Override that with a pipe()
method that emits an error.
Ensure that Duplex streams ARE still pipe()able, however.
Since the 'readable' flag on streams is sometimes temporary, it's probably
better not to put too much weight on that. But if something is an instanceof
Writable, rather than of Readable or Duplex, then it's safe to say that
reading from it is the wrong thing to do.
Fix#3647
It is not a valid test unless you're connected to the internet, and causes
a lot of spurious failures on Linux anyway, as it's highly dependent on
timing of things that we don't have any control over.
This makes the output of simple/test-debugger-repl and
simle/test-debugger-repl-utf8 mirror an actual debugger session, so it's
a bit easier to reason about.
Also, it uses the same code for both, and fixes it so that it doesn't
leave zombie processes lying around when it crashes.
Run 1000 times without any failures or zombies.
Starting the debugger directly in the SIGUSR1 signal handler results in
a malloc lock contention ~1% of the time. It hangs the test, which is
annoying on a daily basis to all of us, but it also is pretty terrible
if you actually want to debug a node process that has gone sideways.
Credit to @bnoordhuis for most of this. I just added the unref which
keeps it from messing up the event loop for other stuff.
The CI system requires that some environment variables are set so merge
our variables into the current environment instead of blindly replacing
it.
This will probably have to be repeated for other tests. C'est la vie.
Commit 3d67f89 ("fix generation of v8 constants on freebsd") is an
unfortunate victim of this rollback.
Revert "dtrace: fix generation of v8 constants on freebsd"
Revert "dtrace: More style"
Revert "dtrace: Make D style more D-ish"
Revert "dtrace: x64 ustack helper"
Revert "dtrace: fix style in ustack helper"
Revert "dtrace: SeqAsciiString was renamed to SeqOneByteString in v8"
This reverts commit 3d67f89552.
This reverts commit 321b8eec08.
This reverts commit 38df9d51a2.
This reverts commit f9afb3f010.
This reverts commit 13296e4b13.
This reverts commit 3b715edda9.
Reapply floating patches. Special mention: also reapplies 017009f but
with the extra change of removing DescriptorArray::kTransitionsIndex
from the postmortem metadata generator because said field no longer
exists in V8 3.14.
The Readable and Writable classes will nextTick certain things
if in sync mode. The sync flag gets unset after a call to _read
or _write. However, most of these behaviors should also be
deferred until nextTick if no reads have been made (for example,
the automatic '_read up to hwm' behavior on Readable.push(chunk))
Set the sync flag to true in the constructor, so that it will not
trigger an immediate 'readable' event, call to _read, before the
user has had a chance to set a _read method implementation.
Commit 9901b69c introduces a small regression where the trailing base64
padding is no longer written out when Cipher#final is called. Rectify
that.
Fixes#4837.
There are cases where a push() call would return true, even though
the thing being pushed was in fact way way larger than the high
water mark, simply because the 'needReadable' was already set, and
would not get unset until nextTick.
In some cases, this could lead to an infinite loop of pushing data
into the buffer, never getting to the 'readable' event which would
unset the needReadable flag.
Fix by splitting up the emitReadable function, so that it always
sets the flag on this tick, even if it defers until nextTick to
actually emit the event.
Also, if we're not ending or already in the process of reading, it
now calls read(0) if we're below the high water mark. Thus, the
highWaterMark value is the intended amount to buffer up to, and it
is smarter about hitting the target.
It seems like a good idea on the face of it, but lowWaterMarks are
actually not useful, and in practice should always be set to zero.
It would be worthwhile for writers if we actually did some kind of
writev() type of thing, but actually this just delays calling write()
and the overhead of doing a bunch of Buffer copies is not worth the
slight benefit of calling write() fewer times.
lib/path.js:
- throws a TypeError on the filter if the argument is not a string.
test/simple/test-path.js:
- removed the test to check if non-string types are filtered.
- added a test to check if path.join throws TypeError on arguments that
are not strings.
lib/http.js is using stream._handle.readStart/readStop to control
data-flow coming out from underlying stream. If this methods are not
present - data might be buffered regardless of whether it'll be read.
see #4657
Checks have been simplified and optimized for most-used cases.
Calling Buffer with another Buffer as the subject will now use the
SlowBuffer Copy method instead of the for loop.
No need to call for value coercion, just place the ternary inline.
ASN1_STRING_to_UTF8() passes an ASN1_STRING to ASN1_STRING_set() but forgot to
initialize the `length` field.
Fixes the following valgrind error:
$ valgrind -q --track-origins=yes --num-callers=19 \
out/Debug/node test/simple/test-tls-client-abort.js
==2690== Conditional jump or move depends on uninitialised value(s)
==2690== at 0x784B69: ASN1_STRING_set (asn1_lib.c:382)
==2690== by 0x809564: ASN1_mbstring_ncopy (a_mbstr.c:204)
==2690== by 0x8090F0: ASN1_mbstring_copy (a_mbstr.c:86)
==2690== by 0x782F1F: ASN1_STRING_to_UTF8 (a_strex.c:570)
==2690== by 0x78F090: asn1_string_canon (x_name.c:409)
==2690== by 0x78EF17: x509_name_canon (x_name.c:354)
==2690== by 0x78EA7D: x509_name_ex_d2i (x_name.c:210)
==2690== by 0x788058: ASN1_item_ex_d2i (tasn_dec.c:239)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x7890D4: asn1_template_noexp_d2i (tasn_dec.c:746)
==2690== by 0x788CB6: asn1_template_ex_d2i (tasn_dec.c:607)
==2690== by 0x78877A: ASN1_item_ex_d2i (tasn_dec.c:448)
==2690== by 0x787C93: ASN1_item_d2i (tasn_dec.c:136)
==2690== by 0x78F5E4: d2i_X509 (x_x509.c:141)
==2690== by 0x7C9B91: PEM_ASN1_read_bio (pem_oth.c:81)
==2690== by 0x7CA506: PEM_read_bio_X509 (pem_x509.c:67)
==2690== by 0x703C9A: node::crypto::SecureContext::AddRootCerts(v8::Arguments const&) (node_crypto.cc:497)
==2690== Uninitialised value was created by a stack allocation
==2690== at 0x782E89: ASN1_STRING_to_UTF8 (a_strex.c:560)
When perlasm generates MASM code it sets the assembler target to 468.
In this mode MASM refuses to assemble a couple of instructions. Bumping
the target to 686 solves this problem.
For throughput benchmarks, run with just 5s durations rather than 1s and 3s.
For startup benchmark, run with just a single 1s duration, since it's very
consistent anyway.
isaacs
Ben Noordhuis
yangguo@chromium.org
Timothy J Fontaine
Andrei Sedoi
Fedor Indutny
Nathan Rajlich
Arianit Uka
Trevor Norris
Bert Belder