uv_async_t让Node.js脚本停止运行

在公司搬砖给Node.js写C++插件的时候遇到了一个BUG:在为Node.js导出的C++类中,如果存储了uv_async_t对象,会让一些Node.js的async/await操作不能正常工作。套上async/await,代码执行到C++代码通过回调函数异步返回给JS数据之后,脚本就停止工作了。

C++部分的代码大致是这样的:

#include <nan.h>
#include <memory>
#include <thread>
#include <vector>

// simple wrapper for uv_async_t
class uvAsyncEvent
{
public:
    uvAsyncEvent(void* context, uv_async_cb callback)
    {
        m_pAsyncHandle.reset(new uv_async_t());
        m_pAsyncHandle->data = context;
        uv_async_init(uv_default_loop(), m_pAsyncHandle.get(), callback);
    }
    ~uvAsyncEvent()
    {
    }
    void* GetContext() const
    {
        return m_pAsyncHandle->data;
    }
    void Notify()
    {
        uv_async_send(m_pAsyncHandle.get());
    }

private:
    struct Deleter
    {
        void operator()(uv_async_t* asyncEvent) const
        {
            if (asyncEvent)
            {
                uv_close((uv_handle_t*)asyncEvent, Deleter::uvCloseCallback);
            }
        }

        static void uvCloseCallback(uv_handle_t* handle)
        {
            delete (uv_async_t*)handle;
        }
    };
    std::unique_ptr<uv_async_t, Deleter> m_pAsyncHandle;
};

// a c++ class exported to Node.js which holds uv_async_t handles
class Hang
    : public Nan::ObjectWrap
{
public:
    static NAN_MODULE_INIT(Init)
    {
        v8::Local<v8::FunctionTemplate> tpl = Nan::New<v8::FunctionTemplate>(New);
        tpl->SetClassName(Nan::New("Hang").ToLocalChecked());
        tpl->InstanceTemplate()->SetInternalFieldCount(1);

        Nan::SetPrototypeMethod(tpl, "start", Start);
        Nan::SetPrototypeMethod(tpl, "stop", Stop);
        Nan::SetPrototypeMethod(tpl, "setCallback", SetCallback);

        constructor.Reset(Nan::GetFunction(tpl).ToLocalChecked());

        Nan::Set(target, Nan::New("Hang").ToLocalChecked(), Nan::GetFunction(tpl).ToLocalChecked());
    }

private:
    Hang()
        : m_pEvent(std::make_unique<uvAsyncEvent>(this, asyncCallback)) // async/await hangs
        , m_bRunning(true)
    {
    }
public:
    ~Hang()
    {
    }

    static NAN_METHOD(New)
    {
        if (info.IsConstructCall()) {
            // Invoked as constructor: `new Hang(...)`
            Hang* obj = new Hang();
            obj->Wrap(info.This());

            info.GetReturnValue().Set(info.This());

            v8::Local<v8::Object> context = v8::Local<v8::Object>::Cast(info[0]);
        }
        else {
            // Invoked as plain function `Hang(...)`, turn into construct call.
            const int argc = 1;
            v8::Local<v8::Value> argv[argc] = { info[0] };
            v8::Local<v8::Function> cons = Nan::New(constructor);
            v8::Local<v8::Object> result =
                Nan::NewInstance(cons, argc, argv).ToLocalChecked();
            info.GetReturnValue().Set(result);
        }
    }

    static NAN_METHOD(SetCallback)
    {
        Hang* obj = ObjectWrap::Unwrap<Hang>(info.Holder());

        if (!info[0]->IsFunction())
        {
            Nan::ThrowTypeError("arg 1 is not function");
            return;
        }

        obj->m_evCallback.reset(new Nan::Callback(info[0].As<v8::Function>()));
    }

    static NAN_METHOD(Start)
    {
        Hang* obj = ObjectWrap::Unwrap<Hang>(info.Holder());

        obj->m_bRunning = true;

        struct ThreadRunner
        {
            ThreadRunner(Hang& h)
                : m_obj(h)
            {
            }

            // Run
            void operator()()
            {
                while (m_obj.m_bRunning) {
                    std::this_thread::sleep_for(std::chrono::milliseconds(1000));
                    m_obj.m_pEvent->Notify();
                }
            }
        private:
            Hang& m_obj;
        };

        if (!obj->m_workThread)
        {
            obj->m_workThread = std::make_unique<std::thread>(ThreadRunner(*obj));
        }

    }

    static NAN_METHOD(Stop)
    {
        Hang* obj = ObjectWrap::Unwrap<Hang>(info.Holder());

        obj->m_bRunning = false;
        if (obj->m_workThread)
        {
            obj->m_workThread->join();
            obj->m_workThread.reset();
        }

        obj->m_pEvent.reset();
    }

private:
    static void asyncCallback(uv_async_t* handle)
    {
        Hang* pThis = (Hang*)handle->data;
        Nan::HandleScope scope;

        auto ret = Nan::New("async callback").ToLocalChecked();

        v8::Local<v8::Value> argv[] = { ret };

        Nan::Call(*pThis->m_evCallback, 1, argv);

    }

private:
    std::unique_ptr<uvAsyncEvent> m_pEvent;
    std::unique_ptr<Nan::Callback> m_evCallback;

    std::unique_ptr<std::thread> m_workThread;
    bool m_bRunning;

private:
    static Nan::Persistent<v8::Function> constructor;
};
Nan::Persistent<v8::Function> Hang::constructor;

