Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segfault in 16.3.0 with promise hooks #39019

Closed
stephenh opened this issue Jun 12, 2021 · 17 comments
Closed

Segfault in 16.3.0 with promise hooks #39019

stephenh opened this issue Jun 12, 2021 · 17 comments
Labels
async_hooks Issues and PRs related to the async hooks subsystem.

Comments

@stephenh
Copy link

stephenh commented Jun 12, 2021

  • Version: v16.3.0
  • Platform:Linux sh12 5.11.0-18-generic #19-Ubuntu SMP Fri May 7 14:22:03 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
  • Subsystem: async_hooks

What steps will reproduce the bug?

I cannot reproduce it outside of our internal codebase yet.

How often does it reproduce? Is there a required condition?

It deterministically reproduces in the test I am running, but I cannot reproduce it outside of that yet

What do you see instead?

A seg fault:

   1   │ PID 457702 received SIGSEGV for address: 0x0
   2   │ /home/stephen/homebound/graphql-service/node_modules/segfault-handler/build/Release/segfault-handler.node(+0x3745)[0x7fde18334745]
   3   │ /lib/x86_64-linux-gnu/libpthread.so.0(+0x141f0)[0x7fde17f971f0]
   4   │ /home/stephen/.asdf/installs/nodejs/16.3.0/bin/node(_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+0x17)[0xd0cfc7]
   5   │ /home/stephen/.asdf/installs/nodejs/16.3.0/bin/node[0xa61a68]
   6   │ /home/stephen/.asdf/installs/nodejs/16.3.0/bin/node[0xd655cb]
   7   │ /home/stephen/.asdf/installs/nodejs/16.3.0/bin/node[0xd66a6c]
   8   │ /home/stephen/.asdf/installs/nodejs/16.3.0/bin/node(_ZN2v88internal21Builtin_HandleApiCallEiPmPNS0_7IsolateE+0x16)[0xd670e6]
   9   │ /home/stephen/.asdf/installs/nodejs/16.3.0/bin/node[0x16148d9]

Additional information

cc'ing @Qard because of the SetPromiseHooks in the above segfault.

Sorry I don't have any useful reproductions yet :-( will keep poking at it.

@gireeshpunathil
Copy link
Member

@stephenh - do you have a core dump produced out of the crash that I can have a look at?

@stephenh
Copy link
Author

core.zip

@gireeshpunathil yep, attached!

@gireeshpunathil
Copy link
Member

(gdb) x/12i 0xD0CFB0
   0xd0cfb0 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_>:	push   rbp
   0xd0cfb1 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+1>:	mov    rbp,rsp
   0xd0cfb4 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+4>:	push   r15
   0xd0cfb6 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+6>:	push   r14
   0xd0cfb8 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+8>:	push   r13
   0xd0cfba <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+10>:	push   r12
   0xd0cfbc <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+12>:	mov    r12,rdi
   0xd0cfbf <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+15>:	push   rbx
   0xd0cfc0 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+16>:	mov    rbx,r8
   0xd0cfc3 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+19>:	sub    rsp,0x18
=> 0xd0cfc7 <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+23>:	mov    rax,QWORD PTR [rdi]
   0xd0cfca <_ZN2v87Context15SetPromiseHooksENS_5LocalINS_8FunctionEEES3_S3_S3_+26>:	and    rax,0xfffffffffffc0000
(gdb) i r rdi
rdi            0x0                 0
(gdb) 

basically, the Context is null. Not sure how this scenario is possible.

/cc @nodejs/v8

@Flarna
Copy link
Member

Flarna commented Jun 13, 2021

There are known issues regarding PromiseHooks in 16.2.0 and 16.3.0. Latest fix was #38912

Above fix is already in master but not on 16.x yet. Could you test with a nightly build?

@Flarna Flarna added the async_hooks Issues and PRs related to the async hooks subsystem. label Jun 13, 2021
@stephenh
Copy link
Author

stephenh commented Jun 13, 2021

@Flarna sure, I just tried a nightly, assuming I did it right, and still got a core dump:

I have the 6/13 nightly:

$ npx node-nightly --version
v17.0.0-nightly20210613174b191f70

Running this test segfaults:

$ npx node-nightly ./node_modules/.bin/jest src/...sometest....test.tsx

 RUNS  src/...sometest...test.tsx

I got this core dump file:

