为什么没有无法捕获的 coredump 信号？
我最近遇到一个应用程序冻结在 SIGABRT 处理程序中，没有注册其他信号来立即进行核心转储。在我们标准化留下 SIGSTOP、SIGABRT、SIGTRAP 等之一之前，我们将只使用 gcore 和 SIGKILL，但考虑到损坏的处理是问题所在，我想知道为什么除了 SIGSTOP 和 SIGKILL 之外没有一个标准的 SIGCORE不能被捕获或忽视。有谁知道为什么要添加或不应该添加一个？
I recently came across an app that froze in a SIGABRT handler with no other signal registered to immediately core dump. Until we standardize leaving one of SIGSTOP, SIGABRT, SIGTRAP, etc., alone, we'll just use gcore and SIGKILL, but given that broken handling was the issue, I wondered why there isn't along with SIGSTOP and SIGKILL a standard SIGCORE that can't be caught or ignored. Does anyone know why one was or should not be added?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
一个原因可能是程序员有办法避免执行标准错误处理程序。有时，标准处理程序可能是“错误的”（例如，“核心”文件创建可能很慢，或者由于磁盘空间泄漏而昂贵）。对于每个“合理”“标准”故障行为，都有一个应用程序（或者可能是程序员）认为最好更改它......
A reason may be that the programmer has a way to avoid the execution of the standard fault handler. Sometimes the standard handler may be "wrong" (e.g. the "core" file cration may be slow, or expensive because of leak of disk space). For every "reasonable" "standard" fault behaviour, there is an application (or perhaps a programmer) that thinks it's better to change it...