我的应用程序通常崩溃并打印堆栈以logging收到的段错误信号。
但是在某些环境中，'dmesg'显示了与我的应用程序相关的段错误消息，但是应用程序的正常运行时间要长得多。
segfault可以抑制和应用程序不接收信号？ 或者来自dmesg的错误可能意味着什么？
应用程序可能会忽略或为分段故障信号做一些特殊处理。 信号和相关页面的手册页上有详细的信息。
我看到的一种可能的情况可能导致描述的行为（dmesg报告段错误，但应用程序正在运行）是应用程序分叉和subprocess段错误。 要知道是否属于这种情况，请检查dmesg报告的进程ID是否与当前正在运行的进程相同。
在后台运行的程序可以很好地处理SIGSEGV，只要logging它在退出之前发生的情况。 这不仅给出了日志文件中出现错误的指示，而且还提供了包含在错误报告中的有用信息。 是的，信号可以被忽略，但这只是通过故意的行动，几乎总是一个坏主意（除非你正在一个已知的越野车vmm子系统的实验内核下进行testing）。
不幸的是，一旦这个信号被发现，任何事情都是可疑的。 例如，使用任何在SEGV处理程序中分配内存的东西很可能是一个坏主意。 像printf（）这样的可变参数也是一样的。 所以，是的，当一个应用程序正在处理信号，它可能不是有效的，因此你只能看到它在dmesg中的痕迹。
无论如何，是的，信号被发送到应用程序，但是SEGV不是实时信号，可以被内核合并 。 也就是说，如果一个程序访问内存没有权限访问15次，根据非法内存访问的时间，很可能只有一个 SEGV实际被传送。
在SEGV处理程序中，open（）write（）和close（）是你的朋友，并使用特殊的debugging日志（即不是先前可能已打开的日志文件stream）。
内核自动发送SIGSEGV，如果一个进程做了一些内存不应该做的事情; 但信号可能被困住，并且该过程可以运行一个信号处理程序，它可能会尝试从故障状态中恢复。 在这种情况下，该过程可以继续运行。
信号也可以完全忽略，但这是应该避免的。 得到一个SIGSEGV通常意味着有一些真正的错误。
细分故障通常意味着应用程序内部状态出现了一些问题。 它可能被破坏了，它不能运行信号处理程序 – 信号处理程序，应该打印堆栈转储，也可能会崩溃。
编辑：我不太了解'正常运行时间'部分，所以我跳过它。 现在我看到你的问题是“为什么应用程序仍在运行”，所以这里是新的答案：
是的，应用程序可以在SIGSEGV中生存下来。 有时候，SIGSEGV只会被发送给一些不那么重要的线程（它应该终止整个应用程序，但有时候不会），甚至只是一个subprocess – 你看到的一个应用程序可能是多个进程或线程。