| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* uv: Upgrade to v0.10.23
* npm: Upgrade to v1.3.24
* v8: Fix enumeration for objects with lots of properties
* child_process: fix spawn() optional arguments (Sam Roberts)
* cluster: report more errors to workers (Fedor Indutny)
* domains: exit() only affects active domains (Ryan Graham)
* src: OnFatalError handler must abort() (Timothy J Fontaine)
* stream: writes may return false but forget to emit drain (Yang Tianyang)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
fix #6679
|
| | |
|
| |
|
|
|
|
|
| |
Spawn's arguments were documented to be optional, as they are for the
other similar child_process APIs, but the code was missing. Result was
`child_process.spawn('node', {})` errored when calling slice() on an
Object, now it behaves as the documentation said it would.
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
domain.create().exit() should not clear the domain stack if the domain
instance does not exist within the stack.
Signed-off-by: Trevor Norris <trev.norris@gmail.com>
|
| | |
|
| |
|
|
| |
fix #6859
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
spawn stdio options can be a 'stream', but the following code
fails with "Incorrect value for stdio stream: [object Object]",
despite being a stream. The problem is the test isn't really
for a stream, its for an object with a numeric `.fd` property,
and streams do not have an fd until their async 'open' event
has occurred. This is reasonable, but was not documented.
child_process.spawn('date', [], {stdio: [
'ignore',
fs.createWriteStream('out.txt',{flags:'a'}),
'ignore']})
|
| |
|
|
|
| |
Killing the debuggee without first closing the socket can result
in an ECONNRESET error.
|
| |
|
|
|
|
|
| |
If node was compiled with --no-ifaddrs to support older operating
systems, don't throw instead simply return an empty object
Fixes #6846
|
| |
|
|
|
|
|
| |
Keep the number of descriptors below
DescriptorArray::kMaxNumberOfDescriptors even for accessors
Review URL: https://codereview.chromium.org/11362182
|
| | |
|
| |
|
|
|
|
|
| |
We are in an unrecoverable state if v8 throws a FatalError, actually
ask the operating system to dump core in this case.
Fixes #6836
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a write is above the highWaterMark, _write still manages to
fully send it synchronously, _writableState.length will be adjusted down
to 0 synchronously with the write returning false, but 'drain' will
not be emitted until process.nextTick.
If another small write which is below highWaterMark is issued before
process.nextTick happens, _writableState.needDrain will be reset to false,
and the drain event will never be fired.
So we should check needDrain before setting it up, which prevents it
from inproperly resetting to false.
|
| | |
|
| |
|
|
| |
Ref #2598
|
| | |
|
| |
|
|
|
|
| |
The fact that the "exit" event passes the exit code as an argument
as omitted from the documentation. This adds the explanation and
augments the example code to show that.
|
| | |
|
| |
|
|
|
|
|
| |
Some errors for listening and binding to a socket were not properly
delivered to workers.
fix #6767
|
| | |
|
| | |
|
| |
|
|
|
| |
Search for VS2013 compiler 1st, before falling back to older ones. This
allows compiling using the latest VS2013.
|
| | |
|
| |
|
|
| |
node-gyp requires this file
|
| | |
|
| | |
|
| |\ |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
* uv: Upgrade to v0.10.21
* npm: upgrade to 1.3.21
* v8: backport fix for CVE-2013-{6639|6640}
* build: unix install node and dep library headers (Timothy J Fontaine)
* cluster, v8: fix --logfile=%p.log (Ben Noordhuis)
* module: only cache package main (Wyatt Preul)
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The %p is replaced with the current PID. This used to work in node.js
v0.9.7 but it seems to have been lost somewhere along the way.
This commit makes the fix from 6b713b52 ("cluster: make --prof work for
workers") work again. Without it, all log data ends up in a single
file and is unusable because the addresses are all wrong.
|
| |
|
|
|
| |
Restores functionality from v0.8 where module authors may not be
relying on gyp for building their modules.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
The 1.3.19 release had a critical bug: any packages published with it
could not be installed, because the shasum would be incorrect.
Thankfully, 1.3.19 was published using 1.3.19, so could not be installed
by any users! However, if it goes out as part of a Node.js release,
then obviously that would be a problem.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Quoting CVE-2013-6639:
The DehoistArrayIndex function in hydrogen-dehoist.cc in Google V8
before 3.22.24.7, as used in Google Chrome before 31.0.1650.63,
allows remote attackers to cause a denial of service (out-of-bounds
write) or possibly have unspecified other impact via JavaScript code
that sets the value of an array element with a crafted index.
Quoting CVE-2013-6640:
The DehoistArrayIndex function in hydrogen-dehoist.cc in Google V8
before 3.22.24.7, as used in Google Chrome before 31.0.1650.63,
allows remote attackers to cause a denial of service (out-of-bounds
read) via JavaScript code that sets a variable to the value of an
array element with a crafted index.
Like 6b92a7, this is unlikely to affect node.js because it only runs
local, trusted code. However, if there exists some module somewhere
that populates an array index with remotely provided data this could
very well be used to crash a remote server running node. Defense in
depth and all.
This is a backport of upstream commit r17801. Original commit log:
Limit size of dehoistable array indices
LOG=Y
BUG=chromium:319835,chromium:319860
R=dslomov@chromium.org
Review URL: https://codereview.chromium.org/74113002
|
| | |
|
| | |
|
| | |
|
