如何区分Python中MLE与空指针引发的SIGSEGV终止信号

用Cgroup替代setrlimit()做内存限制（最可靠） #

Linux的Cgroup内存控制比Python的resource.setrlimit()更精准，进程超出内存限制时会被OOM Killer发送SIGKILL（返回码-9），和空指针解引用触发的SIGSEGV（返回码-11）能明确区分：

• 创建临时Cgroup，配置memory.limit_in_bytes为设定的内存阈值
• 将被测进程加入该Cgroup后启动
• 进程终止后检查返回信号：返回码为-9则判定为MLE，-11则判定为普通运行时错误
• 评测完成后销毁临时Cgroup，避免资源残留

用Ptrace跟踪内存分配系统调用 #

通过Ptrace监控被测进程的内存分配操作，判断崩溃是否由内存分配失败导致：

• 在子进程启动时附加Ptrace
• 拦截所有系统调用，重点监控brk、mmap等内存分配相关调用：
  • 若内存分配返回ENOMEM错误，且进程后续因SIGSEGV终止，判定为MLE
  • 若内存分配成功后触发SIGSEGV，则判定为普通运行时错误
• 注意：Ptrace会带来一定性能开销，需根据评测规模权衡效率

给被测代码添加内存分配失败处理（仅限可控场景） #

若允许对用户提交的代码做微小修改（竞赛平台通常不适用，仅特殊场景可用）：

• 重载malloc/new函数，当内存分配失败时主动触发自定义信号（如SIGUSR1），或使用特定退出码终止进程
• 评测系统捕获到自定义信号/退出码时，直接判定为MLE
• 局限性：竞赛平台无法修改用户提交的代码，该方法实用性有限

额外提醒 #

• 放弃使用resource.getrusage()：进程因内存超限崩溃时，内核往往来不及更新rusage数据，获取到的内存使用量会低于限制值，无法作为判定依据
• 若坚持使用RLIMIT_AS：部分场景下进程会因内存分配失败拿到NULL指针，后续解引用才触发SIGSEGV，仅靠返回信号无法区分，必须结合系统调用日志判断

内容的提问来源于stack exchange，提问作者Saad Ahmed