[BUG]: Native crash in onnxruntime (BFCArena/posix_memalign, SIGTRAP) during embedding even with LM Studio set as embedding provider

快速结论：该报错发生在 AnythingLLM Desktop 版本中，即使已配置 LM Studio 作为嵌入提供程序，应用程序仍会在连续发送几条聊天消息后原生崩溃（并非 JavaScript 异常）。优先排查是否因为 Electron 的 PartitionAllocator 与 onnxruntime 的内存分配冲突导致，临时替代方案是将嵌入器切换为“无嵌入器”或使用 Docker/自托管版本。

问题场景

用户在 AnythingLLM Desktop 应用（版本 1.15.0）中配置了 LM Studio 作为嵌入提供程序（Embedding Provider），模型为 text-embedding-qwen3-embedding-0.6b，base URL 为 http://127.0.0.1:1234/v1，LLM 提供程序同样为 LM Studio（模型 qwen/qwen3.5-9b）。在已有文档嵌入的工作区中连续发送 2-3 条聊天消息后，应用程序本身或 AnythingLLM Helper 进程发生原生崩溃，且崩溃日志显示崩溃线程在 onnxruntime 内部，而非 LanceDB。

报错原文

Crash report (relevant excerpt — Thread 0, the crashing thread)

Process:             AnythingLLM Helper [17779]
Version:             1.15.0
Code Type:           ARM-64 (Native)
OS Version:          macOS 26.5.1 (25F80)

Exception Type:    EXC_BREAKPOINT (SIGTRAP)
Exception Codes:   0x0000000000000001, 0x000000010cc1b250
Termination Reason:  Namespace SIGNAL, Code 5, Trace/BPT trap: 5

Triggered by Thread 0, Dispatch Queue: com.apple.main-thread

Thread 0 Crashed:: node.CrUtilityMain Dispatch queue: com.apple.main-thread
...
libsystem_malloc.dylib            _malloc_zone_memalign + 300
libsystem_malloc.dylib            _posix_memalign + 52
libonnxruntime.1.14.0.dylib       onnxruntime::CPUAllocator::Alloc(unsigned long) + 60
libonnxruntime.1.14.0.dylib       onnxruntime::BFCArena::Extend(unsigned long)::$_0::operator()(unsigned long) const + 60
libonnxruntime.1.14.0.dylib       onnxruntime::BFCArena::Extend(unsigned long) + 436
libonnxruntime.1.14.0.dylib       onnxruntime::BFCArena::AllocateRawInternal(...) + 916
libonnxruntime.1.14.0.dylib       onnxruntime::BFCArena::Alloc(unsigned long) + 60
libonnxruntime.1.14.0.dylib       onnxruntime::Tensor::Tensor(...) + 148
libonnxruntime.1.14.0.dylib       onnxruntime::Tensor::InitOrtValue(...) + 116
libonnxruntime.1.14.0.dylib       onnxruntime::ExecutionFrame::AllocateMLValueTensorSelfOwnBufferHelper(...) + 644
libonnxruntime.1.14.0.dylib       onnxruntime::ExecutionFrame::AllocateAsPerAllocationPlan(...) + 708
libonnxruntime.1.14.0.dylib       onnxruntime::IExecutionFrame::GetOrCreateNodeOutputMLValue(...) + 464
libonnxruntime.1.14.0.dylib       onnxruntime::OpKernelContext::OutputMLValue(...) + 132
libonnxruntime.1.14.0.dylib       onnxruntime::OpKernelContext::Output(...) + 20
libonnxruntime.1.14.0.dylib       onnxruntime::MatMul::Compute(onnxruntime::OpKernelContext*) const + 444
libonnxruntime.1.14.0.dylib       onnxruntime::ExecuteKernel(...) + 328
libonnxruntime.1.14.0.dylib       onnxruntime::LaunchKernelStep::Execute(...) + 48
libonnxruntime.1.14.0.dylib       onnxruntime::RunSince(...) + 208
libonnxruntime.1.14.0.dylib       onnxruntime::ExecuteThePlan(...) + 888
libonnxruntime.1.14.0.dylib       onnxruntime::utils::ExecuteGraphImpl(...) + 408
libonnxruntime.1.14.0.dylib       onnxruntime::utils::ExecuteGraph(...) + 908
libonnxruntime.1.14.0.dylib       onnxruntime::utils::ExecuteGraph(...) + 344
libonnxruntime.1.14.0.dylib       onnxruntime::InferenceSession::Run(...) + 2196
libonnxruntime.1.14.0.dylib       OrtApis::Run(...) + 656
onnxruntime_binding.node          InferenceSessionWrap::Run(Napi::CallbackInfo const&) + 2220
onnxruntime_binding.node          Napi::InstanceWrap::InstanceMethodCallbackWrapper(...) + 128
...
Electron Framework                ElectronMain + 180

原因分析

该崩溃的根本原因是 Electron 的 Chromium PartitionAllocator。AnythingLLM Desktop 应用将后端服务器作为 Electron Utility Process（通过 utilityProcess.fork()）运行。当原生嵌入器需要处理文档时，它通过 Bree（使用 child_process.fork()）产生子进程。由于 fork() 默认使用 process.execPath，子进程使用 Electron Helper 二进制文件而非标准 Node.js 二进制文件运行。

Electron 二进制文件包含 Chromium 的 PartitionAllocator 作为编译时 malloc 替代。当 onnxruntime-node 的原生代码调用 posix_memalign 进行张量内存对齐分配时，会经过这个自定义分配器而非系统的 libsystem_malloc。PartitionAllocator 有更严格的约束（对齐限制、最大分配大小），导致其触发 __builtin_trap()，产生 EXC_BREAKPOINT (SIGTRAP) 崩溃。崩溃发生在第一次成功嵌入批量之后，因为第二次批量触发了新的内存分配（arena 扩展），正好触及分配器的约束。

注意：Docker/自托管环境不受影响，因为这些环境使用普通的 Node.js 二进制文件，使用标准的系统分配器。

环境排查

确认 AnythingLLM 版本是否为 1.15.0 或相关版本
确认运行环境是否为 macOS（本次崩溃在 macOS 26.5.1 上观察，但可能影响其他操作系统）
确认运行模式是否为 Desktop 版本，而非 Docker/自托管版本
确认 LM Studio 是否已正确配置为嵌入提供程序，且 LM Studio 服务器日志显示嵌入请求成功返回
检查崩溃是否为原生级别错误（无 JavaScript 异常），并确保应用的事件日志或桌面日志文件中无相关记录

解决步骤

临时替代方案（可优先尝试）：在无核心 RAG 功能需求时，在设置中将嵌入提供程序切换为“无嵌入器”（No embedder），以避免触发任何 onnxruntime 调用。
长期解决方案：改用 Docker 或自托管版本运行 AnythingLLM。这些环境使用标准 Node.js 二进制文件，不会触发 Electron 的 PartitionAllocator 冲突。
等待上游修复：检查 Electron 是否已修复已知问题（如 Electron issue #41513），并关注 AnythingLLM 的更新版本，看是否已通过其他方式规避了该问题（例如改用不同的子进程产生方式）。
在开发或测试环境中，如果确实需要使用 Desktop 版本且无法切换嵌入器，可以尝试使用环境变量强制使用系统分配器（例如设置 NODE_OPTIONS=”–max-old-space-size=4096″ 等，但 Issue 中未提供特定环境变量，需要谨慎测试）。