
Misc. bug: Llama-server.exe executing built-in tool edit_file to append an existing text file crashes server
快速结论:当 llm 调用内置工具 edit_file 并传递 line_start = -1 和 line_end = -1 参数(append 模式)时,llama-server.exe 会直接崩溃退回到命令行,无任何错误日志。优先排查版本是否为 b9189 及以上,并进行降级或临时禁用该工具。
问题场景
用户运行 llama-server.exe 并启用内置工具 edit_file。当 LLM 决定调用该工具来追加内容到一个已存在的文本文件时,特别是在 append 模式下传入 -1 作为 line_start/line_end 参数,llama-server 进程会直接崩溃,退回到命令行提示符,不输出任何错误信息。此问题在 Windows 系统上使用 Vulkan、CUDA 12 以及纯 CPU 环境下均出现。
报错原文
Nothing logged, it just crashes back to command line.
Drops to command prompt with no errors logged.
工具调用 payload 示例:
{
"path": "./helper.sh",
"changes": [
{
"mode": "append",
"line_start": -1,
"line_end": -1,
"content": "\n\n..."
}
]
}
原因分析
在 tools/server/server_tools.cpp 的 server_tool_edit_file::invoke 函数中,当 line_start == 0 时,代码将 line_end 设置为 lines array length + 1,然后先后进行了减 1 和加 1 操作,导致最终引用到数组末尾之外的字节(out-of-bounds access),从而引发段错误崩溃。实际触发条件是 LLM 生成 line_start = -1 和 line_end = -1——这会导致后端的行号处理逻辑产生越界。
环境排查
- llama-server.exe 版本:b9189 及以上(最后正常版本是 b9186)。验证到 b9222 仍存在问题。
- 后端:Vulkan、CUDA 12、CPU 均受影响。
- 操作系统:Windows(报告),但 Linux 上 GDB 回溯中也观察到相同崩溃,表明平台无关。
- 日志级别:即便是设置最高 verbose 级别也无错误日志。
解决步骤
- 降级:将 llama.cpp 回退到 b9186 或更早版本,这是确认的最后正常工作版本。
- 临时禁用该工具:在 llama-server 设置中禁用
edit_file工具。之后 LLM 会使用write_file作为替代,但代价是读取整个文件、在内存中编辑、再写回新文件,显著增加 token 消耗。 - 应用代码补丁:(可优先尝试)修改
tools/server/server_tools.cpp中处理 line_start/line_end 为 -1 时的边界逻辑,确保不会产生数组越界。目前社区给出的具体修复涉及检查line_start == -1时的line_end赋值与调整操作。
验证方法
发起一个包含 append 模式的 edit_file 工具调用(如附录中的 JSON payload),确认 llama-server.exe 不再崩溃退回到命令行,并能在控制台或日志中看到正常工具执行结果。