$ ls /tmp/core-node-11-1000-1000-1111527-1623592549 -l
-rw------- 1 stephen stephen 405385216 Jun 13 08:55 /tmp/core-node-11-1000-1000-1111527-1623592549

Which I'm attaching (...er, I'm getting a github error about "not in the list", but I'm uploading a zip file which worked before...still poking at it...)

@stephenh
Copy link
Author

I can't seem to upload either a zip or a tar.gz file, and the error looks kinda weird/not display correctedly, in both firefox and chrome:

image

Not sure how I was able to upload the first one, it just worked...

@gireeshpunathil
Copy link
Member

may be that this issue is already loaded with a heavy core file, and github is capping on size limit?

@stephenh
Copy link
Author

Okay, I've put the core dump in this other repo (which was for reproducing a prior async hooks issue, the one in 16.2.0, not this current issue, I'm just borrowing that repository as a place to shove this file):

https://github.com/stephenh/async-local-storage-repro/blob/main/core-nightly-0613.tar.gz

@Qard
Copy link
Member

Qard commented Jun 14, 2021

This is the corresponding function. I don't see anything jumping out at me about it. 🤔 https://github.com/v8/v8/blob/master/src/api/api.cc#L6314-L6351

@Qard
Copy link
Member

Qard commented Jun 15, 2021

I suspect the issue may have been introduced by #38821. I think it's trying to do a context->SetPromiseHooks(...) when the context is not entered which may result in context->native_context() returning null.

@gireeshpunathil
Copy link
Member

I can attempt a bisect. @stephenh, the reproduce repo that is linked - it has different steps and results, but I could not locate the one that produce the above crash. Can you guide me how do I reproduce the crash?

@stephenh
Copy link
Author

stephenh commented Jun 16, 2021

@gireeshpunathil sorry, I don't have a repro for this one yet :-/

That repository was for reproducing #38821, and I just borrowed it for this issue's coredump.

For #38821, it was failing ~most/all of our tests, so it is was fairly easy to scope down to a few lines of code. This issue fails maybe ~10% of our tests (but fails those tests deterministically, which is at least good), but I haven't had a chance to dig into why.

At first I thought it was b/c of a particularly complex test, but later I noticed it is also segfaulting what I thought was a relatively simple test (we use AsyncLocalStorage within an ORM and the tests are using that + making a handful of SQL calls to a pg database). Which should be easier to pare down, but unfortunately still haven't had a chance to do so.

(...erg, last time we were also able to reproduce this in the ORM's public test suite, but it looks like the public test suite is passing on node 16.3.0, so it's only our internal application that is failing here...)

@karanbirsingh
Copy link

There are known issues regarding PromiseHooks in 16.2.0 and 16.3.0. Latest fix was #38912

Above fix is already in master but not on 16.x yet. Could you test with a nightly build?

Thanks for this note. My team encountered the same Segfault call stack as Stephen when running jest --detectOpenHandles with a snapshot test in a Docker container. We found this issue after making a repro here - but the segfault seems to be fixed with node-nightly. Leaving a comment in case other jest / snapshot users encounter the segfault in 16.3.0.

@gireeshpunathil
Copy link
Member

@karanbirsingh - thanks for the additional info, and the repro repo; unfortunately, I am unable to reproduce in 100 iterations. I always see the test passing.

$ yarn docker:run
$ docker run -t demo-segfault
 PASS  ./sum.test.js
  test
     test (7 ms)

Test Suites: 1 passed, 1 total
Tests:       1 passed, 1 total
Snapshots:   1 passed, 1 total
Time:        0.557 s
Ran all test suites.
Done in 2.84s.
$

any other info, that may be crucial here?

@bengl
Copy link
Member

bengl commented Jun 17, 2021

I am able to reproduce the issue @karanbirsingh has via the repro repo. Here's my branch of that, with some notes. It seems to happen with either node 16.3.0 or nightly, but only sometimes, typically on the first run in a running container. The backtrace is similar (but shorter) to the one provided by @stephenh.

Here are v8 bts:

From @stephenh's core dump
(llnode) v8 bt
 * thread #1: tid = 1111527, 0x0000000000d16eb7 node`v8::Context::SetPromiseHooks(v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>) + 23, name = 'node', stop reason = signal SIGSEGV
  * frame #0: 0x0000000000d16eb7 node`v8::Context::SetPromiseHooks(v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>) + 23
    frame #1: 0x0000000000a69a78 node`node::SetPromiseHooks(v8::FunctionCallbackInfo<v8::Value> const&) + 920
    frame #2: 0x0000000000d6eeab node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) + 1019
    frame #3: 0x0000000000d7035c node`v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) + 172
    frame #4: 0x0000000000d709d6 node`v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) + 22
    frame #5: 0x000000000163f739 node`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 57
    frame #6: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #7: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #8: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #9: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #10: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #11: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #12: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #13: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #14: 0x0000000001684a24 <non-function>
    frame #15: 0x00000000015d61f8 <constructor>
    frame #16: 0x00000000016c8d6c <stub>
    frame #17: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #18: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #19: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #20: 0x00000000016050ff node`Builtins_AsyncFunctionAwaitResolveClosure + 63
    frame #21: 0x000000000168630e <stub>
    frame #22: 0x00000000015f7e00 <stub>
    frame #23: 0x00000000015d6ba3 <entry>
    frame #24: 0x0000000000e6375c node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 1740
    frame #25: 0x0000000000e64613 node`v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*, v8::internal::MaybeHandle<v8::internal::Object>*) + 163
    frame #26: 0x0000000000e8c1f6 node`v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) (.part.49) + 182
    frame #27: 0x0000000000e8c5a0 node`v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) + 48
    frame #28: 0x0000000000d6eeab node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) + 1019
    frame #29: 0x0000000000d7035c node`v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) + 172
    frame #30: 0x0000000000d709d6 node`v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) + 22
    frame #31: 0x000000000163f739 node`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 57
    frame #32: 0x00000000015d89eb node`Builtins_InterpreterEntryTrampoline + 203
    frame #33: 0x00000000015d6c5b <internal>
    frame #34: 0x00000000015d69e3 <entry>
    frame #35: 0x0000000000e63255 node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 453
    frame #36: 0x0000000000e640cf node`v8::internal::Execution::Call(v8::internal::Isolate*, v8::internal::Handle<v8::internal::Object>, v8::internal::Handle<v8::internal::Object>, int, v8::internal::Handle<v8::internal::Object>*) + 95
    frame #37: 0x0000000000d270f3 node`v8::Function::Call(v8::Local<v8::Context>, v8::Local<v8::Value>, int, v8::Local<v8::Value>*) + 307
    frame #38: 0x0000000000a60dba node`node::InternalCallbackScope::Close() + 1306
    frame #39: 0x0000000000a61415 node`node::InternalMakeCallback(node::Environment*, v8::Local<v8::Object>, v8::Local<v8::Object>, v8::Local<v8::Function>, int, v8::Local<v8::Value>*, node::async_context) + 677
    frame #40: 0x0000000000a71099 node`node::AsyncWrap::MakeCallback(v8::Local<v8::Function>, int, v8::Local<v8::Value>*) + 121
    frame #41: 0x0000000000bf98f8 node`node::StreamBase::CallJSOnreadMethod(long, v8::Local<v8::ArrayBuffer>, unsigned long, node::StreamBase::StreamBaseJSChecks) (.constprop.133) + 168
    frame #42: 0x0000000000bfc9e6 node`node::EmitToJSStreamListener::OnStreamRead(long, uv_buf_t const&) + 886
    frame #43: 0x0000000000c06cc8 node`node::LibuvStreamWrap::OnUvRead(long, uv_buf_t const*) + 120
    frame #44: 0x00000000015c6127 node`uv__read(stream=0x00000000055fa8a0) at stream.c:1239:7
    frame #45: 0x00000000015c6ae0 node`uv__stream_io(loop=<unavailable>, w=0x00000000055fa928, events=1) at stream.c:1306:5
    frame #46: 0x00000000015cd5c5 node`uv__io_poll at linux-core.c:462:11
    frame #47: 0x00000000015bb168 node`uv_run(loop=0x000000000483b280, mode=UV_RUN_DEFAULT) at core.c:385:5
    frame #48: 0x0000000000a61f25 node`node::SpinEventLoop(node::Environment*) + 309
    frame #49: 0x0000000000b61d57 node`node::NodeMainInstance::Run(node::EnvSerializeInfo const*) + 407
    frame #50: 0x0000000000ae7c02 node`node::Start(int, char**) + 546
