本文为ROS调试工具的笔记主要聚焦于代码调试部分日志、GDB、Valgrind 调试工具概览ROS集成了丰富的调试工具主要分为以下几类代码调试GDB、valgrind、日志可视化调试rqt_graph网络拓扑、rqt_console消息、rqt_logger_level日志、RVIZ三维可视化、rqt_plot趋势图单元测试Cgtest、Pythonnosetests通信调试rostopic、rosbag系统检查roswtf、rosnode、rosservice、rosparam系统仿真URDF、Gazebo 代码调试1. 日志调试日志等级严重程度递增DEBUG→INFO→WARN→ERROR→FATAL对应宏ROS_DEBUG、ROS_INFO、ROS_WARN、ROS_ERROR、ROS_FATAL日志位置默认路径~/.ros/log可通过设置环境变量ROS_LOG_DIR修改建议在~/.bashrc中配置2. GDB 调试GDB 是 C/C 调试工具用于设置断点、查看变量和环境。进入调试模式catkin config-DCMAKE_BUILD_TYPEDebug三种调试方式命令行调试在 launch 文件中配置nodenameclientpkgexample_3typeclientoutputscreenlaunch-prefixxterm -e gdb --args/注xterm -e会新建终端执行 GDBVSCode 可视化调试配置launch.json中的program项通过菜单运行 → 启动调试开始配置示例launch.json{version:0.2.0,configurations:[{name:Debug,type:cppdbg,request:launch,program:${workspaceRoot}/devel/lib/example_1/hello,cwd:.}]}开始调试设置断点启动 Master 节点点击运行 → 启动调试3. Valgrind 调试Valgrind 通过模拟 CPU 运行配合插件进行内存和性能分析。常用插件Memcheck检测内存泄漏、非法内存访问Callgrind函数调用关系分析Cachegrind缓存命中/丢失分析Helgrind多线程竞争分析Massif堆栈内存分析在 launch 文件中配置 Valgrindnodenamehellopkgexample_1typehellooutputscreenlaunch-prefixvalgrind --leak-checkfull --show-leak-kindsall/常用参数说明--track-originsyes显示未定义变量的来源--leak-checkno|summary|full内存泄漏检查级别--show-leak-kindsall显示所有泄漏类型总结日志调试快速定位代码流程和错误等级GDB调试深入分析逻辑错误和运行时状态Valgrind调试检测内存问题及性能瓶颈下面内容是关于Valgrind 调试的实际运行示例与输出解读。 Valgrind 调试实战1. 启动带 Valgrind 的 ROS 节点在终端中首先确保已编译调试版本并加载环境然后通过 launch 文件启动节点该文件已配置launch-prefix调用 Valgrindcd~/catkin_wssourcedevel/setup.bash roslaunch example_1 valgrind.launch示例输出ros/1og/3b5151ec-9053-11eb-8ff2-ef0b09d08f9d/ros1 sk usage. This may take a while. sage. Usage is 1GB.注部分输出可能因系统或日志记录而异重点是 Valgrind 会在后台运行并生成分析报告2. 理解 Valgrind 内存泄漏报告当节点运行结束或退出时Valgrind 会输出内存检查摘要。以下是一个典型的Memcheck 报告来自 IMG_446610153 LEAK SUMMARY: 10153 definitely lost: 11,000 bytes in 11 blocks 10153 indirectly lost: 0 bytes in 0 blocks 10153 possibly lost: 0 bytes in 0 blocks 10153 still reachable: 3,037 bytes in 40 blocks 10153 suppressed: 0 bytes in 0 blocks 10153 10153 ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)各项含义definitely lost明确泄漏的内存程序运行结束后仍然没有被释放且没有指针指向它们。这是最需要关注的部分。indirectly lost由于父块泄漏而导致依赖块无法释放通常与数据结构如链表有关。possibly lost可能泄漏指针指向内存块的某个位置而非起始位置导致释放困难一般也需要检查。still reachable内存尚未释放但仍有指针指向它们程序退出时通常由操作系统回收。虽然不算严格泄漏但长时间运行的程序应避免累积。suppressed被抑制的错误通常是因为 Valgrind 的 suppression 文件过滤了某些已知问题。错误统计ERROR SUMMARY: 1 errors from 1 contexts表示检测到 1 个内存错误例如非法读写或泄漏开发者应据此定位代码。3. 如何定位泄漏代码若要获取更详细的泄漏位置需在 launch 文件中添加更详细的 Valgrind 选项例如node...launch-prefixvalgrind --leak-checkfull --show-leak-kindsall --track-originsyes --verbose/--verbose可输出更多信息包括每个泄漏的调用栈。结合调试符号编译时加-gValgrind 会指出泄漏发生的源文件和行号。4. 根据报告修复问题definitely lost检查所有new/malloc是否有对应的delete/free尤其是在异常路径或提前返回处。still reachable若程序生命周期内需要长期保留如全局单例可忽略否则应确保在合适时机释放。重新编译并再次运行 Valgrind验证泄漏是否消除。 小结Valgrind 的 Memcheck 是定位内存问题的利器通过--leak-checkfull可获得详细报告。在 ROS 中通过 launch 文件的launch-prefix集成 Valgrind无需修改代码即可检测节点内存状况。报告中的 “definitely lost” 是必须修复的硬伤“still reachable” 视情况而定。