node-api/test_exception fails in debug mode #26754
Assignees
Labels
build
Issues and PRs related to build files or the CI.
confirmed-bug
Issues with confirmed bugs.
node-api
Issues and PRs related to the Node-API.
test
Issues and PRs related to the tests.
Comments
addaleax
added
node-api
|
@addaleax for context is that any addons or just n-api addons? I'm guessing we don't test either in debug but thought I should ask to be sure. |
|
@mhdawson It doesn’t look like any add-ons are tested, but somebody from the build WG should be able to tell your for sure. |
|
In terms of add-on testing if it's not in the main test job then I think the answer is no. We do have another job that tests node-addon-api but that does not include debug either. |
|
@mhdawson Does that mean that addons aren’t tested on all platforms in general, not just not on debug builds? |
|
There are addon tests which run in the main test job for all platforms but that runs on regular not debug builds. So we have addon testing but I think in release not debug mode. |
|
As an example in:https://ci.nodejs.org/job/node-test-commit-linux/nodes=centos7-64-gcc6/26253/consoleFull these are some of the napi addon tests running: 13:53:27 ok 2344 js-native-api/test_array/test
13:53:27 ---
13:53:27 duration_ms: 0.173
13:53:27 ...
13:53:28 ok 2345 js-native-api/test_new_target/test
13:53:28 ---
13:53:28 duration_ms: 0.182
13:53:28 ...
13:53:28 ok 2346 js-native-api/test_exception/test
13:53:28 ---
13:53:28 duration_ms: 0.179
13:53:28 ...
13:53:28 ok 2347 js-native-api/test_function/test
13:53:28 ---
13:53:28 duration_ms: 0.182
13:53:28 ...
13:53:28 ok 2348 js-native-api/4_object_factory/test
13:53:28 --- |
|
ping @nodejs/n-api |
|
@addaleax can we close this? |
|
@gabrielschulhof No, I don’t think anything here has been addressed? This still crashes for me, and I don’t think the CI testing situation has been fixed either. Either way, the cause of the bug is already determined, so the question still isn’t whether we have to do anything here (we do), but whether we want to modify the behaviour here (e.g. use a
This should be |
addaleax
added a commit
to addaleax/node
that referenced
this issue
Jun 5, 2019
We have a test that verifies that JS execution from the Buffer finalizer is accepted, and that errors thrown are passed down synchronously. However, since the finalizer executes during GC, this is behaviour is fundamentally invalid and, for good reasons, disallowed by the JS engine. This leaves us with the options of either finding a way to allow JS execution from the callback, or explicitly forbidding it on the N-API side as well. This commit implements the former option, since it is the more backwards-compatible one, in the sense that the current situation sometimes appears to work as well and we should not break that behaviour if we don’t have to, but rather try to actually make it work reliably. Since GC timing is largely unobservable anyway, this commit moves the callback into a `SetImmediate()`, as we do elsewhere in the code, and a second pass callback is not an easily implemented option, as the API is supposed to wrap around Node’s `Buffer` API. In this case, exceptions are handled like other uncaught exceptions. Two tests have to be adjusted to account for the timing difference. This is unfortunate, but unavoidable if we want to conform to the JS engine API contract and keep all tests. Fixes: nodejs#26754
3 tasks
addaleax
added a commit
that referenced
this issue
Jun 14, 2019
We have a test that verifies that JS execution from the Buffer finalizer is accepted, and that errors thrown are passed down synchronously. However, since the finalizer executes during GC, this is behaviour is fundamentally invalid and, for good reasons, disallowed by the JS engine. This leaves us with the options of either finding a way to allow JS execution from the callback, or explicitly forbidding it on the N-API side as well. This commit implements the former option, since it is the more backwards-compatible one, in the sense that the current situation sometimes appears to work as well and we should not break that behaviour if we don’t have to, but rather try to actually make it work reliably. Since GC timing is largely unobservable anyway, this commit moves the callback into a `SetImmediate()`, as we do elsewhere in the code, and a second pass callback is not an easily implemented option, as the API is supposed to wrap around Node’s `Buffer` API. In this case, exceptions are handled like other uncaught exceptions. Two tests have to be adjusted to account for the timing difference. This is unfortunate, but unavoidable if we want to conform to the JS engine API contract and keep all tests. Fixes: #26754 PR-URL: #28082 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: James M Snell <jasnell@gmail.com>
BridgeAR
pushed a commit
that referenced
this issue
Jun 17, 2019
Previously, the throwing callback would have been re-executed in case of an exception. This patch corrects the calculation to exclude the callback. PR-URL: #28082 Fixes: #26754 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: James M Snell <jasnell@gmail.com>
BridgeAR
pushed a commit
that referenced
this issue
Jun 17, 2019
We have a test that verifies that JS execution from the Buffer finalizer is accepted, and that errors thrown are passed down synchronously. However, since the finalizer executes during GC, this is behaviour is fundamentally invalid and, for good reasons, disallowed by the JS engine. This leaves us with the options of either finding a way to allow JS execution from the callback, or explicitly forbidding it on the N-API side as well. This commit implements the former option, since it is the more backwards-compatible one, in the sense that the current situation sometimes appears to work as well and we should not break that behaviour if we don’t have to, but rather try to actually make it work reliably. Since GC timing is largely unobservable anyway, this commit moves the callback into a `SetImmediate()`, as we do elsewhere in the code, and a second pass callback is not an easily implemented option, as the API is supposed to wrap around Node’s `Buffer` API. In this case, exceptions are handled like other uncaught exceptions. Two tests have to be adjusted to account for the timing difference. This is unfortunate, but unavoidable if we want to conform to the JS engine API contract and keep all tests. Fixes: #26754 PR-URL: #28082 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: James M Snell <jasnell@gmail.com>
targos
pushed a commit
that referenced
this issue
Jun 18, 2019
Previously, the throwing callback would have been re-executed in case of an exception. This patch corrects the calculation to exclude the callback. PR-URL: #28082 Fixes: #26754 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: James M Snell <jasnell@gmail.com>
targos
pushed a commit
that referenced
this issue
Jun 18, 2019
We have a test that verifies that JS execution from the Buffer finalizer is accepted, and that errors thrown are passed down synchronously. However, since the finalizer executes during GC, this is behaviour is fundamentally invalid and, for good reasons, disallowed by the JS engine. This leaves us with the options of either finding a way to allow JS execution from the callback, or explicitly forbidding it on the N-API side as well. This commit implements the former option, since it is the more backwards-compatible one, in the sense that the current situation sometimes appears to work as well and we should not break that behaviour if we don’t have to, but rather try to actually make it work reliably. Since GC timing is largely unobservable anyway, this commit moves the callback into a `SetImmediate()`, as we do elsewhere in the code, and a second pass callback is not an easily implemented option, as the API is supposed to wrap around Node’s `Buffer` API. In this case, exceptions are handled like other uncaught exceptions. Two tests have to be adjusted to account for the timing difference. This is unfortunate, but unavoidable if we want to conform to the JS engine API contract and keep all tests. Fixes: #26754 PR-URL: #28082 Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com> Reviewed-By: Gabriel Schulhof <gabriel.schulhof@intel.com> Reviewed-By: James M Snell <jasnell@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Three questions:
Buffers?/cc @nodejs/n-api @nodejs/build
The text was updated successfully, but these errors were encountered: