Node.js 子线程 Crash 问题的排查

前言：昨天碰到了一个 worker_threads crash 的线程问题，最终经过阅读源码和调试找到了具体原因。排查不得不说，线程阅读源码是排查解决问题的非常有效的方法。

代码例子如下。线程 

index.js:

const addon = require.resolve(./build/Release/addon.node);

// this makes addon not be 排查unloaded

require(addon);

const { Worker } = require(worker_threads);

event_loop.cc:

#include "event_loop.h"

void on_close(uv_handle_t *handle){

delete handle;

}

void cleanup(void* data){

uv_close((uv_handle_t *)data, on_close);

}

void Start(const Napi::CallbackInfo &args){

Napi::Env env = args.Env();

uv_loop_t *loop;

v8::Isolate* isolate = v8::Isolate::GetCurrent();

napi_get_uv_event_loop(env, &loop);

uv_prepare_t* prepare_handle = new uv_prepare_t;

uv_prepare_init(loop, prepare_handle);

uv_unref((uv_handle_t *)prepare_handle);

uv_prepare_start(prepare_handle, [](uv_prepare_t *handle) {});

node::AddEnvironmentCleanupHook(isolate, cleanup, prepare_handle);

}

Napi::Object Initialize(Napi::Env env, Napi::Object exports){

exports.Set(Napi::String::New(env, "start"), Napi::Function::New(env, Start));

return exports;

}

总的来说就是我需要在 worker_threads 里使用 addon，然后在子线程退出时发生了 segmentation fault，线程但是排查在主线程里是没问题的（完整代码可参考 https://github.com/theanarkh/test_worker_thread）。首先分析下上面代码的线程过程，当在 JS 层执行 start 的排查时候，就会往 loop 里面插入一个任务，线程并通过 AddEnvironmentCleanupHook 注册了一个回调，排查这个回调在线程退出时会被执行，线程执行完 start 后线程就退出了，排查所以这时候 AddEnvironmentCleanupHook 的线程回调 cleanup 会被执行，cleanup 里调用 uv_close 关闭 handle，接着在线程真正退出时会执行一次 uv_run 处理 uv_close 的回调，从而释放内存。问题发生在执行 uv_close 的回调时出现了 crash。通过调试发现调用 uv_close 时传入的站群服务器回调函数地址是 A，但是最终执行时地址变成了 B，而 B 是一个非法地址，从而导致了 crash。出现这个问题时，我就开始调试，尝试找出哪里修改了这个地址，但是无果，最终靠灵光一现，想到了动态链接库被卸载的问题，然后通过打断点发现果然如此。

下面通过 Node.js 的源码来分析这个问题。

WorkerThreadData data(this);

{

Locker locker(isolate_);

Isolate::Scope isolate_scope(isolate_);

SealHandleScope outer_seal(isolate_);

DeleteFnPtrenv_;

// 离开作用域时执行 env_.reset();

auto cleanup_env = OnScopeLeave([&]() {

isolate_->CancelTerminateExecution();

env_.reset();

});

// 初始化子线程

{

HandleScope handle_scope(isolate_);

Localcontext;

{

TryCatch try_catch(isolate_);

context = NewContext(isolate_);

}

Context::Scope context_scope(context);

{

env_.reset(CreateEnvironment(

data.isolate_data_.get(),

context,

std::move(argv_),

std::move(exec_argv_),

static_cast(environment_flags_),

thread_id_,

std::move(inspector_parent_handle_)));

}

{

Mutex::ScopedLock lock(mutex_);

if (stopped_) return;

this->env_ = env_.get();

}

{

if (LoadEnvironment(env_.get(), StartExecutionCallback{}).IsEmpty())

return;

}

}

// 进入子线程事件循环

{

Maybeexit_code = SpinEventLoop(env_.get());

Mutex::ScopedLock lock(mutex_);

if (exit_code_ == 0 && exit_code.IsJust()) {

exit_code_ = exit_code.FromJust();

}

}

上面是子线程执行时的核心逻辑，当子线程退出时，OnScopeLeave 的第一个函数参数会被执行，从而执行 env_.reset()，接着执行 FreeEnvironment。

void FreeEnvironment(Environment* env) {

Isolate* isolate = env->isolate();

Isolate::DisallowJavascriptExecutionScope disallow_js(isolate,

Isolate::DisallowJavascriptExecutionScope::THROW_ON_FAILURE);

{

HandleScope handle_scope(isolate); // For env->context().

Context::Scope context_scope(env->context());

SealHandleScope seal_handle_scope(isolate);

env->set_stopping(true);

env->stop_sub_worker_contexts();

// 执行 AddEnvironmentCleanupHook 回调

env->RunCleanup();

RunAtExit(env);

}

MultiIsolatePlatform* platform = env->isolate_data()->platform();

if (platform != nullptr)

platform->DrainTasks(isolate);

// 删除 env 对象

delete env;

FreeEnvironment 首先通过来 RunCleanup 执行通过 AddEnvironmentCleanupHook 注册的回调，回到开始的代码就是执行 uv_close 往 loop 里插入一个回调。接着 FreeEnvironment 删除了 env 对象，接下来看 env 的服务器租用析构函数中相关的代码。

if (!is_main_thread()) {

for (binding::DLib& addon : loaded_addons_) {

addon.Close();

}

如果当前是子线程，析构函数会调用 addon.Close() 关闭动态链接库，也就是 addon，当 addon 的引用数为 0 就会被卸载。因为只有子线程里用到了 addon 所以 addon 会被卸载。这时候 uv_close 回调函数的地址就被修改了。env 处理完之后，接着是 WorkerThreadData 被析构，WorkerThreadData 析构函数中会再执行一次 uv_run 处理剩下的任务。

所以 uv_close 的回调就会被执行，因为这时候回调函数的地址被修改成非法的了，所以导致了 crash。除了这个问题外，子线程退出前还会检查 loop，如果还有任务没有被关闭也会导致线程 crash。

void CheckedUvLoopClose(uv_loop_t* loop) {

if (uv_loop_close(loop) == 0) return;

PrintLibuvHandleInformation(loop, stderr);

fflush(stderr);

// Finally, abort.

CHECK(0 && "uv_loop_close() while having open handles");

再看 uv_loop_close:

int uv_loop_close(uv_loop_t* loop) {

QUEUE* q;

uv_handle_t* h;

if (uv__has_active_reqs(loop))

return UV_EBUSY;

QUEUE_FOREACH(q, &loop->handle_queue) {

h = QUEUE_DATA(q, uv_handle_t, handle_queue);

if (!(h->flags & UV_HANDLE_INTERNAL))

return UV_EBUSY;

}

uv__loop_close(loop);

if (loop == default_loop_ptr)

default_loop_ptr = NULL;

return 0;

总结：这个问题排查了很长的时间，最终靠一个切入点成功找到了问题，并通过源码深入了解了这个过程。源码，是学习一门技术非常重要的服务器托管资料。

最新评论