Skip to content

Conversation

@santigimeno
Copy link
Member

This is specially prevalent in the case of having in-progress FileHandle
operations in a worker thread while the Worker is exiting.

Fixes: #42829

@nodejs-github-botnodejs-github-bot added c++ Issues and PRs that require attention from people who are familiar with C++. fs Issues and PRs related to the fs subsystem / file system. needs-ci PRs that need a full CI run. labels Apr 29, 2022
@nodejs-github-bot

This comment was marked as outdated.

@aduh95aduh95 added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. request-ci Add this label to start a Jenkins CI on a PR. labels Apr 29, 2022
@github-actionsgithub-actionsbot removed the request-ci Add this label to start a Jenkins CI on a PR. label Apr 29, 2022
@nodejs-github-bot

This comment was marked as outdated.

@nodejs-github-bot

This comment was marked as outdated.

@RaisinTen
Copy link
Member

Do you know which exception is getting scheduled and causing V8 to return empty Maybes? I tried to run the test without the fix and it's always coming from one of these Check() calls for me:

e->Set(context,
env->errno_string(),
Integer::New(isolate, errorno)).Check();
e->Set(context, env->code_string(), js_code).Check();
e->Set(context, env->syscall_string(), js_syscall).Check();
if (!js_path.IsEmpty())
e->Set(context, env->path_string(), js_path).Check();
if (!js_dest.IsEmpty())
e->Set(context, env->dest_string(), js_dest).Check();
.

@santigimeno
Copy link
MemberAuthor

This is the other exception, which doesn't occur that often, in fact I could try to devise a different test which exercises that path more often:

FATAL ERROR: v8::FromJust Maybe value is Nothing. 1: 0xb57b90 node::Abort() [node] 2: 0xa701b3 node::FatalError(char const*, char const*) [node] 3: 0xd4388a v8::Utils::ReportApiFailure(char const*, char const*) [node] 4: 0xb5bfed node::fs::FileHandle::CloseReq::Resolve() [node] 5: 0xb5c170 [node] 6: 0x1634dbd [node] 7: 0x1639596 [node] 8: 0x164bcd4 [node] 9: 0x1639ee8 uv_run [node] 10: 0xa95e45 node::SpinEventLoop(node::Environment*) [node] 11: 0xc22472 node::worker::Worker::Run() [node] 12: 0xc22a58 [node] 13: 0x7f765d46a609 [/lib/x86_64-linux-gnu/libpthread.so.0] 14: 0x7f765d38f163 clone [/lib/x86_64-linux-gnu/libc.so.6] Aborted 

@santigimeno
Copy link
MemberAuthor

And this is the 3rd one:

node[30432]: ../src/node_file-inl.h:160:node::fs::FSReqPromise<AliasedBufferT>::~FSReqPromise() [with AliasedBufferT = node::AliasedBufferBase<double, v8::Float64Array>]: Assertion `finished_' failed. 1: 0xb57b90 node::Abort() [node] 2: 0xb57c0e [node] 3: 0xb5288a [node] 4: 0xb5e74a node::fs::FSReqAfterScope::~FSReqAfterScope() [node] 5: 0xb5f09e node::fs::AfterOpenFileHandle(uv_fs_s*) [node] 6: 0x1634dbd [node] 7: 0x1639596 [node] 8: 0x164bcd4 [node] 9: 0x1639ee8 uv_run [node] 10: 0xa95e45 node::SpinEventLoop(node::Environment*) [node] 11: 0xc22472 node::worker::Worker::Run() [node] 12: 0xc22a58 [node] 13: 0x7fcbc059f609 [/lib/x86_64-linux-gnu/libpthread.so.0] 14: 0x7fcbc04c4163 clone [/lib/x86_64-linux-gnu/libc.so.6] Aborted 

@santigimeno
Copy link
MemberAuthor

santigimeno commented Apr 30, 2022

@RaisinTen if you want to test it on your side, applying this patch to the current test makes the 2 other errors appear mostly all the time:

diff --git a/test/parallel/test-worker-fshandles-closed.js b/test/parallel/test-worker-fshandles-closed.js index 730b5fc3b1..e3c62bba4a 100644 --- a/test/parallel/test-worker-fshandles-closed.js +++ b/test/parallel/test-worker-fshandles-closed.js @@ -49,7 +49,7 @@ if (isMainThread){} open_close_ok().then(common.mustCall()); - open_close_nok().then(common.mustCall()); + open_close_ok().then(common.mustCall()); parentPort.postMessage('terminate')} 

@RaisinTen
Copy link
Member

Sure, feel free to add more tests for those paths though I don't think it's strictly necessary for this PR. The crash sites are indeed spread over multiple places. However, I was curious to know which JS exception (not C++ crash) caused this. Do worker threads throw an exception if we interact with the isolate during termination? If so, what's the source?

@RaisinTen
Copy link
Member

Tbh, I was curious to know why pending exceptions caused v8::Object::Set() to crash only sometimes because I noticed some unexpected behavior which I thought was a bug in V8 (reported in https://crbug.com/v8/12839) but it seems we do some exception catching magic.

@aduh95aduh95 removed the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label May 2, 2022
@RaisinTen
Copy link
Member

To answer my question, this crashes because of this exception -

returnThrow(ReadOnlyRoots(this).termination_exception());
. #42874 is also trying to fix a crash that happens due to the same reason.

@santigimenosantigimenoforce-pushed the santi/some_filehandle_fixes branch from 260c189 to 2ab9f9aCompareJune 17, 2022 13:13
@santigimenosantigimeno added the request-ci Add this label to start a Jenkins CI on a PR. label Jun 17, 2022
@github-actionsgithub-actionsbot removed the request-ci Add this label to start a Jenkins CI on a PR. label Jun 17, 2022
@nodejs-github-bot
Copy link
Collaborator

@nodejs-github-bot

This comment was marked as duplicate.

@nodejs-github-bot
Copy link
Collaborator

@aduh95aduh95 added the commit-queue Add this label to land a pull request using GitHub Actions. label Jun 18, 2022
@nodejs-github-botnodejs-github-bot added commit-queue-failed An error occurred while landing this pull request using GitHub Actions. and removed commit-queue Add this label to land a pull request using GitHub Actions. labels Jun 18, 2022
@nodejs-github-bot
Copy link
Collaborator

Commit Queue failed
- Loading data for nodejs/node/pull/42910 ✔ Done loading data for nodejs/node/pull/42910 ----------------------------------- PR info ------------------------------------ Title fs: don't end fs promises on Isolate termination (#42910) Author Santiago Gimeno (@santigimeno) Branch santigimeno:santi/some_filehandle_fixes -> nodejs:main Labels c++, fs, author ready, needs-ci Commits 1 - fs: don't end fs promises on Isolate termination Committers 1 - Santiago Gimeno PR-URL: https://github.com/nodejs/node/pull/42910 Fixes: https://github.com/nodejs/node/issues/42829 Reviewed-By: Antoine du Hamel Reviewed-By: Darshan Sen ------------------------------ Generated metadata ------------------------------ PR-URL: https://github.com/nodejs/node/pull/42910 Fixes: https://github.com/nodejs/node/issues/42829 Reviewed-By: Antoine du Hamel Reviewed-By: Darshan Sen -------------------------------------------------------------------------------- ⚠ Commits were pushed since the last review: ⚠ - fs: don't end fs promises on Isolate termination ℹ This PR was created on Fri, 29 Apr 2022 14:06:18 GMT ✔ Approvals: 2 ✔ - Antoine du Hamel (@aduh95) (TSC): https://github.com/nodejs/node/pull/42910#pullrequestreview-958012346 ✔ - Darshan Sen (@RaisinTen) (TSC): https://github.com/nodejs/node/pull/42910#pullrequestreview-962848317 ✔ Last GitHub CI successful ℹ Last Full PR CI on 2022-06-18T00:22:32Z: https://ci.nodejs.org/job/node-test-pull-request/44668/ - Querying data for job/node-test-pull-request/44668/ ✔ Last Jenkins CI successful -------------------------------------------------------------------------------- ✔ Aborted `git node land` session in /home/runner/work/node/node/.ncu
https://github.com/nodejs/node/actions/runs/2519886079

@aduh95aduh95 added commit-queue Add this label to land a pull request using GitHub Actions. and removed commit-queue-failed An error occurred while landing this pull request using GitHub Actions. labels Jun 18, 2022
@nodejs-github-botnodejs-github-bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Jun 18, 2022
@nodejs-github-botnodejs-github-bot merged commit 4c077b0 into nodejs:mainJun 18, 2022
@nodejs-github-bot
Copy link
Collaborator

Landed in 4c077b0

@joyeecheung
Copy link
Member

This has introduced a flake in the CI: #43499 should we revert this?

@santigimeno
Copy link
MemberAuthor

This has introduced a flake in the CI: #43499 should we revert this?

Please, hold on a bit. I'm investigating this and post a fix shortly.

targos pushed a commit that referenced this pull request Jul 12, 2022
This is specially prevalent in the case of having in-progress FileHandle operations in a worker thread while the Worker is exiting. Fixes: #42829 PR-URL: #42910 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Darshan Sen <[email protected]>
@targostargos mentioned this pull request Jul 12, 2022
targos pushed a commit that referenced this pull request Jul 18, 2022
This is specially prevalent in the case of having in-progress FileHandle operations in a worker thread while the Worker is exiting. Fixes: #42829 PR-URL: #42910 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Darshan Sen <[email protected]>
targos pushed a commit that referenced this pull request Jul 31, 2022
This is specially prevalent in the case of having in-progress FileHandle operations in a worker thread while the Worker is exiting. Fixes: #42829 PR-URL: #42910 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Darshan Sen <[email protected]>
@targostargos mentioned this pull request Aug 3, 2022
guangwong pushed a commit to noslate-project/node that referenced this pull request Oct 10, 2022
This is specially prevalent in the case of having in-progress FileHandle operations in a worker thread while the Worker is exiting. Fixes: nodejs/node#42829 PR-URL: nodejs/node#42910 Reviewed-By: Antoine du Hamel <[email protected]> Reviewed-By: Darshan Sen <[email protected]>
Sign up for freeto join this conversation on GitHub. Already have an account? Sign in to comment

Labels

author readyPRs that have at least one approval, no pending requests for changes, and a CI started.c++Issues and PRs that require attention from people who are familiar with C++.fsIssues and PRs related to the fs subsystem / file system.needs-ciPRs that need a full CI run.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Crash in AfterOpenFileHandle

7 participants

@santigimeno@nodejs-github-bot@RaisinTen@aduh95@joyeecheung@addaleax@tniessen