Valgrind环境下父子进程SIGUSR1信号通信异常及信号机制咨询

Valgrind确实存在会改变信号传递行为、拉高信号投递延迟的模拟机制，你遇到的子进程偶发收不到起始SIGUSR1的问题，本质是自身代码的时序逻辑存在先天漏洞——这类漏洞在原生高速执行环境下触发概率极低，几乎观测不到，而Valgrind的慢执行特性会把这个漏洞的触发概率放大到可观的偶发级别。

Valgrind对信号通信的特有影响 #

• Valgrind不会直接走内核原生的信号硬投递路径，所有跨进程的信号都要经过Valgrind自身的调度层拦截、做进程状态检查、再转发到对应的被监控进程，天生比原生环境的信号投递延迟高几个数量级，原本微秒级的时序等待窗口会被拉长到毫秒级，大幅提升时序错位的概率。
• Valgrind在处理fork()、execve()生成的子进程时，会在子进程初始化阶段临时同步信号表状态、临时阻塞部分非强制处理的信号。如果这时候收到父进程发来的SIGUSR1，因为子进程还没完成对应handler的注册，信号会被直接丢弃，或者触发默认的终止动作，不会进入待投递队列。
• Valgrind的信号模拟逻辑和内核原生语义存在差异，普通非实时信号不会像内核那样做可靠的不丢失投递，重复发送的同类信号会被直接合并覆盖。

现有代码存在的时序漏洞 #

这些问题在原生环境下几乎不会被触发，放到Valgrind的慢执行场景下就会变成高频偶发问题：

• 父进程全程盲发信号无同步：你的父进程是先循环fork完80个子进程，才开始逐个给子进程发SIGUSR1，但子进程从被fork出来，到执行完init_signal()注册handler、打印日志、最后进入sigsuspend()等待态，中间没有任何就绪反馈。如果父进程发SIGUSR1的时候，子进程还没完成信号handler的注册，此时SIGUSR1的默认动作是终止进程，子进程会直接被信号杀死，根本等不到挂起等待的步骤。
• 缺少双向就绪握手：子进程进入sigsuspend之前没有给父进程发任何通知，父进程完全不知道每个子进程已经准备好接收信号，信号投递时间点和子进程就绪时间点存在天然的错位可能。
• 错误的状态检查逻辑：你在父进程里写完kill(children[i], SIGUSR1)之后直接打印strerror(errno)，但errno只有系统调用失败时才会被重置，如果kill调用成功，errno会保留上一次系统调用的旧值，你根本从日志里看不到kill是不是真的投递成功，也没法判断子进程是不是已经提前退出。
• 信号本身不排队：如果父进程发的SIGUSR1刚好在子进程还没阻塞SIGUSR1、还没进入sigsuspend的间隙被投递，信号触发完handler就会被内核清除，等子进程真正挂到sigsuspend上等待时，已经没有待处理的信号，就会永久卡在等待态，表现为收不到起始SIGUSR1。

可落地的修复方向 #

• 增加就绪握手逻辑：子进程完成信号注册、确认进入接收状态后，先给对应父进程发送一个“就绪”信号；父进程收到某一个子进程的就绪信号后，再给这个子进程发送起始SIGUSR1，彻底消除时序错位的窗口。
• 对kill()的返回值做严格检查，识别ESRCH（子进程不存在）、EPERM（无发送权限）等错误，不要沿用旧的errno值做状态判断。
• 可以考虑将跨进程的信号换成实时信号，这类信号会被内核可靠排队投递，减少信号被覆盖丢失的概率。

内容的提问来源于stack exchange，提问作者tango-1