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'); new Worker(`require('${addon}').start();`, {eval: true});
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; } NODE_API_MODULE(NODE_GYP_MODULE_NAME, Initialize)
總的來說就是我需要在 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_); DeleteFnPtr<Environment, FreeEnvironment> env_; // 離開作用域時執行 env_.reset(); auto cleanup_env = OnScopeLeave([&]() { isolate_->CancelTerminateExecution(); env_.reset(); }); // 初始化子線程 { HandleScope handle_scope(isolate_); Local<Context> context; { 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<EnvironmentFlags::Flags>(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; } } // 進入子線程事件循環 { Maybe<int> exit_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_run(&loop_, UV_RUN_ONCE);
所以 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; }
總結:這個問題排查瞭很長的時間,最終靠一個切入點成功找到瞭問題,並通過源碼深入瞭解瞭這個過程。源碼,是學習一門技術非常重要的資料。
到此這篇關於Node.js 子線程Crash 問題的排查的文章就介紹到這瞭,更多相關Node.js 子線程Crash內容請搜索WalkonNet以前的文章或繼續瀏覽下面的相關文章希望大傢以後多多支持WalkonNet!
推薦閱讀:
- Nodejs探秘之深入理解單線程實現高並發原理
- nodejs處理tcp連接的核心流程
- JS調用C++函數拋出異常及捕捉異常詳解
- Android handle-message的發送與處理案例詳解
- MySQL單表千萬級數據處理的思路分享