From @karanbirsingh's repro
(llnode) v8 bt
 * thread #1: tid = 83, 0x0000000000d0cfc7 node`v8::Context::SetPromiseHooks(v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>) + 23, name = 'node', stop reason = signal SIGSEGV: invalid address (fault address: 0x0)
  * frame #0: 0x0000000000d0cfc7 node`v8::Context::SetPromiseHooks(v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>, v8::Local<v8::Function>) + 23
    frame #1: 0x0000000000a61a68 node`node::SetPromiseHooks(v8::FunctionCallbackInfo<v8::Value> const&) + 920
    frame #2: 0x0000000000d655cb node`v8::internal::MaybeHandle<v8::internal::Object> v8::internal::(anonymous namespace)::HandleApiCallHelper<false>(v8::internal::Isolate*, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::HeapObject>, v8::internal::Handle<v8::internal::FunctionTemplateInfo>, v8::internal::Handle<v8::internal::Object>, v8::internal::BuiltinArguments) + 1019
    frame #3: 0x0000000000d66a6c node`v8::internal::Builtin_Impl_HandleApiCall(v8::internal::BuiltinArguments, v8::internal::Isolate*) + 172
    frame #4: 0x0000000000d670e6 node`v8::internal::Builtin_HandleApiCall(int, unsigned long*, v8::internal::Isolate*) + 22
    frame #5: 0x00000000016148d9 node`Builtins_CEntry_Return1_DontSaveFPRegs_ArgvOnStack_BuiltinExit + 57
    frame #6: 0x00000000015ad385 node`Builtins_InterpreterEntryTrampoline + 197
    frame #7: 0x00000000015cc6cd <stub>
    frame #8: 0x00000000015ab543 <entry>
    frame #9: 0x0000000000e6250a node`v8::internal::(anonymous namespace)::Invoke(v8::internal::Isolate*, v8::internal::(anonymous namespace)::InvokeParams const&) + 1738
    frame #10: 0x0000000000e633c3 node`v8::internal::Execution::TryRunMicrotasks(v8::internal::Isolate*, v8::internal::MicrotaskQueue*, v8::internal::MaybeHandle<v8::internal::Object>*) + 163
    frame #11: 0x0000000000e8a816 node`v8::internal::MicrotaskQueue::RunMicrotasks(v8::internal::Isolate*) (.part.50) + 182
    frame #12: 0x0000000000e8abc0 node`v8::internal::MicrotaskQueue::PerformCheckpoint(v8::Isolate*) + 48
    frame #13: 0x0000000000a589c1 node`node::InternalCallbackScope::Close() + 289
    frame #14: 0x0000000000a590e1 node`node::InternalCallbackScope::~InternalCallbackScope() + 17
    frame #15: 0x0000000000a90a24 node`node::Environment::RunTimers(uv_timer_s*) + 756
    frame #16: 0x000000000158b495 node`uv__run_timers(loop=0x0000000004837dc0) at timer.c:178
    frame #17: 0x000000000158f9f5 node`uv_run(loop=0x0000000004837dc0, mode=UV_RUN_DEFAULT) at core.c:376
    frame #18: 0x0000000000a59f25 node`node::SpinEventLoop(node::Environment*) + 309
    frame #19: 0x0000000000b59bd7 node`node::NodeMainInstance::Run(node::EnvSerializeInfo const*) + 407
    frame #20: 0x0000000000adfaa2 node`node::Start(int, char**) + 546
    frame #21: 0x00007ffff6ca1bf7 libc.so.6`__libc_start_main + 231
    frame #22: 0x0000000000a57d6c node`_start + 41

@bengl
Copy link
Member

bengl commented Jun 19, 2021

I was able to narrow this down to the following snippet to reproduce. It works for me on both Linux and macOS, with v16.3.0.

// flags: --expose-gc
const asyncHooks = require('async_hooks');
const vm = require('vm');

const hook = asyncHooks.createHook({ init() {} }).enable();
vm.createContext();
gc();
hook.disable();

It looks like weak references to the contexts are still being held in in the contexts_ vector in env->async_hooks() after they've been garbage collected. The handles end up being empty. RemoveContext is called in the ContextifyContext destructor, but looks like in this repro case the context can't be found in vector. Right now it's checking by comparing equality of handles. Maybe there's a more correct approach?

For reference, here are AddContext and RemoveContext:

node/src/env-inl.h

Lines 234 to 267 in cd43073

