如果收到段错误信号，我的应用程序通常会崩溃并打印堆栈以记录。
但在某些环境中，“dmesg”显示与我的应用程序相关的段错误消息，但应用程序的正常运行时间要长得多。
段错误是否可以被抑制，应用程序不会收到信号？或者 dmesg 的错误可能意味着什么？
答案1
应用程序可以忽略或对分段错误信号进行一些特殊处理。信号手册页和相关页面对此有详细说明。
我发现一种可能导致上述行为（dmesg 报告分段错误但应用程序正在运行）的情况是应用程序分叉并且子进程分段错误。要知道是否是这种情况，请检查 dmesg 报告的进程 ID 是否与当前正在运行的进程的进程 ID 相同。
答案2
在后台运行的程序可以很好地处理 SIGSEGV，只要记录它发生的事实以及退出前的上下文即可。这不仅可以在日志文件中指示出了什么问题，还可以提供有用的信息以包含在错误报告中。是的，可以忽略该信号，但这只能通过故意的操作来实现，而且几乎总是一个坏主意（除非您在具有已知有缺陷的 vmm 子系统的实验性内核下进行测试）。
不幸的是，一旦捕获该信号，任何事情都值得怀疑。例如，使用在 SEGV 处理程序中分配内存的任何东西都很可能是一个坏主意。对于 printf() 等可变函数也是如此。所以是的，当应用程序正在处理信号时，它可能无法有效地处理，因此您只能在 dmesg 中看到它的痕迹。
无论如何，是的，信号被发送到应用程序，但是 SEGV 不是实时信号，并且可以合并由内核执行。也就是说，如果一个程序访问了它无权访问的内存 15 次，那么很有可能只有一SEGV 是否会真正被传送，取决于非法内存访问的时间。
在 SEGV 处理程序中，open() write() 和 close() 是您的朋友并使用特殊的调试日志（即，不是可能先前打开的日志记录 FILE 流）。
答案3
如果进程对内存做了不该做的事情，内核会自动发送 SIGSEGV；但可以捕获该信号，进程可以运行信号处理程序，以尝试从故障状态中恢复。在这种情况下，进程可以继续运行。
该信号也可以完全被忽略，但这是应该避免的；收到 SIGSEGV 通常意味着发生了一些非常非常错误的事情。
答案4
分段错误通常意味着应用程序内部状态出现严重错误。它可能已经严重损坏，无法运行信号处理程序 - 本来应该打印堆栈转储的信号处理程序也可能崩溃。
编辑：我不太理解“正常运行时间较旧”部分，所以我跳过了它。现在我看到你的问题是“为什么应用程序仍在运行”，所以这里是新的答案：
是的，应用程序可以经受住 SIGSEGV 的攻击。有时 SIGSEGV 只会发送给一些不太重要的线程（它应该会终止整个应用程序，但有时不会），甚至只是一个子进程——您看到的一个应用程序可能是多个进程或线程。