保姆级教程：用GDB调试SRS 4.0，快速定位RTMP推流失败问题
保姆级教程：用GDB调试SRS 4.0，快速定位RTMP推流失败问题
直播业务中遇到RTMP推流频繁失败，但日志信息有限怎么办？本文将带你深入SRS 4.0源码，通过GDB调试实战，从TCP连接到RTMP握手再到音视频数据接收，逐层排查问题根源。无需猜测，直接定位协议解析错误、网络超时或资源竞争等具体原因。
1. 环境准备与问题复现
在开始调试前，我们需要搭建一个可调试的SRS环境。建议使用Ubuntu 20.04 LTS或更高版本，因为其软件包兼容性较好。以下是具体步骤：
- 编译带调试符号的SRS：
git clone https://github.com/ossrs/srs -b 4.0release cd srs/trunk ./configure --with-gdb=on --with-debug=on make -j$(nproc)- 配置基础推流测试环境：
# 启动SRS服务（前台运行方便观察日志） ./objs/srs -c conf/srs.conf # 另开终端使用FFmpeg测试推流 ffmpeg -re -i test.flv -c copy -f flv rtmp://localhost/live/stream当出现推流失败时，典型现象包括：
- FFmpeg端报错"Connection refused"或"Connection reset by peer"
- SRS日志中出现"RTMP handshake failed"等警告
- 推流连接建立后几秒内断开
关键检查点：
- 确保防火墙未阻止1935端口
- 确认SRS配置文件中
listen参数正确 - 检查系统资源（CPU/内存/网络）是否过载
2. GDB基础调试技巧
GDB是Linux下最强大的调试工具，掌握以下几个核心命令就能应对大部分调试场景：
| 命令 | 缩写 | 功能说明 |
|---|---|---|
| break | b | 设置断点 |
| run | r | 启动程序 |
| continue | c | 继续执行 |
| next | n | 单步跳过 |
| step | s | 单步进入 |
| backtrace | bt | 查看调用栈 |
| p | 打印变量 | |
| info threads | i thr | 查看线程 |
实战示例：附加到运行中的SRS进程
# 查找SRS主进程ID ps aux | grep srs # 使用GDB附加进程 sudo gdb -p <pid> # 在GDB中加载调试符号 (gdb) symbol-file ./objs/srs注意：生产环境调试时，建议先将流量切换到备用节点，避免影响线上服务。
3. RTMP连接建立过程调试
RTMP推流失败最常见于连接建立阶段，我们需要重点关注以下几个关键类和方法：
SrsRtmpConn：处理RTMP连接的核心类SrsRtmpServer::do_cycle()：连接生命周期管理SrsProtocol::handshake()：握手协议实现
设置关键断点：
(gdb) b SrsRtmpConn::service_cycle (gdb) b SrsProtocol::handshake (gdb) b SrsRtmpServer::do_cycle当客户端尝试连接时，GDB会在断点处暂停。此时可以：
- 查看连接信息：
(gdb) p conn->get_client_ip() (gdb) p conn->get_server_port()- 跟踪握手过程：
# 进入handshake函数后单步执行 (gdb) s (gdb) n # 检查握手状态 (gdb) p handshake_state常见问题定位：
- 如果
handshake_state卡在SRS_RTMP_HANDSHAKE_C0，通常是网络问题 - 如果报
SRS_RTMP_HANDSHAKE_INVALID，可能是协议版本不匹配 - 如果连接在握手后立即断开，检查
SrsRtmpConn::stream_service_cycle
4. 推流数据处理调试
当连接建立成功但推流数据异常时，需要关注以下关键点：
- 媒体数据接收：
(gdb) b SrsRtmpConn::on_receive_message (gdb) b SrsProtocol::recv_message- 关键数据结构检查：
# 查看接收到的消息类型 (gdb) p msg->header.message_type # 检查时间戳 (gdb) p msg->header.timestamp # 查看负载大小 (gdb) p msg->payload->length典型问题分析：
视频数据丢失： 检查
message_type是否为SRS_RTMP_TYPE_VIDEO，确认payload->length大于0音频视频不同步： 比较音视频包的
timestamp差值是否在合理范围内数据包不完整： 检查
SrsProtocol::recv_interlaced_message中的chunk_size设置
5. 高级调试技巧
对于更复杂的问题，可能需要以下进阶方法：
多线程调试：
# 查看所有线程 (gdb) info threads # 切换到特定线程 (gdb) thread <id> # 查看线程调用栈 (gdb) bt条件断点：
# 只在特定客户端IP触发断点 (gdb) b SrsRtmpConn::service_cycle if strcmp(conn->get_client_ip(), "192.168.1.100") == 0内存检查：
# 检查内存泄漏 (gdb) b __cxa_throw (gdb) b malloc_error_break # 查看对象内存布局 (gdb) ptype SrsRtmpConn核心转储分析：
# 生成core dump ulimit -c unlimited kill -SIGSEGV <pid> # 加载分析 gdb ./objs/srs core.<pid>6. 实战案例：推流中断问题排查
最近遇到一个典型案例：推流约5分钟后连接总是断开。通过以下步骤定位问题：
- 重现问题时抓取完整日志：
./objs/srs -c conf/srs.conf > srs.log 2>&1发现日志中有"thread cycle timeout"警告
使用GDB设置超时相关断点：
(gdb) b SrsSTCoroutine::cycle (gdb) b SrsRtmpConn::on_thread_stop发现某个线程卡在
SrsProtocol::recv_message检查网络状态确认是客户端NAT超时导致
最终解决方案是调整SRS配置中的heartbeat参数，并建议客户端优化网络环境。