EXC_BAD_ACCESS in node::EmitAsyncDestroy #772
Comments
|
I have a much smaller repro example: https://github.com/markandrus/nan-asyncresource-bug |
|
@ofrobots Any idea what could be up with this? |
|
I built Node 9.8.0 locally and got a more detailed backtrace: EDIT: Seems like |
|
I ran out of time today, and couldn't take a deeper look; but looking at just the stack, I don't think it is safe to 'do JS or VM operations' from a weak callback (i.e. from GC). GC callbacks do not guarantee that a V8 context is attached when the weak callback is called. |
|
I thought something similar based on the stack trace, but then the documentation needs updating, since it cannot be used with |
So the weak callback here is the "pending phantom callbacks" invoked by --- nan.h 2018-05-16 10:24:36.000000000 -0700
+++ nan.h 2018-05-16 10:24:45.000000000 -0700
@@ -510,7 +510,9 @@
~AsyncResource() {
#if NODE_MODULE_VERSION >= NODE_9_0_MODULE_VERSION
v8::Isolate* isolate = v8::Isolate::GetCurrent();
- node::EmitAsyncDestroy(isolate, context);
+ if (!isolate->GetCurrentContext().IsEmpty()) {
+ node::EmitAsyncDestroy(isolate, context);
+ }
#endif
}In my testing, this seems to work, although I haven't looked to see if it passes existing nodejs/nan tests. EDIT: I don't see issues with nodejs/nan tests; however, they weren't testing instances of both ObjectWrap and AsyncResource anyway. |
|
@markandrus that's probably not the right fix – it would work around the issue, but you would potentially leak if there is anything in the application that is keeping track of async resources. You're never calling the destroy hook on the resource in these cases. My suggestion would be to defer this work to a microtask you post to run later. More elegant solutions might be possible if somehow you can decouple the async resource from the lifetime of your
You're right. This might be a common gotcha people run into, and the documentation is worth updating, or perhaps this indicates that there might be a missing abstraction needed here. I'll try to do this once I have some bandwidth available to think. Feel free to go ahead if you have time / motivation, however. |
|
@ofrobots thanks for your response. When you say
Do you mean the work of calling
I think others may run into this if/when they start heeding the deprecation warning on
Hmm, I will think on it. Maybe I could have some |
|
I have a PR that demonstrates decoupling the ObjectWrap from the AsyncResource here: markandrus/nan-asyncresource-bug#1 |
Hi,
I'm occasionally hitting an error in the destructor for AsyncResource. Sorry I don't have a minimal reproduction example yet. I've just started hitting this since migrating js-platform/node-webrtc to AsyncResource. I've got a graph of objects, some of them just ObjectWrap instances and some of the ObjectWrap + AsyncResource instances. The AsyncResource instances wrap libuv's
uv_default_loop(). I callRefwhen constructing these andUnrefin theuv_close_cb. The graph looks like this:In my tests, I'm only seeing the issues in
~MediaStreamTrack, and then, only occasionally. I'm also not seeing the destructor fire twice or anything like that. Interestingly, if I comment out thenode::EmitAsyncDestroycall, I don't see crashes. I'm using Node v9.8.0.I'm opening this in case there's something obvious here I'm missing. The async hooks functionality is very new to me. If it's not obvious, I'll try to create a minimal repro.
Thanks,
Mark
The text was updated successfully, but these errors were encountered: