Go:一次 exit code 是 137 且 无 coredump 的排错经历

博客讲述了作者在调试Go程序时遇到的进程异常退出问题,退出码为137且无coredump生成。经过排查,发现并非代码BUG,而是由于内存使用超标触发了操作系统的OOM killer。通过分析系统日志确认了进程因内存耗尽被SIGKILL信号杀死,从而没有生成coredump。作者通过简化代码复现了问题,并给出了内存占用与退出码137之间的关联。最后提醒读者在遇到类似问题时,应检查系统日志和内存使用情况。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Go:一次 exit code 是 137 且 无 coredump 的排错经历


最近在调试一个 Go 写的网关,总是莫名其妙地出现重启。

我以为是我写代码有 BUG 引发 panic 导致进程退出,我想借助 coredump 定位问题。

但是,在我设置如下后:

1.$ ulimit -c unlimited
2.$ export GOTRACEBACK=crash

更多参考:https://blog.csdn.net/test1280/article/details/112570784

在进程异常退出时,我没能找到 panic 输出,也没找到 coredump,如下:

...(一些前台终端日志输出)
已杀死
$ 

初时,我以为是 ulimit -c 或是 GOTRACEBACK 有问题,但是单独执行:

package main

func main() {
	panic("test1280-panic info")
}
$ go run main.go 
panic: test1280-panic info

goroutine 1 [running]:
panic(0x466460, 0x48a298)
...
signal: aborted (core dumped)
$ file core*
core.25321: ELF 64-bit LSB core file x86-64, version 1 (SYSV), SVR4-style, from '/tmp/go-build3230483068/b001/exe/main'

可以正常地、如期地在 panic 时生成 coredump 文件。

可见并非是 ulimit -c 或 GOTRACEBACK 设置问题引起。

那问题就是在代码本身?

紧接着我又查看了 exit code。

我们知道,进程在消亡时,总会有一个 exit code 存在,记录进程消亡原因。

通过 echo $? 可以查看上一个命令(进程)的 exit code。

我是将此网关启动在前台,等网关进程异常退出,然后执行 echo $?

$ ./gateway
...(一些前台终端日志输出)
已杀死
$ echo $?
137

关键线索:退出码 137!

Google:golang exit code 137 no coredump

我查到一个提问:Process finished with exit code 137 in PyCharm

里面有一个回复

Exit code 137 means that your process was killed by (signal 9) SIGKILL.
In most of the cases, it is caused by excessive memory usage.

exit code = 137,且 “已杀死”,指的是进程被 SIGKILL 信号干掉了。

而大多数情况下是因为内存使用超标导致(OOM),操作系统使用 SIGKILL 杀死进程。

!!!醍醐灌顶。赶快测试:

一边 tail -f /var/log/messages ,一边启动网关复现问题,果不其然,稍等片刻:

Feb 16 16:00:32 test1280 kernel: Out of memory: Kill process 20820 (gateway) score 100 or sacrifice child
Feb 16 16:00:32 test1280 kernel: Killed process 20820 (gateway) total-vm:3675256kB, anon-rss:804648kB, file-rss:124kB, shmem-rss:0kB

当前系统内存占用:【free 133MB】

$  free -h
              total        used        free      shared  buff/cache   available
Mem:           7.6G        6.1G        133M         13M        1.4G        762M
Swap:            0B          0B          0B

真相终于揭晓:

并非是 Go 写的网关代码存在BUG,而是:
网关占用本剩余不多的内存触发OOM(虽然网关占用内存很少),被操作系统SIGKILL杀死。

被 SIGKILL 杀死,当然是没有 coredump 的。

用 C 复现测试一下:

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define SIZE 1024*1024*1024

int main()
{
	void *p = malloc(SIZE);
	memset(p, 0, SIZE);
	sleep(60);
	return 0;
}
$ gcc -o main main.c
$ ./main
已杀死
$

此时,/var/log/message 可以观察到:

Feb 16 17:26:58 test1280 kernel: Out of memory: Kill process 28012 (main) score 98 or sacrifice child
Feb 16 17:26:58 test1280 kernel: Killed process 28012 (main) total-vm:1052748kB, anon-rss:788564kB, file-rss:52kB, shmem-rss:0kB

如果降低内存申请:(SIZE 由 1G 改为 10B)

#include <stdio.h>
#include <stdlib.h>
#include <string.h>

#define SIZE 10

int main()
{
	void *p = malloc(SIZE);
	memset(p, 0, SIZE);
	sleep(60);
	return 0;
}
$ gcc -o main main.c
$ ./main
$ 【sleep 60s 后正常结束】

总结:

如果你的代码在运行时异常退出且出现“已杀死”,查看 exit code 是 137 时:

不一定是你的代码有 BUG,可能是操作系统内存不足,你的进程被 OOM kill 掉啦。

赶快检查下 /var/log/message 吧!


https://stackoverflow.com/a/50910479
https://stackoverflow.com/questions/43268156/process-finished-with-exit-code-137-in-pycharm


后记

后面发现,确实是我写的网关有内存泄漏问题,占用大约2GB内存。

### PyCharm 进程结束退出代码137 的原因分析 当遇到 PyCharm 中进程意外终止并返回特定的退出代码时,通常意味着应用程序遇到了某种类型的致命错误或资源不足情况。对于退出代码 137 特指操作系统强制杀死了该进程[^4]。 在 Linux 和 Unix 类似系统上,退出码 137 表明进程被 SIGKILL 杀死。这可能是由于内存耗尽或其他系统级别的限制触发了操作系统的 OOM(Out Of Memory)杀手机制所致。而在 Windows 上虽然不太常见报告此确切数值作为退出状态,但也可能因为类似的底层问题引起。 针对此类情形可以考虑以下几个方面来排查和解决问题: #### 增加可用物理内存/交换空间 如果项目规模较大或者配置不当导致占用过多RAM,则尝试增加机器本身的 RAM 或者设置更大的 swap 文件大小可以帮助缓解因内存压力造成的崩溃现象。 #### 检查是否存在无限循环或者其他可能导致高负载的操作 审查代码逻辑确保没有不必要的长时间运行的任务或是递归调用过深等问题存在;优化算法效率减少不必要的计算开销也能有效降低发生这种情况的概率。 #### 更新软件版本至最新稳定发布版 有时旧版本可能存在某些 bug 导致不稳定行为,在官方维护团队修复之后的新发行版里这些问题往往已经被修正过了所以保持 IDE 及其插件处于更新状态总是好的实践之一。 ```bash # 查看当前使用的 Python 解释器及其库是否为最新版本 pip list --outdated ``` #### 配置合适的 JVM 参数调整堆栈大小等参数 对于基于 Java 构建的应用程序比如 IntelliJ IDEA 平台下的 PyCharm ,适当调节启动选项中的 `-Xms` , `-Xmx` 关键字指定初始与最大允许分配给虚拟机的空间量级有助于提高稳定性表现。 ```properties # 修改 idea.properties 文件内相应条目 idea.max.intellisense.filesize=2500 idea.heap.size=2g ```
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值