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.

Raspberry Pi is an example.

BUG=v8:2393

Review URL: https://chromiumcodereview.appspot.com/11570061
Patch from Chi-Thanh Christopher Nguyen <nguyenchithanh@gmail.com>.

git-svn-id: https://v8.googlecode.com/svn/branches/bleeding_edge@13232 ce2b1a6d-e550-0410-aec6-3dcde31c8c00

This is a backport of v8/v8@44419ad089b729a1aab4a5f27c0833e2ce69d28b.

See http://code.google.com/p/v8/issues/detail?id=2493 for details.

This commit reapplies 9668df8b. The issue has been fixed upstream but
reappeared after last night's downgrade to V8 3.14.5 in commit b15a10e7.

Conflicts:
	test/simple/test-buffer.js

Fixes #4850.

Regardless of previous @bnoordhuis' changes

This reverts commit f80f3c5f.

Do not run the http/simple.js server in a child process.

Fix #4831

Commit 3d67f895 ("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 3d67f895.
This reverts commit 321b8eec.
This reverts commit 38df9d51.
This reverts commit f9afb3f0.
This reverts commit 13296e4b.
This reverts commit 3b715edd.

Reapply floating patches. Special mention: also reapplies 017009f8 but
with the extra change of removing DescriptorArray::kTransitionsIndex
from the postmortem metadata generator because said field no longer
exists in V8 3.14.

V8 3.15 and newer have stability and performance issues. Roll back to
a known-good version.

Only handle objects if explicitly told to do so in the options
object.  Non-buffer/string chunks are an error if not already in
objectMode.

Close #4662

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.

The functionality is available again per joyent/libuv@14eb8b0
and joyent/libuv@e89aced.

Fixes #3687.

Also, this adds a test that guarantees that the ordering of several
push() calls in a row is always preserved in synchronous readable streams

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

Apperently there is a case where calling the spinner was required after
passing a callback to nextTick(). This fixes that issue.

Fix #4795

It's a buffer so it's never bigger than Buffer::kMaxLength bytes,
which in turn is always < INT_MAX.

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.

It's not used outside of src/node.cc so make it static.

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.

It used to be off before. It's extremely unlikely that such an attack
would be a viable attack against node. And it makes AES much slower.