Original commit message:
[heap] fix crash during the scavenge of ArrayBuffer
Scavenger should not attempt to visit ArrayBuffer's storage, it is a
user-supplied pointer that may have any alignment. Visiting it, may
result in a crash.
BUG=
R=jochen
Review URL: https://codereview.chromium.org/1406133003
Cr-Commit-Position: refs/heads/master@{#31611}
PR-URL: https://github.com/nodejs/node/pull/4259
Reviewed-By: Ali Ijaz Sheikh <ofrobots@google.com>
Reviewed-By: James M Snell <jasnell@gmail.com>
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.
Original commit message:
Add SetAbortOnUncaughtExceptionCallback API
The --abort-on-uncaught-exception command line switch makes
Isolate::Throw abort if the error being thrown cannot be caught by a
try/catch block.
Embedders may want to use other mechanisms than try/catch blocks to
handle uncaught exceptions. For instance, Node.js has "domain" objects
that have error handlers that can handle uncaught exception like
following:
var d = domain.create();
d.on('error', function onError(err) {
console.log('Handling error');
});
d.run(function() {
throw new Error("boom");
});
These error handlers are called by isolates' message listeners.
If --abort-on-uncaught-exception is *not* used, the isolate's
message listener will be called, which will in turn call the domain's
error handler. The process will output 'Handling error' and will exit
successfully (not due to an uncaught exception). This is the behavior
that Node.js users expect.
However, if --abort-on-uncaught-exception is used and when throwing an
error within a domain that has an error handler, the process will abort
and the domain's error handler will not be called. This is not the
behavior that Node.js users expect.
Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
determine when it's not appropriate to abort and instead handle the
exception via the isolate's message listener.
In the example above, Node.js would set a custom callback with
SetAbortOnUncaughtExceptionCallback that would be implemented as
following (the sample code has been simplified to remove what's not
relevant to this change):
bool ShouldAbortOnUncaughtException(Isolate* isolate) {
return !IsDomainActive();
}
Now when --abort-on-uncaught-exception is used, Isolate::Throw would
call that callback and determine that it should not abort if a domain
with an error handler is active. Instead, the isolate's message listener
would be called and the error would be handled by the domain's error
handler.
I believe this can also be useful for other embedders.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1375933003
Cr-Commit-Position: refs/heads/master@{#31111}
Ref: #3036
Ref: https://github.com/nodejs/node/pull/3481
PR-URL: https://github.com/nodejs/node/pull/4106
Reviewed-By: bnoordhuis - Ben Noordhuis <info@bnoordhuis.nl>
Reviewed-By: targos - Michaël Zasso <mic.besace@gmail.com>
Reviewed-By: rvagg - Rod Vagg <rod@vagg.org>
Original commit message:
[heap] fix crash during the scavenge of ArrayBuffer
Scavenger should not attempt to visit ArrayBuffer's storage, it is a
user-supplied pointer that may have any alignment. Visiting it, may
result in a crash.
BUG=
R=jochen
Review URL: https://codereview.chromium.org/1406133003
Cr-Commit-Position: refs/heads/master@{#31611}
PR-URL: https://github.com/nodejs/node/pull/3549
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
Backport 1ee712ab8687e5f4dec93d45da068d37d28feb8b from V8 upstream.
Original commit message:
Add SetAbortOnUncaughtExceptionCallback API
The --abort-on-uncaught-exception command line switch makes
Isolate::Throw abort if the error being thrown cannot be caught by a
try/catch block.
Embedders may want to use other mechanisms than try/catch blocks to
handle uncaught exceptions. For instance, Node.js has "domain" objects
that have error handlers that can handle uncaught exception like
following:
var d = domain.create();
d.on('error', function onError(err) {
console.log('Handling error');
});
d.run(function() {
throw new Error("boom");
});
These error handlers are called by isolates' message listeners.
If --abort-on-uncaught-exception is *not* used, the isolate's
message listener will be called, which will in turn call the domain's
error handler. The process will output 'Handling error' and will exit
successfully (not due to an uncaught exception). This is the behavior
that Node.js users expect.
However, if --abort-on-uncaught-exception is used and when throwing an
error within a domain that has an error handler, the process will abort
and the domain's error handler will not be called. This is not the
behavior that Node.js users expect.
Having a SetAbortOnUncaughtExceptionCallback API allows embedders to
determine when it's not appropriate to abort and instead handle the
exception via the isolate's message listener.
In the example above, Node.js would set a custom callback with
SetAbortOnUncaughtExceptionCallback that would be implemented as
following (the sample code has been simplified to remove what's not
relevant to this change):
bool ShouldAbortOnUncaughtException(Isolate* isolate) {
return !IsDomainActive();
}
Now when --abort-on-uncaught-exception is used, Isolate::Throw would
call that callback and determine that it should not abort if a domain
with an error handler is active. Instead, the isolate's message listener
would be called and the error would be handled by the domain's error
handler.
I believe this can also be useful for other embedders.
BUG=
R=bmeurer@chromium.org
Review URL: https://codereview.chromium.org/1375933003
Cr-Commit-Position: refs/heads/master@{#31111}
PR: #3036
PR-URL: https://github.com/nodejs/node/pull/3036
Reviewed-By: Ben Noordhuis <ben@strongloop.com>
Upgrade the bundled V8 and update code in src/ and lib/ to the new API.
Notable backwards incompatible changes are the removal of the smalloc
module and dropped support for CESU-8 decoding. CESU-8 support can be
brought back if necessary by doing UTF-8 decoding ourselves.
This commit includes https://codereview.chromium.org/1192973004 to fix
a build error on python 2.6 systems. The original commit log follows:
Use optparse in js2c.py for python compatibility
Without this change, V8 won't build on RHEL/CentOS 6 because the
distro python is too old to know about the argparse module.
PR-URL: https://github.com/nodejs/io.js/pull/2022
Reviewed-By: Rod Vagg <rod@vagg.org>
Reviewed-By: Trevor Norris <trev.norris@gmail.com>
* @indutny's SealHandleScope patch (484bebc38319fc7c622478037922ad73b2edcbf9)
has been cherry picked onto the top of V8 to make it compile.
* There's some test breakage in contextify.
* This was merged at the request of the TC.
PR-URL: https://github.com/iojs/io.js/pull/1632
This commit applies a secondary change in order to make `make test`
pass cleanly, specifically re-disabling post-mortem debugging in
common.gypi.
PR-URL: https://github.com/iojs/io.js/pull/1506
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This includes the out-of-tree patch (but fixed in upstream HEAD) from
commit 41c00a2 ("deps: enable v8 postmortem debugging again".)
PR-URL: https://github.com/iojs/io.js/pull/1399
Reviewed-By: Fedor Indutny <fedor@indutny.com>
This commit applies some secondary changes in order to make `make test`
pass cleanly:
* disable broken postmortem debugging in common.gypi
* drop obsolete strict mode test in parallel/test-repl
* drop obsolete test parallel/test-v8-features
PR-URL: https://github.com/iojs/io.js/pull/1232
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Original commit message:
api: introduce SealHandleScope
When debugging Handle leaks in io.js we found it very convenient to be
able to Seal some specific (root in our case) scope to prevent Handle
allocations in it, and easily find leakage.
R=yangguo
BUG=
Review URL: https://codereview.chromium.org/1079713002
Cr-Commit-Position: refs/heads/master@{#27766}
Should help us identify and fix Handle leaks in core and user-space code.
NOTE: Works only in Debug build now, but is still better than nothing.
PR-URL: https://github.com/iojs/io.js/pull/1395
Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl>
This commit upgrades V8 from 3.31.74.1 to 4.1.0.7. Despite the major
version bump, there are no API or ABI changes, it's a bug fix release
only.
PR-URL: https://github.com/iojs/io.js/pull/490
Reviewed-By: Colin Ihrig <cjihrig@gmail.com>
Reviewed-By: Fedor Indutny <fedor@indutny.com>
Reviewed-By: Kenan Sulayman <kenan@sly.mn>
Reviewed-By: Rod Vagg <rod@vagg.org>
V8 3.26.31 has received 14 patches since the upgrade to 3.26.33. Since
3.26.33 is technically a tag on the 3.27 branch, reverting back to
3.26.31 would remove now default functionality like WeakMaps. Because of
that the patches have simply been cherry-picked and squashed.
Here is a summary of all patches:
* Fix index register assignment in LoadFieldByIndex for arm, arm64, and
mips.
* Fix invalid attributes when generalizing because of incompatible map
change.
* Skip write barriers when updating the weak hash table.
* MIPS: Avoid HeapObject check in HStoreNamedField.
* Do GC if CodeRange fails to allocate a block.
* Array.concat: properly go to dictionary mode when required.
* Keep CodeRange::current_allocation_block_index_ in range.
* Grow heap slower if GC freed many global handles.
* Do not eliminate bounds checks for "<const> - x".
* Add missing map check to optimized f.apply(...).
* In GrowMode, force the value to the right representation to avoid
deopts between storing the length and storing the value.
* Reduce max executable size limit.
* Fix invalid condition in check elimination effects.
* Fix off-by-one error in Array.concat slow mode check.
For more information see: https://github.com/v8/v8/commits/3.26
Reviewed-By: Fedor Indutny <fedor@indutny.com>
This commit removes the simple/test-event-emitter-memory-leak test for
being unreliable with the new garbage collector: the memory pressure
exerted by the test case is too low for the garbage collector to kick
in. It can be made to work again by limiting the heap size with the
--max_old_space_size=x flag but that won't be very reliable across
platforms and architectures.
After the upgrade from 3.20.17.7 to 3.20.17.11, we've begun hitting
random assertions in V8 in memory-constrained / GC-heavy situations.
The assertions all seem to be related to heap allocations and garbage
collection but apart from that, they're all over the place.
This reverts commit 970bdccc38.
