[GH-ISSUE #845] [bug] macOS 下调用 AppHandle::restart 导致主线程死锁（tauri_plugin_store） #626

New issue

Closed

opened 2026-03-02 03:40:55 +03:00 by kerem · 1 comment

kerem commented

2026-03-02 03:40:55 +03:00

Owner

Originally created by @HansYeoh on GitHub (Jan 10, 2026).
Original GitHub issue: https://github.com/codexu/note-gen/issues/845

详细描述这个 Bug

问题概述

在mac上导入配置文件的时候，出现卡死情况。

通过分析报错信息，确认在 macOS 环境下，NoteGen 0.24.0 在调用
tauri_plugin_process::restart 时会出现 确定性的卡死（deadlock，而非 crash）。

卡死发生在 主线程（UI 线程），系统 stackshot 已明确标记为死锁。

环境信息

应用版本：NoteGen 0.24.0
框架：Tauri（wry / wkwebview）
操作系统：macOS 15.7.3 (24G419)
架构：x86_64

关键现象（系统级证据）

macOS Stackshot 明确指出：


Deadlocked: 1 thread - Thread "main"
Blocked by Deadlock: note-gen

主线程阻塞位置

主线程在执行 restart 过程中被阻塞，调用路径如下：


tauri_plugin_process::commands::restart
→ tauri::app::AppHandle::restart
→ tauri::app::AppHandle::cleanup_before_exit
→ tauri_plugin_store::Store::drop
→ tauri_plugin_store::Store::save
→ std::sync::Mutex::lock
→ pthread_mutexwait   （阻塞点）

即：在主线程中同步执行 Store::save，并尝试获取 Mutex。

后台线程状态（形成死锁闭环）

与此同时，Tokio runtime 后台线程处于以下状态：


WTF::callOnMainRunLoopAndWait
→ Condition::wait
→ __psynch_cvwait

这表示后台线程正在 等待主线程 RunLoop 执行回调。

死锁机理分析

形成了典型的闭环等待关系：

主线程：
- 正在 Store::save() 中同步等待 Mutex
后台线程：
- 持有或依赖相关资源
- 同时等待主线程 RunLoop 回调

由于主线程被 Mutex 阻塞，RunLoop 无法继续执行，
最终导致 主线程与后台线程相互等待，形成确定性死锁。

备注

该问题并非 WebKit 或 macOS Bug
系统 Stackshot 已明确判定为死锁
属于主线程 + 同步锁 + RunLoop 依赖的经典死锁模式

NoteGen 版本

0.24.0

操作系统

macOS

报错日志

No response

Originally created by @HansYeoh on GitHub (Jan 10, 2026). Original GitHub issue: https://github.com/codexu/note-gen/issues/845 ### 详细描述这个 Bug ## 问题概述在mac上导入配置文件的时候，出现卡死情况。通过分析报错信息，确认在 macOS 环境下，NoteGen 0.24.0 在调用 `tauri_plugin_process::restart` 时会出现 **确定性的卡死（deadlock，而非 crash）**。卡死发生在 **主线程（UI 线程）**，系统 stackshot 已明确标记为死锁。 --- ## 环境信息 - 应用版本：NoteGen 0.24.0 - 框架：Tauri（wry / wkwebview） - 操作系统：macOS 15.7.3 (24G419) - 架构：x86_64 --- ## 关键现象（系统级证据） macOS Stackshot 明确指出： ``` Deadlocked: 1 thread - Thread "main" Blocked by Deadlock: note-gen ``` --- ## 主线程阻塞位置主线程在执行 restart 过程中被阻塞，调用路径如下： ``` tauri_plugin_process::commands::restart → tauri::app::AppHandle::restart → tauri::app::AppHandle::cleanup_before_exit → tauri_plugin_store::Store::drop → tauri_plugin_store::Store::save → std::sync::Mutex::lock → pthread_mutexwait （阻塞点） ``` 即：**在主线程中同步执行 Store::save，并尝试获取 Mutex。** --- ## 后台线程状态（形成死锁闭环）与此同时，Tokio runtime 后台线程处于以下状态： ``` WTF::callOnMainRunLoopAndWait → Condition::wait → __psynch_cvwait ``` 这表示后台线程正在 **等待主线程 RunLoop 执行回调**。 --- ## 死锁机理分析形成了典型的闭环等待关系： - 主线程： - 正在 `Store::save()` 中同步等待 Mutex - 后台线程： - 持有或依赖相关资源 - 同时等待主线程 RunLoop 回调由于主线程被 Mutex 阻塞，RunLoop 无法继续执行，最终导致 **主线程与后台线程相互等待，形成确定性死锁**。 ## 备注 * 该问题并非 WebKit 或 macOS Bug * 系统 Stackshot 已明确判定为死锁 * 属于主线程 + 同步锁 + RunLoop 依赖的经典死锁模式 ### NoteGen 版本 0.24.0 ### 操作系统 macOS ### 报错日志 _No response_