为什么Monty资源限制触发后会话不可信终端错误语义与丢弃策略详解【免费下载链接】montyA minimal, secure Python interpreter written in Rust for use by AI项目地址: https://gitcode.com/GitHub_Trending/monty3/montyMonty 是一个用 Rust 编写的、面向 AI 的最小化安全 Python 解释器。当不可信代码触发它的资源限制内存、执行时间或递归深度时Monty 会把该会话标记为终态terminal沙箱代码无法捕获这类错误堆状态和引用计数不再受任何保证宿主必须丢弃整个会话而不是继续在上面运行代码。本文用通俗的方式解释这套终端错误语义背后的原因以及正确的丢弃策略。一、先认识 Monty 的三道资源闸门 Monty 为每个会话session独立配置三道闸门防止不可信代码永远分配或永远循环闸门配置项超限时抛出的异常沙箱内能否捕获内存max_memory字节MemoryError❌ 不能执行时间max_duration_secs秒累计TimeoutError❌ 不能递归深度max_recursion_depth默认 1000 帧RecursionError✅ 可以 关键设计前两种错误对沙箱代码不可捕获。不可信代码绝不应该能拦截资源强制机制——如果它能try/except MemoryError后继续分配资源限制就形同虚设。只有RecursionError保持可捕获与 CPython 行为一致捕获后可安全继续执行。二、终端错误意味着什么内存或时间限制触发后错误被定义为终态的terminal不是事务性的。执行不是事务操作超限指令被中断时堆上可能已经留下一半分配了一半的对象、写了一半的结构。堆状态不再可信。官方文档明确写道一旦超限触发堆上可能残留引用计数错误的孤儿对象orphaned objects with wrong refcounts。后续任何代码的分配、回收都可能踩到这些地雷且表现不可预测。预算是累计的无法重置。max_duration_secs统计的是会话生命期内的累计执行时间并且会被序列化进快照。预算花完后之后每次feed_run都会立即以同样的TimeoutError失败——你换什么代码跑都过不了。这正是不可信的核心含义不是这个会话里的数据错了而是承载数据的堆本身处于未定义状态。三、实现层面不可捕获异常如何产生 错误从解释器内部转换而来内存/时间错误被包装成UncatchableExc递归错误走普通的Exc分支三者在 resource_checks.rs 中完成映射。错误定义ResourceError枚举位于 resource.rs其注释直接点明设计意图除Recursion外的所有变体在沙箱内不可捕获不可信代码绝不应拦截资源强制。此外还有两层防线大结果预检查。对结果规模可预判的操作序列重复、整数乘方、str.replace等Monty 在分配之前就按 100 KB 阈值预检x * 10**12会立即失败而不是先吃光机器内存。硬上限兜底。软限制之上还有一道硬天花板为异常机制本身预留内存击穿硬上限的 worker 会以专用退出码OOM_EXIT_CODE 65见 resource.rs退出宿主据此报告MemoryError而不是难以归类的SIGABRT。四、丢弃策略谁负责、怎么丢 ️这是新手最容易踩坑的地方——Monty 的池子pool不会替你丢弃会话超限后checkout保持打开甚至能继续接受feed_run调用。时间预算耗尽后每次都会失败但内存超限后后续调用可能在不可信堆上安静地成功——结果看似正常实则不可靠。正确的做法是结束丢弃该会话由你负责。这是宿主的义务不是池子的职责。Worker 进程本身可以复用。会话与进程是两层会话因堆状态不可信而作废而 worker 进程会被池子替换或直接复用于下一个 checkout。软超限的 worker 依然有响应只是这个会话没救了。唯一的例外是RecursionError捕获它不会使任何东西失效执行可以正常继续。五、实践清单触发限制后该做什么 ✅捕获到会话级MemoryError/TimeoutError后立即关闭该 checkout不要重试、不要复用。新建一个 checkout 重跑任务如果任务依赖中间状态优先使用快照恢复注意时间预算会随快照延续不是从零开始。为不可信代码同时设置max_duration_secs和池的request_timeout——前者管累计预算后者管单轮硬超时。RecursionError不需要丢弃会话按 CPython 习惯捕获处理即可。给max_memory留余量它统计的是分配器请求字节数不是进程 RSS。延伸阅读 面向用户的资源限制总览含超限之后一节docs/resource-limits.md内部机制详解软/硬限制、worker 生命周期、退出码语义limitations/resource_limits.md预检查与不可捕获错误转换的源码crates/monty/src/resource_checks.rs限制行为对应的测试crates/monty/tests/resource_limits.rs一句话总结Monty 的资源错误是对会话的死刑而不是对语句的警告——堆状态一旦受污染就无法自证清白丢弃会话不是惩罚而是唯一的正确操作。【免费下载链接】montyA minimal, secure Python interpreter written in Rust for use by AI项目地址: https://gitcode.com/GitHub_Trending/monty3/monty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 为什么Monty资源限制触发后会话不可信？终端错误语义与丢弃策略详解
为什么Monty资源限制触发后会话不可信终端错误语义与丢弃策略详解【免费下载链接】montyA minimal, secure Python interpreter written in Rust for use by AI项目地址: https://gitcode.com/GitHub_Trending/monty3/montyMonty 是一个用 Rust 编写的、面向 AI 的最小化安全 Python 解释器。当不可信代码触发它的资源限制内存、执行时间或递归深度时Monty 会把该会话标记为终态terminal沙箱代码无法捕获这类错误堆状态和引用计数不再受任何保证宿主必须丢弃整个会话而不是继续在上面运行代码。本文用通俗的方式解释这套终端错误语义背后的原因以及正确的丢弃策略。一、先认识 Monty 的三道资源闸门 Monty 为每个会话session独立配置三道闸门防止不可信代码永远分配或永远循环闸门配置项超限时抛出的异常沙箱内能否捕获内存max_memory字节MemoryError❌ 不能执行时间max_duration_secs秒累计TimeoutError❌ 不能递归深度max_recursion_depth默认 1000 帧RecursionError✅ 可以 关键设计前两种错误对沙箱代码不可捕获。不可信代码绝不应该能拦截资源强制机制——如果它能try/except MemoryError后继续分配资源限制就形同虚设。只有RecursionError保持可捕获与 CPython 行为一致捕获后可安全继续执行。二、终端错误意味着什么内存或时间限制触发后错误被定义为终态的terminal不是事务性的。执行不是事务操作超限指令被中断时堆上可能已经留下一半分配了一半的对象、写了一半的结构。堆状态不再可信。官方文档明确写道一旦超限触发堆上可能残留引用计数错误的孤儿对象orphaned objects with wrong refcounts。后续任何代码的分配、回收都可能踩到这些地雷且表现不可预测。预算是累计的无法重置。max_duration_secs统计的是会话生命期内的累计执行时间并且会被序列化进快照。预算花完后之后每次feed_run都会立即以同样的TimeoutError失败——你换什么代码跑都过不了。这正是不可信的核心含义不是这个会话里的数据错了而是承载数据的堆本身处于未定义状态。三、实现层面不可捕获异常如何产生 错误从解释器内部转换而来内存/时间错误被包装成UncatchableExc递归错误走普通的Exc分支三者在 resource_checks.rs 中完成映射。错误定义ResourceError枚举位于 resource.rs其注释直接点明设计意图除Recursion外的所有变体在沙箱内不可捕获不可信代码绝不应拦截资源强制。此外还有两层防线大结果预检查。对结果规模可预判的操作序列重复、整数乘方、str.replace等Monty 在分配之前就按 100 KB 阈值预检x * 10**12会立即失败而不是先吃光机器内存。硬上限兜底。软限制之上还有一道硬天花板为异常机制本身预留内存击穿硬上限的 worker 会以专用退出码OOM_EXIT_CODE 65见 resource.rs退出宿主据此报告MemoryError而不是难以归类的SIGABRT。四、丢弃策略谁负责、怎么丢 ️这是新手最容易踩坑的地方——Monty 的池子pool不会替你丢弃会话超限后checkout保持打开甚至能继续接受feed_run调用。时间预算耗尽后每次都会失败但内存超限后后续调用可能在不可信堆上安静地成功——结果看似正常实则不可靠。正确的做法是结束丢弃该会话由你负责。这是宿主的义务不是池子的职责。Worker 进程本身可以复用。会话与进程是两层会话因堆状态不可信而作废而 worker 进程会被池子替换或直接复用于下一个 checkout。软超限的 worker 依然有响应只是这个会话没救了。唯一的例外是RecursionError捕获它不会使任何东西失效执行可以正常继续。五、实践清单触发限制后该做什么 ✅捕获到会话级MemoryError/TimeoutError后立即关闭该 checkout不要重试、不要复用。新建一个 checkout 重跑任务如果任务依赖中间状态优先使用快照恢复注意时间预算会随快照延续不是从零开始。为不可信代码同时设置max_duration_secs和池的request_timeout——前者管累计预算后者管单轮硬超时。RecursionError不需要丢弃会话按 CPython 习惯捕获处理即可。给max_memory留余量它统计的是分配器请求字节数不是进程 RSS。延伸阅读 面向用户的资源限制总览含超限之后一节docs/resource-limits.md内部机制详解软/硬限制、worker 生命周期、退出码语义limitations/resource_limits.md预检查与不可捕获错误转换的源码crates/monty/src/resource_checks.rs限制行为对应的测试crates/monty/tests/resource_limits.rs一句话总结Monty 的资源错误是对会话的死刑而不是对语句的警告——堆状态一旦受污染就无法自证清白丢弃会话不是惩罚而是唯一的正确操作。【免费下载链接】montyA minimal, secure Python interpreter written in Rust for use by AI项目地址: https://gitcode.com/GitHub_Trending/monty3/monty创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考