-
Notifications
You must be signed in to change notification settings - Fork 30k
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
EXC_BAD_ACCESS: Environment::GetCurrent returns nullptr in node::EmitAsyncDestroy #27218
Comments
Possibly. What is the reason for that? It's unusual enough that something is probably amiss. |
I think this might be an N-API bug, or at least something that could be partially addressed there. In This may apply to the other |
Here's a trace back if it's of any use. I'm trying to find a minimal repro, but it's proving elusive. Traceback
|
Anna's explanation sounds plausible. I thought you were still using NAN but I see there's also a templated instance that uses n-api.
I think the design flaw here is that Just bailing out when there's no active context is probably not a proper fix because it means you lose events. Maybe that's acceptable as a temporary workaround, I don't know. Having said all that, are you sure |
This can be necessary for being able to call the function when no JS Context is on the stack, e.g. during GC. Refs: nodejs#27218
Allow the function to be called during GC, which is a common use case. Fixes: nodejs#27218
Fwiw, I’ve double-checked, and yes, during a regular GC run it’s an empty handle. |
Thanks @bnoordhuis and @addaleax,
Yes, I'm mid-conversion to N-API. After I hit this issue I just continued converting class by class from NAN to N-API thinking the bug could be from my NAN code (which was also using libuv directly), but the bug still manifests in my N-API branch (which I haven't updated yet).
Thanks for explaining. Just to clarify: this isn't a "disallowed" usage?
These events are the
Thanks for checking @addaleax. @addaleax I see your PR addressing this issue. I will try it out soon. If it does fix my issue, what is the backport policy? Will your change only be applied to Node releases, or will it land in current non-EOL releases? |
This can be necessary for being able to call the function when no JS Context is on the stack, e.g. during GC. Refs: #27218 PR-URL: #27255 Fixes: #27218 Reviewed-By: Ben Noordhuis <info@bnoordhuis.nl> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Michael Dawson <michael_dawson@ca.ibm.com>
In case anyone needs to work around this issue in older releases of Node, here is how I did it in node-webrtc: instead of |
Hi, I'm porting my Native Addon from NAN to N-API and I've hit an issue. I have some objects which make use of node-addon-api's Napi::ObjectWrap and Napi::AsyncContext classes; however, I'm raising an issue here, because I'm not sure these are specific to node-addon-api. I actually hit a similar issue with NAN a while back (nodejs/nan#772).
What I see is that the call to
Environment::GetCurrent(isolate)
innode::EmitAsyncDestroy
returnsnullptr
. I believe that is because this call toisolate->GetCurrentContext()
returnsnullptr
. This results in anEXC_BAD_ACCESS
.You can see how I worked around this issue (starting with Node 9) when using NAN, although 1. it's probably incorrect and 2. it relies on v8 APIs that I don't want to use when porting to N-API.
Is this a bug? Am I doing something wrong? Thanks in advance!
The text was updated successfully, but these errors were encountered: