FIFO管道与fork实现C/S通信项目关闭客户端时服务器段错误修复

客户端关闭时服务端触发Segmentation fault (core dumped) #

• 优先校验FIFO读操作返回值的处理逻辑：
  • 客户端进程退出时，对应专属FIFO的所有写端会被关闭，服务端调用read()读取该FIFO时会返回0（EOF）。如果代码未对返回0的分支做处理，反而继续操作读缓冲区、解析客户端上下文（如昵称、进程ID），会直接触发空指针或野指针访问。
  • 公共FIFO逻辑同理：所有客户端退出时公共FIFO写端全部关闭，服务端读取得到EOF后未做退出/重试处理的话，继续操作读缓冲区会触发非法内存访问。
• 排查客户端上下文管理逻辑：
  • 服务端维护的已登录客户端链表/数组中，若客户端退出后未及时释放对应结构体内存、移除链表节点，后续遍历或下发消息时访问已释放内存，会触发use-after-free类型的段错误。
• 检查FIFO文件描述符引用计数：
  • 若服务端通过fork()派生子进程处理客户端通信，父进程未及时关闭子进程继承的多余FIFO读写端，会导致FIFO引用计数不随客户端退出归零，后续读写逻辑出现不可预期行为，最终触发内存非法访问。
• 排除SIGPIPE信号干扰：
  • 若未显式设置signal(SIGPIPE, SIG_IGN)，服务端向已关闭的客户端专属FIFO写数据时会被默认的SIGPIPE信号终止，可先添加该逻辑排除信号类崩溃的干扰。
• 快速定位方法：
  • 若已开启core dump，执行gdb ./projectname core加载核心转储文件，直接查看触发段错误的调用栈和非法访问地址，可快速定位问题代码行。

登录校验逻辑导致父进程死循环发消息 #

• 明确fork()的地址空间特性：
  • fork()创建的子进程拥有独立地址空间（写时复制），子进程修改的普通变量、全局变量，父进程无法直接读取。若此前逻辑为“子进程修改校验结果变量，父进程直接读取该变量判断合法性”，必然无法获取正确结果。
• 检查父子进程同步与结果传递逻辑：
  • 传递校验结果必须使用IPC机制：可在fork()前创建匿名管道，子进程将校验结果写入管道，父进程从管道读取；或通过信号、共享内存等机制完成父子进程的信息交互。
  • 必须显式调用waitpid()回收校验子进程：若父进程未等待校验子进程退出，会直接跳过校验流程进入发消息的while(1)循环，此时校验流程未执行完成，自然会持续发送未校验的消息。
• 校验循环进入条件：
  • 确认发消息的while(1)循环是否绑定“校验成功”的标志位：若此前逻辑为“无论校验结果如何直接进入发消息循环”，即使修复了父子进程的结果传递，也会出现未登录即发消息的问题。

内容的提问来源于stack exchange，提问作者Invirs