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.
* http: Do not free the wrong parser on socket close (isaacs)
* http: Handle hangup writes more gently (isaacs)
* zlib: fix assert on bad input (Ben Noordhuis)
* test: add TAP output to the test runner (Timothy J Fontaine)
* unix: Handle EINPROGRESS from domain sockets (Ben Noordhuis)
This appears to fix#4673. That bug is very hard to reproduce, so it's
hard to tell for certain, but this approach is more correct anyway.
Hat-tip: @dougwilson
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.
The following test case occasionally triggered an assert because
write_in_progress_ didn't get cleared on error:
$ cat test.js
require('zlib').gunzip('BAM', console.log);
setTimeout(gc, 10);
$ while true; do node --expose-gc test.js || break; done
{ [Error: incorrect header check] errno: -3, code: 'Z_DATA_ERROR' }
Assertion failed: (!write_in_progress_ && "write in progress"),
function Clear, file ../src/node_zlib.cc, line 71.
Abort trap: 6
Steps to avoid that:
* Initialize all primitive member fields in the constructor.
* Clear the write_in_progress_ member field in ZCtx::Error().
* Ref the ZCtx object as soon as write_in_progress_ is set to true.
Before this commit, it could get GC'ed in the time between setting
the field and the call to ctx->Ref().
Fixes#4783.
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
isaacs
Ben Noordhuis
yangguo@chromium.org
Timothy J Fontaine
Andrei Sedoi
Fedor Indutny
Nathan Rajlich
Arianit Uka
Trevor Norris