开始以为是上下问太长引起，但是新建任务跑第一轮也会出现这个异常。请有没有知道怎么解决的？
版权声明：本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《阿里云开发者社区用户服务协议》和《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
我发现是读取图片是报错的，我用qoder cn测试了；
这是ai总结的
【BUG】Qoder CN 桌面版：Qoder CLI daemon 反复 SIGSEGV，导致会话报 QODER_EXECUTION_STREAM_FAILED
一、现象
会话执行过程中反复弹异常，报错文案对应日志里的 QODER_EXECUTION_STREAM_FAILED / ChatSession execution transport failed。根因不是会话本身：跑 Agent 的独立进程 Qoder CLI daemon（~/.qoder-cn/shared_client/bin/<版本>/x86_64_linux/QoderCN start）被 SIGSEGV 打死；它一死，当时所有打开的会话这一轮全部失败，App 侧再自动把 daemon 重新拉起、会话重开（所以聊天看起来"续上了"，但那轮回答确实丢了，需要重发）。
二、频率（本机实测，口径：qodercli/qoder-agent-sdk.log 里 [DaemonConnection] connection failed 计一次真实崩溃，[Daemon] spawned 计一次重拉）
三、崩溃上下文（关键：不是请求触发的）
[DaemonConnection] connection failed pendingRequests=0 sessions=3，即崩溃时没有待决请求，只有 3~4 个空闲会话挂着。get_models / list_byok_configs 轮询；11:40 那次是一个会话 [SDK close] … stage=close outcome=completed 之后约 8 秒。[ERROR] [App] Unhandled main process rejection {"name":"QoderCliProcessError","message":"Qoder CLI daemon terminated by signal SIGSEGV"}；栈只到 app.asar/node_modules/@qoder-ai/qoder-cn-agent-sdk/dist/index.js:24:23383（是 SDK 的检测点，不是崩溃点）。QoderCliDaemon] QoderCLI SDK Daemon generation drain timed out 两次、hydration invalidated 20 次，说明 daemon 的 generation 切换也有卡住的情况。四、已排除
五、版本线索
daemon：cosy.core.version=2026.1021.1，build.commitId=275db5b，build.time=2026-10-21 20:38:57（读自 ~/.qoder-cn/shared_client/bin/config.json）。App：Qoder CN 0.4.9 / Electron 43.1.1。系统：Ubuntu 26.04.1、kernel 7.0.0-38、GNOME 50.1。本机 shared_client/bin 下留有 27 个历史 CLI 版本目录，最近一次是 10-22 08:33 落地的 2026.1021.1；崩溃频度明显上升也是这之后的事（我只能确认时间同窗口，没有更早的同类统计做对照）。
六、想请官方确认的点
七、我可以提供的补充材料
本次与前几次运行的 main.log、renderer.log、qodercli/qoder-agent-sdk.log（含每次崩溃前后行）；按 connection failed/spawned 统计的逐启动表；如果指导我用 ulimit -c unlimited 启动抓 core，我可以提供带 core 的第二次复现。
八、时间序列（全部保留的运行日志，按启动时刻；口径：qodercli/qoder-agent-sdk.log 里 connection failed 计数）
10-17 01:53 app=? 崩溃=1
10-17 08:48 app=? 崩溃=0
10-19 00:25 app=0.4.8 崩溃=1
10-19 04:42 app=0.4.8 崩溃=40
10-20 00:27 app=? 崩溃=0
10-21 00:28 app=0.4.8 崩溃=1
10-21 00:55 app=0.4.9 崩溃=1
10-23 05:34 app=0.4.9 崩溃=0
10-23 05:35 app=0.4.9 崩溃=0
10-23 06:06 app=0.4.9 崩溃=0
10-23 06:14 app=0.4.9 崩溃=0
10-23 06:15 app=0.4.9 崩溃=2
10-23 06:48 app=0.4.9 崩溃=3
10-24 02:59 app=0.4.11 崩溃=2
10-24 03:23 app=0.4.11 崩溃=1
10-24 03:24 app=0.4.11 崩溃=2
10-24 03:26 app=0.4.11 崩溃=0
10-24 03:29 app=0.4.11 崩溃=0
10-24 03:29 app=0.4.11 崩溃=7
10-24 05:01 app=0.4.11 崩溃=2
10-24 05:32 app=0.4.11 崩溃=2
10-24 05:36 app=0.4.11 崩溃=0
10-24 05:38 app=0.4.11 崩溃=3
10-24 05:56 app=0.4.9 崩溃=2
结论修正（重要，请以这版为准，别采信我之前"可能由 2026.1021.1 引入"的猜测）：
九、根因已定位（apport 保留了 core，我用 gdb 解出栈）
core 来源：/var/crash/_opt_Qoder-CN_qoder-cn.1000.crash（Date: Sat Oct 24 10:52:49 2026，Signal 11，CoreDump 1.54 GB）
崩溃进程 cmdline：/opt/Qoder-CN/qoder-cn /opt/Qoder-CN/resources/app.asar.unpacked/node_modules/@qoder-ai/qoder-cn-agent-sdk/dist/_worker/qoder-worker-runtime.obf.mjs --sdk
（也就是说被记成 "Qoder CLI daemon" 的其实是这个 Electron worker）
gdb 栈（故障线程 LWP 491654）：
关键证据（同一进程的 ProcMaps）：进程里同时存在两份 GObject 运行时
/opt/.../@img/sharp-libvips-linux-x64/lib/libvips-cpp.so.8.17.3
—— 它自己静态内嵌并导出 glib 符号：nm -D 显示 T g_object_unref、T g_type_class_ref
/usr/lib/x86_64-linux-gnu/libglib-2.0.so.0.8800.0
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.8800.0
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0.8800.0 （系统 GLib 2.88.0-1ubuntu0.1，由 Electron 侧载入）
结论：sharp 的 .node 在 libuv 线程池里对 libvips 的 GObject 对象做 unref 时，调用被解析到系统那份 libgobject，
而该对象是在内嵌另一份 glib 的 libvips 里创建的，GType 表对不上 → class/finalize 指针为空 → 跳到 0x0 → SIGSEGV。
worker 一死，SDK 侧就报 QODER_CLI daemon terminated by signal SIGSEGV，所有挂在它上面的会话本轮失败
（报错里出现 "isByok":true，本机确有外部模型渠道配置）。
触发面：worker 里 sharp 的调用点统计（grep 自带 bundle）—— resize 31 处、metadata 11、toBuffer 7、jpeg 7、extract 7、png 5、webp 1、heif 1，
即会话中涉及图片缩放/取元数据/裁剪的流程（贴图、截图预览、生成图缩略图等）。
请官方确认/修复的方向（任一条都能消掉这类崩溃）：
1) 别在同一个进程里放两份 GObject：要么让 sharp/libvips 用系统 GLib（不要静态内嵌 glib 的 libvips 构建），
要么保证 Electron 不加载系统 libgobject；
2) 或换用官方明确支持 Electron 的 sharp/libvips 打包组合（当前 @img/sharp-linux-x64 0.34.5 + libvips-cpp 8.17.3 + sharp-libvips 1.2.4）；
3) 至少把这类崩溃接进崩溃收集：现在 App 的 Crashpad 不收它、只有 apport 留了 core，普通用户提交反馈时拿不到栈。
不确定项请别当成结论：apport 只留了 1 份同签名 core（CrashCounter=1）。10-17 / 10-19 的 daemon 崩溃同样是 SIGSEGV，
但没有保留 core，"同一栈"是强推断而非实证。另有一份不同的崩溃记录：/var/crash/_opt_Qoder CN_qoder-cn.1000.crash，
Mon Oct 19 08:20:46 2026，Signal 4（SIGILL），cmdline 是主进程 /opt/Qoder CN/qoder-cn --ozone-platform=x11 —— 那是另一件事，不要混进本条。
十、最小复现（不启动 App 也能复现，3 行脚本，命中率 100%）
用 App 自带的那个 Electron 二进制当 node 跑（ELECTRON_RUN_AS_NODE=1），加载 App 自带的 sharp，
对任意 PNG 调 metadata()：
// repro.js
const sharp = require('/opt/Qoder-CN/resources/app.asar.unpacked/node_modules/sharp');
sharp('/tmp/any.png').metadata().then(m => console.log(m.width));
ELECTRON_RUN_AS_NODE=1 /opt/Qoder-CN/qoder-cn repro.js → SIGSEGV（6/6 次）
node repro.js（系统 node v22.14.0，同一份 sharp、同一张图）→ 正常
实测矩阵（都是同一台机器、同一份 sharp 0.34.5 / libvips-cpp 8.17.3 / sharp-libvips 1.2.4）：
调用 系统 node App 的 Electron 运行时
sharp(png).metadata() 正常 崩 6/6
sharp(jpg).metadata() 正常 崩
sharp(fs.readFileSync(png)).metadata() 正常 崩 ← 与文件路径/权限无关
sharp(png).raw() — 崩
sharp(png).resize().toBuffer() 正常 正常 3/3（但 8 张并发时 4 次里崩 1 次）
sharp(webp).metadata() 正常 正常 4/4 ← 只有走 webp 加载器不崩
上述任一 + VIPS_CONCURRENCY=1 — 仍然崩 ← 不是单纯线程并发问题
与线上现象的对应关系：被记为 "Qoder CLI daemon" 的进程就是 /opt/Qoder-CN/qoder-cn … qoder-worker-runtime.obf.mjs --sdk，
即上面这个 Electron 运行时；只要任务里让 App 去读 PNG/JPEG 的元数据（附图、预览、缩略图、视觉输入准备），
该进程就 100% 崩，会话本轮报 QODER_EXECUTION_STREAM_FAILED。用户侧可复现描述：
"任务读 /tmp 里的图片就异常，同一个文件连试三次都异常"——与 metadata() 的 6/6 崩溃率吻合。
用户侧已验证可用的临时规避：把要进会话的图先转成 WebP（例如 convert in.png out.webp 或 PIL 保存为 webp），
同一份代码路径下 WebP 加载器不崩；或者让 Agent 用命令行/PIL 读像素、不要以图片附件形式交给界面渲染。
请重点看：Electron 宿主已把系统 GLib 的 g_object_unref 带进全局符号表，而 sharp 自带 libvips 内嵌了另一份
（libvips-cpp.so.8.17.3 自己导出 T g_object_unref、T g_type_class_ref）。同一个进程里两套 GObject 类型系统共存时，
libvips 的 PNG/JPEG foreign-load 对象被错误的 unref 实现处理，class/finalize 指针为空 → 跳 0x0。
WebP 路径不经过该对象，所以不崩 —— 这正好把范围收得很窄。
这大概率是 glibc 版本不兼容 或 动态链接库缺失 导致的。Ubuntu 26.04（若指代未来版本或笔误为 24.04/22.04）升级后，系统底层的 libc.so 可能发生了大版本变更，而 Qoder CN 0.4.11 的预编译二进制文件如果是基于旧版 glibc 构建的，就会报 “version GLIBC_X.XX' not found” 或直接段错误。
排查步骤：
检查报错详情：运行 qoder --version 或相关命令，看是否提示 libstdc++.so 或 libc.so 缺失。
确认依赖：使用 ldd $(which qoder) 查看链接库状态，标记为 not found 的即为缺失项。
临时修复：尝试安装对应版本的 libstdc++ 和 glibc` 开发包，或从源码编译 Qoder CN 以适配当前系统环境。
回退验证：若急需使用，先降级至 0.4.10 稳定版，确认是否为该版本引入的兼容性问题，再向官方提交 Issue。
Qoder CN 是 Qoder CN 系列中面向软件开发场景的核心子产品（原“通义灵码”），提供 IDE、JetBrains 插件、Visual Studio Code 插件等多种使用形态。Qoder CN 持续提供代码智能生成、智能问答、多文件修改、编程智能体等能力，并在模型选择、专家协作、任务规划等方向全面升级，为开发者带来高效、流畅的编码体验。同时面向企业客户提供企业标准版、企业专属版，具备企业级场景自定义、私域知识增强等能力，助力企业研发智能化升级。