delta/node-new.git/src/node_errors.cc, branch try_Python3_on_macOS

src: allow fatal exceptions to be enhanced

2019-07-07T15:55:48+00:00

This commit allows fatal exceptions to be enhanced so that
exceptions thrown from an unhandledException handler have
the stack attached properly.

PR-URL: https://github.com/nodejs/node/pull/28562
Fixes: https://github.com/nodejs/node/issues/28550
Reviewed-By: Joyee Cheung 
Reviewed-By: Rich Trott 
Reviewed-By: Anna Henningsen

process: split routines used to enhance fatal exception stack traces

2019-06-27T12:22:08+00:00

Previously the enhancement were done right after emitting
`'uncaughtException'`, which meant by the time we knew the
exception was fatal in C++, the error.stack had already been
patched.

This patch moves those routines to be called later during the
fatal exception handling, and split them into two stages:
before and after the inspector is notified by the invocation of
`V8Inspector::exceptionThrown`. We now expand the stack to include
additional informations about unhandled 'error' events before
the inspector is notified, but delay the highlighting of the
frames until after the inspector is notified, so that the
ANSI escape sequences won't show up in the inspector console.

PR-URL: https://github.com/nodejs/node/pull/28308
Fixes: https://github.com/nodejs/node/issues/28287
Reviewed-By: Benjamin Gruenbaum

src: refactor uncaught exception handling

2019-06-19T08:16:37+00:00

The C++ land `node::FatalException()` is not in fact fatal anymore.
It gives the user a chance to handle the uncaught exception
globally by listening to the `uncaughtException` event. This patch
renames it to `TriggerUncaughtException` in C++ to avoid the confusion.

In addition rename the JS land handler to `onGlobalUncaughtException`
to reflect its purpose - we have to keep the alias
`process._fatalException` and use that for now since it has been
monkey-patchable in the user land.

This patch also

- Adds more comments to the global uncaught exception handling routine
- Puts a few other C++ error handling functions into the `errors`
  namespace
- Moves error-handling-related bindings to the `errors` binding.

Refs: https://github.com/nodejs/node/commit/2b252acea47af3ebeac3d7e68277f015667264cc

PR-URL: https://github.com/nodejs/node/pull/28257
Reviewed-By: Anna Henningsen 
Reviewed-By: Benjamin Gruenbaum 
Reviewed-By: Franziska Hinkelmann

src: restore stdio on program exit

2019-06-13T03:47:03+00:00

Record the state of the stdio file descriptors on start-up and restore
them to that state on exit.  This should prevent issues where node.js
sometimes leaves stdio in raw or non-blocking mode.

This is a reworked version of commit c2c9c0c3d3 from May 2018 that was
reverted in commit 14dc17df38 from June 2018. The revert was a little
light on details but I infer that the problem was caused by a missing
call to `uv_tty_reset_mode()`.

Apropos the NOLINT comments: cpplint doesn't understand do/while
statements, it thinks they're while statements without a body.

Fixes: https://github.com/nodejs/node/issues/14752
Fixes: https://github.com/nodejs/node/issues/21020
Original-PR-URL: https://github.com/nodejs/node/pull/20592

PR-URL: https://github.com/nodejs/node/pull/24260
Reviewed-By: Colin Ihrig 
Reviewed-By: James M Snell 
Reviewed-By: Refael Ackermann (רפאל פלחי) 
Reviewed-By: Anna Henningsen

src: handle exceptions from ToDetailString()

2019-06-09T20:34:42+00:00

These methods may fail if execution is terminating.

PR-URL: https://github.com/nodejs/node/pull/28019
Reviewed-By: Rich Trott 
Reviewed-By: Michaël Zasso 
Reviewed-By: Ben Noordhuis 
Reviewed-By: Colin Ihrig 
Reviewed-By: Ruben Bridgewater

src, lib: take control of prepareStackTrace

2019-05-21T20:39:09+00:00

Refs https://crbug.com/v8/7848

PR-URL: https://github.com/nodejs/node/pull/23926
Reviewed-By: Refael Ackermann 
Reviewed-By: Joyee Cheung

src: remove util-inl.h from header files

2019-05-13T20:43:26+00:00

Its intended that *-inl.h header files are only included into the src
files that call the inline methods. Explicitly include it into the files
that need it.

PR-URL: https://github.com/nodejs/node/pull/27631
Reviewed-By: Joyee Cheung 
Reviewed-By: James M Snell 
Reviewed-By: Rich Trott 
Reviewed-By: Colin Ihrig

src: move OnMessage to node_errors.cc

2019-04-26T11:03:14+00:00

Rename the per-isolate message listener to `PerIsolateMessageListener`
and move it to `node_errors.cc` since it's part of the error
handling process. It also creates an external reference so it needs
to be exposed in `node_errors.h` for a snapshot builder to know.

PR-URL: https://github.com/nodejs/node/pull/27304
Reviewed-By: Anna Henningsen

src: handle fatal error when Environment is not assigned to context

2019-04-17T10:00:42+00:00

Previously when an uncaught JS error is thrown before Environment was
assigned to the context (e.g. a SyntaxError in a per-context script),
it triggered an infinite recursion:

1. The error message listener `node::OnMessage()` triggered
   `node::FatalException()`
2. `node::FatalException()` attempted to get the Environment
   assigned to the context entered using `Environment::GetCurrent()`
3. `Environment::GetCurrent()` previously incorrectly accepted
   out-of-bound access with the length of the embedder data array
   as index, and called `context->GetAlignedPointerFromEmbedderData()`
4. The out-of-bound access in `GetAlignedPointerFromEmbedderData()`
   triggered a fatal error, which was handled by `node::FatalError()`
5. `node::FatalError()` called `Environment::GetCurrent()`, then
   we went back to 3.

This patch fixes the incorrect guard in 3. When
`Environment::GetCurrent()` returns nullptr (when Environment is not
yet assigned to the context) in 2, it now prints the JS stack trace
and crashes directly.

PR-URL: https://github.com/nodejs/node/pull/27236
Reviewed-By: Ben Noordhuis 
Reviewed-By: James M Snell 
Reviewed-By: Anna Henningsen

process: add --unhandled-rejections flag

2019-04-15T16:29:07+00:00

This adds a flag to define the default behavior for unhandled
rejections. Three modes exist: `none`, `warn` and `strict`. The first
is going to silence all unhandled rejection warnings. The second
behaves identical to the current default with the excetion that no
deprecation warning will be printed and the last is going to throw
an error for each unhandled rejection, just as regular exceptions do.
It is possible to intercept those with the `uncaughtException` hook
as with all other exceptions as well.

This PR has no influence on the existing `unhandledRejection` hook.
If that is used, it will continue to function as before.

PR-URL: https://github.com/nodejs/node/pull/26599
Reviewed-By: Benjamin Gruenbaum 
Reviewed-By: Matteo Collina 
Reviewed-By: Matheus Marchini 
Reviewed-By: Michael Dawson 
Reviewed-By: Сковорода Никита Андреевич 
Reviewed-By: Sakthipriyan Vairamani