The variable isn't actually used uninitialized but g++ 4.8 doesn't know
that. Set it to NULL to silence the following compiler warning:
../src/string_bytes.cc:247:29: warning: 'data' may be used
uninitialized in this function [-Wmaybe-uninitialized]
unsigned a = hex2bin(src[i * 2 + 0]);
^
../src/string_bytes.cc:299:15: note: 'data' was declared here
const char* data;
^
V8 was upgraded from 3.22 to 3.24 in commit 1c7bf24. Upgrade source
files in test/addons/ and automatically generated tests from
doc/api/addons.markdown to the new V8 API.
This coincidentally fixes a bug in src/node_object_wrap.h where it was
still using the old V8 weak persistent handle interface, which is gone
in 3.24.
* ::jsstack -v prints function defintion
* ::jsprint works with objects with only numeric properties
* update tests to use builtin mdb_v8
* add more symbols to postmortem script - pending upstream
inclusion
Previously if you wanted to be notified of pending handles for pipes
you needed to use uv_read2_start, however in v0.11.22 you can query for
pending handles independently.
Internally we use hrtime to schedule when a timer will fire, to avoid
the perils of clock drift or other external operation making time go
backward. The timers ordering test should use the same timing mechanism
Fix the following valgrind warning:
Conditional jump or move depends on uninitialised value(s)
at 0x7D64E7: v8::internal::GlobalHandles::IterateAllRootsWithClassIds(v8::internal::ObjectVisitor*) (global-handles.cc:613)
by 0x94DCDC: v8::internal::NativeObjectsExplorer::FillRetainedObjects() (profile-generator.cc:2849)
# etc.
This was fixed upstream in r12903 and released in 3.15.2 but that commit
was never back-ported to the 3.14 branch that node.js v0.10 uses.
The code itself works okay; this commit simply shuffles the clauses in
an `if` statement to check that the node is in use before checking its
class id (which is uninitialized if the node is not in use.)
When sending a socket to a child process via IPC pipe,
`child_process.js` picks a raw UV handle from `_handle` property, sends
it, and assigns `null` to the property. Sending the same socket twice
was resulting in a runtime error, since we weren't handling the empty
`_handle` case.
In case of `null` `_handle` we should send just a plain text message
as passed it was passed to `.send()` and ignore the handle, letting
users handle such cases themselves instead of throwing the error at
runtime.
fix#5469
It's currently not really possible to compile native add-ons with
-fvisibility=hidden because that also hides the struct containing
the module definition.
The NODE_MODULE() and NODE_MODULE_DECL() macros are structured in
a way that makes it impossible to add a visibility attribute manually
so there is no escape hatch there.
That's why this commit adds an explicit visibility attribute to
the module definition. It doesn't help with node.js releases that
are already out there but at least it improves the situation going
forward.
If two timers run on the same tick, and the first timer uses a domain,
and then catches an exception and disposes of the domain, then the
second timer never runs. (And even if the first timer does not dispose
of the domain, the second timer could run under the wrong domain.)
This happens because timer.js uses "process.nextTick()" to schedule
continued processing of the timers for that tick. However, there was
an exception inside a domain, then "process.nextTick()" runs under
the domain of the first timer function, and will do nothing if
the domain has been disposed.
To avoid this, we temporarily save the value of "process.domain"
before calling nextTick so that it does not run inside any domain.
Previously if you cached process.nextTick and then require('domain')
subsequent nextTick() calls would not be caught because enqueued
functions were taking the wrong path. This keeps nextTick to a single
function reference and changes the implementation details after domain
has been required.
When `setImmediate(cb)` is called in `beforeExit` event handler the
consequent `uv_run(..., UV_RUN_NOWAIT)` may return `0`, even if there
was some active handles at start.
Fixes simple/test-beforeexit-event.js.
Unlike the 'exit' event, this event allows the user to schedule more
work and thereby postpone the exit. That also means that the
'beforeExit' event may be emitted many times, see the attached test
case for an example.
Refs #6305.
libuv gyp builds now require you to define the library disposition
(static or shared).
Also, libuv now supports vectored IO for file system reads and writes,
update to those function signatures
Between `ClientRequest` and `Agent`. The circular require was doing
weird things at load time, like making the `globalAgent` property
be `undefined` from within the context of the "_http_client"
module.
Removing the circular dependency completely fixes this.
This commit effectively removes the undocumented `Agent#request()`
and `Agent#get()` functions.
Don't invoke the `agent.requst()` or `agent.get()` functions
directly. Instead, use the public API and pass the agent
instance in as the `agent` option.
For the `request()` and `get()` functions. I could never
really understand why these two functions go through agent
first... Especially since the user could be passing `agent: false`
or a different Agent instance completely, in which `globalAgent`
will be completely bypassed.
Moved the relevant logic from `Agent#request()` into the
`ClientRequest` constructor.
Incidentally, this commit fixes#7012 (which was the original
intent of this commit).
This makes it so that the user may pass in a
`createConnection()` option, and they don't have
to pass `agent: false` at the same time.
Also adding a test for the `createConnection` option,
since none was in place before.
See #7014.
Expose `setBlocking` on Pipe's and if a pipe is being created for stdio
on windows then make the pipes blocking.
This fixes test-stream2-stderr-sync.js on Windows.
Fixes#3584
One test case in test-stream2-stderr-sync.js was creating a TTY
object using an undocumented constructor and passing in fd 2.
However, this is running in a child process and fd 2 is actually
a pipe, not a TTY.
The constructor fails on Windows and causes the handle type to be
left uninitialized, which later causes an assert to fail.
On Unix, the constructor fails to retrieve the windows size but unlike
on Windows, it just leaves the size fields undefined and continues
with initializing the stream type, yielding a semi-usable object.
I could make the Windows version match Unix behavior, but it
seems to me that the test is relying on an implementation detail of
an undocumented API, and the Unix behavior is not necessarily more
correct than the Windows one. Thus it makes more sense to remove this
test.
Ben Noordhuis
Fedor Indutny
Yazhong Liu
Timothy J Fontaine
Bryan Cantrill
Saúl Ibarra Corretgé
Shuhei Kagawa
Vladimir Kurchatkin
Brian White
Benoit Vallée
Greg Brail
Sam Roberts
Nathan Rajlich
Trevor Norris
Alexis Campailla