inline void AsyncHooks::AddContext(v8::Local<v8::Context> ctx) {
ctx->SetPromiseHooks(
js_promise_hooks_[0].IsEmpty() ?
v8::Local<v8::Function>() :
PersistentToLocal::Strong(js_promise_hooks_[0]),
js_promise_hooks_[1].IsEmpty() ?
v8::Local<v8::Function>() :
PersistentToLocal::Strong(js_promise_hooks_[1]),
js_promise_hooks_[2].IsEmpty() ?
v8::Local<v8::Function>() :
PersistentToLocal::Strong(js_promise_hooks_[2]),
js_promise_hooks_[3].IsEmpty() ?
v8::Local<v8::Function>() :
PersistentToLocal::Strong(js_promise_hooks_[3]));
size_t id = contexts_.size();
contexts_.resize(id + 1);
contexts_[id].Reset(env()->isolate(), ctx);
contexts_[id].SetWeak();
}
inline void AsyncHooks::RemoveContext(v8::Local<v8::Context> ctx) {
v8::Isolate* isolate = env()->isolate();
v8::HandleScope handle_scope(isolate);
for (auto it = contexts_.begin(); it != contexts_.end(); it++) {
v8::Local<v8::Context> saved_context =
PersistentToLocal::Weak(env()->isolate(), *it);
if (saved_context == ctx) {
it->Reset();
contexts_.erase(it);
break;
}
}
}

And here is SetJSPromiseHooks, which is where the segfault is occuring:

node/src/env-inl.h

Lines 98 to 110 in cd43073

inline void AsyncHooks::SetJSPromiseHooks(v8::Local<v8::Function> init,
v8::Local<v8::Function> before,
v8::Local<v8::Function> after,
v8::Local<v8::Function> resolve) {
js_promise_hooks_[0].Reset(env()->isolate(), init);
js_promise_hooks_[1].Reset(env()->isolate(), before);
js_promise_hooks_[2].Reset(env()->isolate(), after);
js_promise_hooks_[3].Reset(env()->isolate(), resolve);
for (auto it = contexts_.begin(); it != contexts_.end(); it++) {
PersistentToLocal::Weak(env()->isolate(), *it)
->SetPromiseHooks(init, before, after, resolve);
}
}

This code was introduced by #38821.

@Qard
Copy link
Member

Qard commented Jun 19, 2021

Seems very strange to me that the context would be collected before the ContextifyScript destructor. 🤔

bengl added a commit to bengl/node that referenced this issue Jun 19, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019
bengl added a commit to bengl/node that referenced this issue Jun 19, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019
bengl added a commit to bengl/node that referenced this issue Jun 19, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019
bengl added a commit to bengl/node that referenced this issue Jun 19, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019
bengl added a commit to bengl/node that referenced this issue Jun 19, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019
@bengl bengl closed this as completed in 0e8bd79 Jun 22, 2021
danielleadams pushed a commit that referenced this issue Jun 22, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: #39019

PR-URL: #39095
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Qard pushed a commit to Qard/node that referenced this issue Jun 22, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019

PR-URL: nodejs#39095
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Qard pushed a commit to Qard/node that referenced this issue Jul 19, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019

PR-URL: nodejs#39095
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Qard pushed a commit to Qard/node that referenced this issue Jul 21, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019

PR-URL: nodejs#39095
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Qard pushed a commit to Qard/node that referenced this issue Jul 21, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019

PR-URL: nodejs#39095
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Qard pushed a commit to Qard/node that referenced this issue Jul 21, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019

PR-URL: nodejs#39095
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Qard pushed a commit to Qard/node that referenced this issue Aug 1, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019

PR-URL: nodejs#39095
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
targos pushed a commit that referenced this issue Aug 3, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: #39019

PR-URL: #39095
Backport-PR-URL: #38577
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
BethGriggs pushed a commit that referenced this issue Aug 12, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: #39019

PR-URL: #39095
Backport-PR-URL: #38577
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
MylesBorins pushed a commit that referenced this issue Aug 31, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: #39019

PR-URL: #39095
Backport-PR-URL: #38577
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
foxxyz pushed a commit to foxxyz/node that referenced this issue Oct 18, 2021
This way we don't end up attempting to SetPromiseHooks on contexts that
have already been collected.

Fixes: nodejs#39019

PR-URL: nodejs#39095
Backport-PR-URL: nodejs#38577
Reviewed-By: Stephen Belanger <admin@stephenbelanger.com>
Reviewed-By: Gerhard Stöbich <deb2001-github@yahoo.de>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>
Reviewed-By: Andrey Pechkurov <apechkurov@gmail.com>
Reviewed-By: Danielle Adams <adamzdanielle@gmail.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
async_hooks Issues and PRs related to the async hooks subsystem.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants