Bug 报告：Remote Control Sync 子进程崩溃循环导致主进程假死（需 SIGKILL 才能恢复）

环境

• 产品：Qoder CN Desktop（Qoder-CN App）0.5.5，Electron 43.8.4
• 系统：Fedora Linux 44 Workstation（x86_64，Wayland + Xwayland，App 以 ozone-platform=x11 运行）
• 触发场景：另一设备通过"远程控制"连接本机，触发会话历史同步

现象

1. 远程设备连接后开始同步两个本地会话的历史消息（batch=50，每批 100–160KB）
2. 同步子进程 Qoder Remote Control Sync（node.mojom.NodeService）反复异常退出并自动重启，形成崩溃循环：
   • 昨日日志 main.1.log 中相关记录 279 次
   • 当日 main.log 中 16 次，集中在 11:10–11:11（UTC+8）
3. 11:11:31（UTC+8）主进程日志完全停止（renderer 停在 10:34），UI 无响应，持续 8 小时以上
4. 卡死的主进程不响应 SIGTERM（systemctl --user stop 被吊住），仅 kill -9 可结束
5. 重启后故障消失，0 错误运行正常

崩溃现场（coredumpctl）

• Signal 11 (SEGV)，崩溃线程 PC = 0x0（空指针）
• 崩溃点位于原生图像库 sharp-linux-x64.node（+0x1835d），调用链经 Node 线程池（ThreadPoolWork/uv_work）
• coredump：/var/lib/systemd/coredump/core.qoder-cn.1000.7de104dd....2199622.1793934686....zst（13M，保留可用）

Stack trace of thread 2199699:
 #0  0x0000000000000000 n/a
 #1  0x00007f5a71ada35d n/a (sharp-linux-x64.node + 0x1835d)
 #2  0x00007f5a71ae200c n/a (sharp-linux-x64.node + 0x2000c)
 #3  0x00007f5a71ad8eac n/a (sharp-linux-x64.node + 0x16eac)
 #4  node::ThreadPoolWork::ScheduleWork(...) [uv_work]

主进程日志关键摘录

[2026-11-06T03:11:16.097Z] [ERROR] [main] [App] Electron child process exited
  {"type":"Utility","reason":"crashed","exitCode":139,
   "serviceName":"node.mojom.NodeService","name":"Qoder Remote Control Sync"}
# 同类记录每 2~5 秒一条，同时 Remote Control 历史同步 body_batch 持续进行
[2026-11-06T03:11:31.381Z]  ← 最后一条日志，此后主进程静默 8h+

systemd 日志佐证（每 2~3 秒一次段错误）：

11月 06 11:11:16 fedora systemd-coredump[...]: Process 2198631 (qoder-cn) terminated
  abnormally with signal 11/SEGV
11月 06 11:11:19 fedora systemd-coredump[...]: Process 2198872 (qoder-cn) ...
（连续多条）

日志目录

~/.config/com.qodercn.app.stable/logs/20261105-150951.663-2144850-6e36e84f/（含 main.log / main.1.log / renderer.log）

反馈的两个问题

1. 崩溃本体：Remote Control Sync 在历史同步/图片处理路径上，sharp 原生库空指针段错误（怀疑与 Fedora 44 的 glibc/新环境兼容性亦有关）
2. 容错设计：单个 utility 子进程崩溃循环最终导致主进程事件循环假死，且不响应 SIGTERM。建议：同步子进程崩溃应退避重试并隔离失败任务，主进程不应被拖死；恢复后历史同步应能断点续传

复现建议

远程连接一台含有大体量历史会话（本次同步了 16+ 批、800+ 条消息且含图片）的桌面端，观察 Remote Control Sync 是否段错误并复现主进程假死。

追加证据（2026-11-07 凌晨，升级 0.5.6 后）

升级：qoder-cn-0.5.6-1.x86_64（官方 rpm，SHA256 校验通过）——问题未修复，同样失败。

清空镜像库后的连锁发现（0.5.5 与 0.5.6 行为一致）：

1. 将 remote-control.sqlite 移走后，数据库准备流程在 handoff 阶段报 ENOENT——该流程不会从零创建库文件，只认已有文件
2. 用空 WAL 模式 SQLite 文件顶位后，inspect/handoff/open 全部通过，死在 import 阶段：elapsed 1ms 即失败（failure_stage:"import"，有 child_pid 但无任何日志/信号记录），cause 仍为 REMOTE_CONTROL_SCOPE_DATABASE_UNAVAILABLE，REMOTE_CONTROL_STORAGE_REPAIR_FAILED 同样出现。修复流程同样无法工作
3. 主进程在无人操作时自发 SIGILL（signal 4）崩溃：00:42:51、00:53:06、01:04:44 各一次，堆栈全部落在 Electron 主二进制内。主机环境：CPU 品牌字符串为空（lscpu 显示 "06/55"），疑似虚拟机/特殊 CPU，flags 含 avx2/avx512f
4. 该机器上 Qoder 的凭据存储在非 GNOME 会话环境启动时会退化为 basic_text 且 encryptionAvailable:false，此时拒绝保存凭据并清除已有条目，表现为"每次重启都掉登录"。以完整 GNOME 会话环境（含 XDG_CURRENT_DESKTOP=GNOME）启动则正常使用 gnome_libsecret

临时缓解措施（供其他用户参考）：

• 毒镜像库备份：remote-control.sqlite{,-shm,-wal}.bak-20261106-231930（清空后崩溃循环停止）
• 崩溃循环期间主进程仅 kill -9 可结束；systemctl --user stop 会被吊死
• 建议 Qoder：远程控制数据库准备流程应能自行建库（而不是 ENOENT 即弃）；import 子进程秒死应在日志中输出原因；凭据存储退化时不应清除已有凭据

coredump 保留：/var/lib/systemd/coredump/（SIGILL 样本 3 份 + 早期 SIGSEGV 样本），日志目录 ~/.config/com.qodercn.app.stable/logs/（20261105-150951 系列为故障全程记录）。