// an asynchronous function for test
NAN_METHOD(testAsync)
{
    class Worker : public Nan::AsyncWorker
    {
    public:
        Worker(Nan::Callback* callbk)
            : Nan::AsyncWorker(callbk)
        {
        }

        void Execute() override
        {
            std::this_thread::sleep_for(std::chrono::milliseconds(100));
        }

        void HandleOKCallback() override
        {
            Nan::HandleScope scope;

            int argc = 1;
            std::unique_ptr<v8::Local<v8::Value>[]> argv(new v8::Local<v8::Value>[argc]());

            argv[0] = Nan::New("async task result").ToLocalChecked();

            Nan::Call(*callback, argc, argv.get());
        }
    };

    Nan::Callback* callbk = new Nan::Callback(Nan::To<v8::Function>(info[0]).ToLocalChecked());

    Worker* pWorker = new Worker(callbk);
    Nan::AsyncQueueWorker(pWorker);
}

NAN_MODULE_INIT(InitAll) 
{
    Hang::Init(target);
    Nan::SetMethod(target, "testAsync", testAsync);
}

NODE_MODULE(hang, InitAll)

用来测试的脚本:

const { Hang, testAsync } = require('./build/Release/hang');
const { EventEmitter } = require('events');

let h = new Hang();

// calling start method or not does not affect the problem
// h.start();

function doTestAsync() {
  return new Promise((resolve, reject) => {
    testAsync((data) => {
      // This line of code got executed without any problems
      // after 100ms of the function call(according to the C++ code)
      console.log(data);
      resolve(data);
    });
  });
}

function doSetTimeoutAsync() {
  return new Promise((resolve, reject) => {
    setTimeout(() => {
      let data = 'timeout async';
      console.log(data);
      resolve(data);
    }, 100)
  });
}

// this is ok
//testAsync((data) => {
//    console.log(data);
//});

async function testHang() {
  let asyncRet = await doSetTimeoutAsync();

  // no problem
  console.log("after async call1");
  let asyncRet2 = await doTestAsync();

  // async/await operation blocks due to the creation of "hang"
  // I paused the execution via the debugger, then continue, 
  // Dramatically this line gets executed
  console.log("after async call2");
  let asyncRet3 = await doTestAsync();
  console.log("after async call3");
  let asyncRet4 = await doTestAsync();
  console.log("after async call4");

  h.stop();
}


testHang();

背景和BUG表现

公司搬砖的项目里,要建立一个TCP长连接,用于与服务端之间通信和保持在线状态。通常情况下会单独启动一个线程用来维护连接,现在要把从服务端接收到的数据传给JS,一个很明显的思路是在工作线程里调用uv_async_send来通知主线程(能调用V8的API的线程)有数据传过来。

代码本身是简化后的模型。C++模块导出了一个Hang类和一个testAsync函数,Hang类对应的C++类管理了一个uv_async_t对象,testAsync函数使用了Nan::AsyncWorker用于测试Node.js的异步调用。

发生的问题是:直接通过命令行运行脚本,测试脚本会卡在调用doTestAsync之后,after async call2不会被输出出来。在vscode中启用调试模式时得到的结果也一样。程序的输出是这样的:

timeout async
after async call1
async task result

诡异的是,在vscode中把脚本暂停,脚本成功中断在了Node.js内部的代码里,然后继续运行,后面的输出居然输出了出来。然后脚本继续卡在第二次调用doTestAsync之后。如此暂停和继续运行,测试脚本居然能一路跑下去。

如果把断点停在testAsync提供的回调函数里,会发现程序走过resolve(data)之后就不能继续运行了。

把脚本本身改写成回调金字塔的样式,就像下面的代码一样,也是没有问题的。但是这样真的是太丑了,而且async/await是官方推崇的方式,总算能彻底解决回调金字塔地狱的问题,因为出现了这状况丫的还得改回去……

testAsync((data) => {
  console.log(data);
  console.log("after async call2");
  testAsync((data) => {
    console.log(data);
    console.log("after async call3");
    testAsync((data) => {
      console.log(data);
      console.log("after async call4");
    });
  });
});

尝试解决

首先用二分法找问题原因,逐个排查最近的修改,发现去掉了创建uv_async_t对象的代码,这个问题就不再出现了。

于是整理了下代码,写了个最小的可以必现这个问题的示例。信心满满地向Node.js提交了个issue,然后这个issue一小时后被项目管理者打入了nodejs/help的冷宫,而且没人回答我提出的问题。

既然没有人愿意回答我的问题,那就自己干!

不管怎么说先build个Debug版本的Node.js程序,Release版本经过优化,找错没有那么容易。签出代码库,按照vcbuild.bat的指示来构建,好了,Debug版的Node.js程序有了。因为ABI的问题,又手动建了个vcxproj项目把刚才的c++代码链接到了debug版生成出来的node.lib上。

然后开始调试。先找下Promise是在哪里实现的,Node.js中用JS写的实现都是放在lib目录下。在这个目录下搜索Promise字样,无果。然后在C++代码里继续搜,发现v8.h中声明了一个Promise类。Promise类里面声明了个Resolve方法。于是抱着试试看的心态在这个方法的实现(在deps/v8/src/api.cc)里加了断点。然后在vs的调试选项里面让Debug版的Node.js进程执行我们的测试脚本,脚本照样还是卡住了,api.cc里面的断点没有进去,看来找的Promise的实现的位置不对。

继续找Promise的实现,看到Promise类的声明里有个PromiseState枚举类型,应该是用来表示Promise对象当前的状态的,心想v8脚本引擎的内外应该都用同一种类型,用”查找所有引用”找了一下,原来v8脚本引擎内部还有个v8::internal::JSPromise类(在deps/v8/src/objects/js-promise.h里)。F12进去,看到了这样的代码,在deps/v8/src/objects.cc里面,这个应该是我们要找的Promise.resolve的实现了:

Handle<Object> JSPromise::Fulfill(Handle<JSPromise> promise,
                                  Handle<Object> value) {
  ...
  // 6. Set promise.[[PromiseState]] to "fulfilled".
  promise->set_status(Promise::kFulfilled);

  // 7. Return TriggerPromiseReactions(reactions, value).
  return TriggerPromiseReactions(isolate, reactions, value,
                                 PromiseReaction::kFulfill);
}

// static
MaybeHandle<Object> JSPromise::Resolve(Handle<JSPromise> promise,
                                       Handle<Object> resolution) {
  Isolate* const isolate = promise->GetIsolate();

  isolate->RunPromiseHook(PromiseHookType::kResolve, promise,
                          isolate->factory()->undefined_value());

  ...

  // 7. If Type(resolution) is not Object, then
  if (!resolution->IsJSReceiver()) {
    // a. Return FulfillPromise(promise, resolution).
    return Fulfill(promise, resolution);
  }

  ...

  // 10. Let thenAction be then.[[Value]].
  // 11. If IsCallable(thenAction) is false, then
  if (!then_action->IsCallable()) {
    // a. Return FulfillPromise(promise, resolution).
    return Fulfill(promise, resolution);
  }

  // 12. Perform EnqueueJob("PromiseJobs", PromiseResolveThenableJob,
  //                        «promise, resolution, thenAction»).
  Handle<PromiseResolveThenableJobTask> task =
      isolate->factory()->NewPromiseResolveThenableJobTask(
          promise, Handle<JSReceiver>::cast(then_action),
          Handle<JSReceiver>::cast(resolution), isolate->native_context());
  if (isolate->debug()->is_active() && resolution->IsJSPromise()) {
    // Mark the dependency of the new {promise} on the {resolution}.
    Object::SetProperty(resolution,
                        isolate->factory()->promise_handled_by_symbol(),
                        promise, LanguageMode::kStrict)
        .Check();
  }
  isolate->EnqueueMicrotask(task);

  // 13. Return undefined.
  return isolate->factory()->undefined_value();
}

在这个函数里加了断点,重新调试。发现在程序卡住之前,Node.js居然没有在JSPromise这里中断!甚至在after async call1输出之前,Node.js进程也没中断在刚才在objects.cc中加的断点上。

如果换一种调用JS脚本的方式:在shell模式下运行Node.js,输入命令require('./hang.js')调用脚本,在JSPromise里加的断点生效了,但是程序之后卡住的时候,仍然没进到加的断点上。

两种运行脚本的方式得到不同结果的原因,大概是在命令参数里直接运行脚本的时候,Node.js把脚本的JS代码包括Promise操作全都JIT掉了,JSPromise里面的那些代码根本没有用。

看来这个问题和Promise的实现是没有关系的。至于还有什么其它原因实在是百思不得其解。

转机

问题解决

这个问题拖了将近一周的时间,直到有一天想这个问题的时候拖了下控制台窗口,改变了下Node.js控制台窗口的大小。改变了窗口大小之后,await后面的语句居然被执行了!

期待的结果出现了,赶紧分析下到底发生了什么让结果是对的。再次打开Node.js项目里编译生成的node.sln,用我们的debug版的Node.js启动测试脚本,脚本毫无悬念地卡死。这时候在VS调试器里暂停node.exe的运行,看到主线程中断在了下面的位置:

可以看到Node.js调用了Windows的IOCP。一直等待的情况下,只有IOCP管理的HANDLE对应的IO操作完成或者用PostQueuedCompletionStatus直接向IOCP对象发消息,IOCP的等待操作才会退出。再看一下node.exe调用GetQueuedCompletionStatusEx传进去的超时时间是多少,现在这个状态下这个值是-1。所以说程序卡死的原因是一直在等待一个IOCP事件传过来。然而尝试修改前面的timeout数值,改成不是一直等待,重新编译代码,卡死的问题仍然存在。

GetQueuedCompletionStatusEx的下一行加个断点,然后让node.exe继续跑下去。这之后拖一下控制台窗口,继续单步跟下去,可以看到IOCP消息对应的libuv消息(uv_req_t)类型是UV_SIGNAL_REQ。继续跟到循环结束走到下一轮循环,单步调试到uv_process_signal_req的时候(在uv_process_reqs里面),可以看到信号的编号是28。编号为28的信号是什么信号?查了下是SIGWINCH,在控制台窗口大小发生改变时,操作系统会向对应的进程发送这个信号。不管这么多,继续单步调试跑到下面signal_wrap.cc的代码时,代码走过wrap->MakeCallback这一行之后,await后面的JS代码要输出的东西输出到了屏幕上。

  static void OnSignal(uv_signal_t* handle, int signum) {
    SignalWrap* wrap = ContainerOf(&SignalWrap::handle_, handle);
    Environment* env = wrap->env();
    HandleScope handle_scope(env->isolate());
    Context::Scope context_scope(env->context());

    Local<Value> arg = Integer::New(env->isolate(), signum);
    wrap->MakeCallback(env->onsignal_string(), 1, &arg);
  }

所以这个MakeCallback到底做了什么?看代码可以知道SignalWrap也是向JS环境导出的一个类,在JS端的名字叫Signal。在node项目的lib目录下狂搜,找到了与SIGWINCH信号相关的几个处理函数,但是这些函数和执行当前要继续执行的JS代码都没有任何关系。所以可能是C++代码的问题?
换一种思路来找代码能正常运行的原因。既然控制台都有输出,在Windows下向控制台窗口输出,最终都会调用kernel32.dll导出的WriteConsole函数。又因为涉及到字符串的函数Windows都会提供分别处理char*wchar_t*的两种函数,所以需要加两个断点,按Ctrl+B打开添加断点窗口,手动加上这两个断点:

  {,,kernel32.dll}WriteConsoleA
  {,,kernel32.dll}WriteConsoleW

在启用这两个断点调试的情况下去单步调试MakeCallback方法的实现,最终锁定到了这一行C++代码:

代码中断在env_->tick_callback_function()->Call(process, 0, nullptr).IsEmpty()这一行时,让代码继续运行,node进程就会立刻中断在kernel32.dll导出的WriteConsoleW函数上。看函数的名字tick_callback_function,这个应该就是用来执行等待运行的JS代码的相关的函数,也就是测试脚本里await之后的部分。

所以结论是:拖动控制台窗口能让async/await继续运行,完全是个副作用。原因只不过是Node.js要运行操作系统信号相关的处理函数的时候,顺带会把等待执行的JS代码拎过来也执行一下而已。鬼使神差地就让脚本按预期的方式工作了。至于为什么新建uv_async_t对象就会让Node.js陷入无限等待IOCP消息的状态,这个我实在是无力去追查。

SIGWINCH信号是如何在windows下模拟出来的

Windows本身是不支持SIGWINCH信号的,Node.js(libuv)用启动监听线程监听控制台窗口大小变化的方法模拟了这个信号。窗口大小变化的消息本身是用PostQueuedCompletionStatus直接向主线程IOCP发消息发过去的。要验证可以Ctrl+B手动加个断点{,,kernelbase.dll}PostQueuedCompletionStatus,然后拖动控制台窗口,程序就会中断在监听控制台窗口的线程里面。

解决办法

既然系统向Node.js进程发送SIGWINCH信号会迫使Node.js去运行下个事件循环需要执行的JS代码,那么解决方法也就出来了。

方法是:在测试脚本前面加个定时器,向当前Node.js进程不停地发送SIGWINCH信号,脚本就能继续跑下去直到结束:

setInterval(() => {
    process.emit('SIGWINCH');
}, 100);

这个解决方法实在是过于草生(中日双语),我始终认为这是Node.js的BUG,应该在事件循环处于空闲的状态时就去处理等待执行的JS代码,然而官方不理,当然原因也可能是真的不好处理。

感想

  • 二分法找BUG万岁。
  • 带JIT的脚本引擎找问题是真难,因为JIT出来的汇编代码产出的调用堆栈和编译器生成出来的约定不一样。然后你就没办法看到调用JIT代码之前的堆栈发生了什么。
  • 有些固有的BUG估计是没有人会理的,久而久之估计就成了feature。

后续

Node.js 8.x 10.x 12.x 在Windows/Linux上都有这个问题,Mac没条件试。

2 thoughts on “uv_async_t让Node.js脚本停止运行”

  1. 同遇到这问题了,不过按我的猜测,这问题很可能跟uv_async_t的实现有关系——uv_async_t实际上会block掉主循环,直到遇到下一个uv_async_send发来的信号。

    我没具体去看代码,但支撑我这个猜测的是调试时遇到的两个场景,产生了不一样的结果。

    场景一,将uv_async_t用于一请求一响应的场景。主动调用一个方法,这个方法里面先是uv_async_init注册回调,然后通知另一条线程去拿数据,最后返回promise。另一条线程拿到数据后,uv_async_send触发主线程回调,主线程回调uv_close掉这个uv_async_t。写个脚本循环await这个方法,脚本完全没有卡住,符合预期。

    场景二,将uv_async_t用于被动接收响应的场景。实现一个方法,从js层传入一个回调,用uv_async_init把这个回调包装成,从收到另一条线程收到数据,就把数据当成第一个参数调用回调。在脚本用这个方法注册一个回调,然后再用一个setTimeout的死循环保持主线程存活,并打印心跳。启动脚本,确保另一条线程完全没有数据传来主线程。然后问题就出来了,脚本会在第一次心跳后卡住,直到另一条线程传来一次数据出发回调,然后心跳跳一下,又再次卡住。

    综上,不难看出uv_async_t被init后,实际上是在主循环中注册了一个会导致block的事件检测,如果要等的事件没来,整个主循环就会卡住,直到事件到来,然后这个loop才能跑下去。但只要一直不close,这个事件检测会一直存在,下一次loop,继续卡住等事件。

    可以说,uv_async_t从设计之初就不打算支持被动接收响应的场景,只适用于一请求一响应的异步任务场景。

Leave a Reply to ChieveiT Cancel reply

Your email address will not be published. Required fields are marked *