目录1 信心--没有解决不了的bug2 耐心、不要着急、静下心来、用脑思考2.1 开始解决问题前不要着急先思考2.2 在解决问题的过程中也不要着急要冷静思考3 灵活运用、不要局限或痴迷于某一种方法4 不要经验主义、不要局限于以前的经验或者知识点5 网络搜索、Github搜索、善用开源的东西、善用现成的东西6 借助AI大模型6.1 以前ChatGPT、Gemini、DeepSeek、GLM、kimi、通义千问、豆包----并且是几个大模型换着用6.2 现在借助cursor、codex、claude code7 看芯片手册、SDK手册、官方demo、开源代码的源码8 寻求技术支持、技术交流群9 gdb调试9.1 集成开发环境调试:vscode、clion、visual studio等9.2 gdb命令调试9.3 硬件仿真器调试、ARM裸板调试J-Link、ST-Link、TI的XDS调试器9.4 hipgdb抓vLLM进程卡主位置10 打印10.1 应用程序的printf、cout以及第三方log10.2 驱动程序的printk、串口打印10.3 借助打印排查vLLM卡主问题10.4 借助打印排查vLLM精度问题11 利用一些工具11.1 内存泄漏分析工具工具asan、valgrind11.2 跟踪系统调用11.3 hipprof调试海光GPU的vmfault coredump13 对比调试法一次解决ffmpeg错误的方法记录14 单元测试法15 组件、算子替换法排查大模型精度问题16 挨段代码注释法17 把自己的代码再看一遍18 重启法19 整体编译法参考文献1 信心--没有解决不了的bug在解决问题前要有信心相信只要自己去做那么bug就一定能解决没有解决不了的bug在解决bug的过程中如果经过多次尝试各种方法还是没能解决也不要放弃再继续尝试说不定突然就解决了以前你的很多bug都是不放弃最终解决掉了。2 耐心、不要着急、静下心来、用脑思考2.1开始解决问题前不要着急先思考当程序遇到问题或者错误的时候不要经过思考直接去网上搜答案或者直接去调试应该先静下心来思考有哪些可能得原因是不是自己哪里配置错误而不是程序有问题比如遇到缺陷错误时别着急冷静思考-CSDN博客当整体大方向确定没问题之后再想办法去解决问题。2.2 在解决问题的过程中也不要着急要冷静思考在解决问题的过程中可能你尝试了一些方法都没能解决这时候也不要像无头苍蝇一样继续尝试各种方法而是应该静下心来思考因为你已经试了一些方法了那么你肯定对这个问题有初步的认识了那么这时候应该基于前面的尝试去考虑下这个问题最大的可能性是什么边思考边尝试而不是一股脑的着急用各种不同的方法尝试解决。3 灵活运用、不要局限或痴迷于某一种方法这些方法是要灵活运用的而不是只用一种比如之前你觉得大模型挺好用的遇到问题就去问大模型然而有时候自己网上搜索反而能找到答案还有就是用IDE调试的方法确实挺好用的但是你不能遇到问题也不思考就打开了调试器去调试然后陷到这种方法里面了有时候认真看看代码就能解决没必要直接vscode调试。4 不要经验主义、不要局限于以前的经验或者知识点不要觉得以前是怎么解决的然后这次也应该怎么怎么样不要因为经验导致一些错误的判断然后就一直走进死胡同了很多时候要抛弃经验多尝试不一样的新的方法。比如从副来看你看音p的可以直接去网上搜别人的博客找现成的开发板而不是基于自己以前的经验在那里想怎么开发I2ST41的开发板配网可以直接web而不是就只用串口的方法T41的glibc可以去github上搜还有很多算法都是可以直接去github上找到开源的东西的所以怎么说呢有时候多尝试不同的方法不要老是基于自己以前的经验去判断。5 网络搜索、Github搜索、善用开源的东西、善用现成的东西当遇到报错的时候最长想到的就是去网上搜一下这个需要注意的是尽量首选x歌然后才是x度因为x歌的搜索结果确实很节省时间有时候x度搜索前几页都没有标准答案而x歌第一条就是正确解决方法。不只是解决bug有时候对于一些未知的不知道怎么解决的不知道怎么查找资源比如从副业来看你看音p的可以直接去网上搜别人的博客找现成的开发板而不是自己想怎么开发I2ST41的glibc可以去github上搜还有很多算法都是可以直接去github上找到开源的东西的所以怎么说呢多找现成的资源多找开源的东西不要老是想着自己写不要老是想着自己解决。6 借助AI大模型6.1 以前ChatGPT、Gemini、DeepSeek、GLM、kimi、通义千问、豆包----并且是几个大模型换着用随着大模型的兴起我们遇到问题可以直接问大模型大模型相比网络搜索有时候能够省掉你的时间但是有一个需要注意的不是痴迷于大模型有时候大模型没有的自己去网上搜索反而能找到答案你最开始觉得大模型好用就什么问题直接问大模型大模型没有你觉得就懒得搜了这个意识要改掉。这里还有个问题就是每个大模型擅长的点是不一样的很多时候你遇到问题比如用GPT没法解决的用了豆包立马解决以后遇到问题要综合几个大模型一个解决不了的另一个大模型可能就帮你解决了。6.2 现在借助cursor、codex、claude code以前排查问题是把问题复制到大模型里面问有了这些ai编程工具之后可以直接用编程工具打开代码目录这样排查问题效率更高更容易发现问题7 看芯片手册、SDK手册、官方demo、开源代码的源码有时候在用一些芯片的时候如果遇到一些错误码那么可以去芯片手册看看这个错误码代表哪种类型的错误还有有时候用的接口报错那么去SDK手册里面看一下这个接口的使用条件或者传入的参数是不是有什么要求或者自己的调用流程是不是不对。还有看一下官方的demo然后是不是自己使用的跟官方的demo有什么不一样还有就是比如再用opencv、ffmpeg等这些开源代码的时候可以去看一下开源代码的源码或者他们的头文件介绍比如下面这个错误当初去看一下opencv头文件的函数介绍也许解决的效率就更高了。记帮两个同事解决的一个奇怪bug-CSDN博客8 寻求技术支持、技术交流群有时候用的是一些厂家芯片网上就没有资料那么这时候就是去找厂家的技术支持只能这样解决要不然自己摸索也不会有答案。9 gdb调试9.1 集成开发环境调试:vscode、clion、visual studio等这个是我最常用的一个方法用集成开发环境调试能够打断点看程序执行单步执行能够看到各种变量能看堆栈看函数调用层次关系特别方便但还是一个注意事项就是不要局限于这种方法有时候如果这种方法一直没能找到错误原因那就换一个虽然这个方法很好用但不要痴迷于他。使用visual studio 远程编辑和调试linux代码_visual studio 远程编译-CSDN博客ubuntu上安装vscode并远程开发与远程调试服务器代码_vscode ssh远程连接ubuntu后,怎么打开项目代码-CSDN博客vscode远程调试服务器的Python代码_vscode 远程调试python代码-CSDN博客搭建嵌入式GDB调试环境以及VSCodegdbserver 图形化调试_vscode gdbserver-CSDN博客9.2 gdb命令调试使用gdb命令调试也可以看一些变量重点是可以bt查看堆栈信息。尤其是有时候在一些小的嵌入式开发板上用集成开发环境调试不太方便的时候可以用gdb命令去调试一些错误。Linux应用调试之使用gdb和gdbserver_gdbserver安装-CSDN博客gdb调试python的segmentation fault错误_debian gdb 调试python segmentation fault-CSDN博客使用GDB调试python调用的C共享库_python 调用c语言库,如何gdb-CSDN博客Linux下生成core文件,并用gdb调试core文件/ gdb调试段错误方法_gdb a.out core-CSDN博客9.3 硬件仿真器调试、ARM裸板调试J-Link、ST-Link、TI的XDS调试器对于ARM芯片我们可以直接用硬件仿真器去调试这样能看到他内部的寄存器值也能像IDE那样单步执行查看变量的值设置断点对于ARM逻辑调试时这个硬件仿真器就很有用还有TI的硬件仿真器还可以直接抓取音频的波形还可以把内存的值保存成文件。Code Composer Studio (CCS) 集成开发环境及TI仿真器的使用_code composer studio target configurations-CSDN博客ARM裸板调试之JTAG原理-CSDN博客ARM裸板调试之JTAG调试体验_制作 arm jtag-CSDN博客ARM裸板调试之JTAG调试命令行调试_arm 如何用jtag来调试-CSDN博客ARM裸板调试之JTAG调试源码级调试_arm jtag-CSDN博客9.4 hipgdb抓vLLM进程卡主位置在做大模型推理的时候遇到vllm起服务卡主的问题然后这种情况可以用hipgdb去看程序卡主的位置的具体命令如下gdb -p pid 把 gdb 挂到已经在跑的进程上不重新启动它。等于「去看这个进程现在卡在哪」。挂上后目标进程会被暂停。 attach pid 效果同上只是写法不同先开空的 gdb再手动 attach。和 -p 二选一即可。 info threads 列出这个进程里所有线程以及每个线程当前停在什么函数/地址。 卡住问题时先扫一眼谁在 futex/poll/ioctl谁在干活。当前线程前面会有 *。 thread 1 切换到线程 1一般是主线程。后续 bt 看的就是这个线程的栈。 线程编号以 info threads 左边那列为准不一定永远是 1。 btbacktrace 打印当前线程的调用栈从最底层往上看「谁调谁最后停在哪」。 段错误时看崩溃点卡住时看它在等什么例如 hipStreamSynchronize。 thread apply all bt 对每一个线程都执行一次 bt。 适合死锁/多线程卡住一眼看清所有线程各自堵在哪避免漏掉非主线程。当然有时候这个hipgdb只能是定位卡在哪个kernel还得不到整体流程这时候需要加打印辅助找到具体的流程和卡主位置。10 打印10.1 应用程序的printf、cout以及第三方log这个不用多说了虽然已经有前面的IDE以及gdb调试了但是有些时候printf打印反而能解决一些调试没法或者不太好解决的问题打印除了打印出来变量的值以外还可以打印出来行号和函数名具体方法在下面博客C/C 中的__FILE__,__FUNCTION__,__LINE__,__DATE__,__TIME__,-CSDN博客Linux应用调试之配置修改内核打印用户态段错误信息_段错误 打印详细信息-CSDN博客10.2 驱动程序的printk、串口打印对于驱动程序可以用printk的方法进行打印调试这个printk很多时候就能帮我们解决很多问题了。Linux驱动调试之printk的原理-CSDN博客Linux驱动调试之printk的使用_linux printk-CSDN博客Linux驱动调试之打印到proc虚拟文件_linux驱动打印信息-CSDN博客ARM裸板调试之串口打印及栈初步分析_arm的串口调试-CSDN博客ARM裸板调试之点灯法_点灯法跟踪调试-CSDN博客10.3 借助打印排查vLLM卡主问题在做大模型推理的时候遇到vllm起服务卡主的问题然后这种情况可以用hipgdb去看程序卡主的位置的具体命令如下gdb -p pid 把 gdb 挂到已经在跑的进程上不重新启动它。等于「去看这个进程现在卡在哪」。挂上后目标进程会被暂停。 attach pid 效果同上只是写法不同先开空的 gdb再手动 attach。和 -p 二选一即可。 info threads 列出这个进程里所有线程以及每个线程当前停在什么函数/地址。 卡住问题时先扫一眼谁在 futex/poll/ioctl谁在干活。当前线程前面会有 *。 thread 1 切换到线程 1一般是主线程。后续 bt 看的就是这个线程的栈。 线程编号以 info threads 左边那列为准不一定永远是 1。 btbacktrace 打印当前线程的调用栈从最底层往上看「谁调谁最后停在哪」。 段错误时看崩溃点卡住时看它在等什么例如 hipStreamSynchronize。 thread apply all bt 对每一个线程都执行一次 bt。 适合死锁/多线程卡住一眼看清所有线程各自堵在哪避免漏掉非主线程。当然有时候这个hipgdb只能是定位卡在哪个kernel还得不到整体流程这时候需要加打印辅助找到具体的流程和卡主位置。10.4 借助打印排查vLLM精度问题有时候有些大模型精度问题不仅是可以通过将算子替换成triton算子解决还可以通过添加打印看一些算子输出的数据有没有异常这个在某次排查vllm EP高吞吐的scatter算子时很有帮助。11 利用一些工具11.1 内存泄漏分析工具工具asan、valgrind写C/C代码有时就会遇到一些内存泄漏那么可以借助内存泄漏分析工具进行查找。内存错误分析工具----asan(AddressSanitizer)的介绍和使用-CSDN博客内存泄漏查找工具----valgrind简介与使用-CSDN博客11.2 跟踪系统调用下面这几个方法我没用过我只是看了学习视频做了笔记以后我用到再看。Linux应用调试之使用strace命令跟踪系统调用_strace detach-onexecve-CSDN博客Linux驱动调试之段错误分析_根据pc值确定出错的代码位置_怎么根据驱动ko加载地址确定-CSDN博客Linux驱动调试之段错误分析_根据栈信息确定函数调用过程_linux 内核调用栈函数关系 无法显示栈地址-CSDN博客Linux驱动调试之自制工具_寄存器编辑器_linux ram 寄存器驱动程序-CSDN博客Linux驱动调试之修改系统时钟中断定位系统僵死问题_linux系统时钟卡死-CSDN博客11.3 hipprof调试海光GPU的vmfault coredump海光 GPU vmfault coredump排查方法与步骤HSA_ENABLE_COREDUMP hipprof --input-core-CSDN博客13 对比调试法一次解决ffmpeg错误的方法记录有一次在使用ffmpeg做视频解码的时候解码mp4视频报错然后我用vscode各种调试都找不到原因那怎么办这时候我试了下用下面的命令是可以的ffmpeg -c:v h264_nvmpi -i cars.mp4 -f null -然后这个ffmpeg命令是ffmpeg的fftools编译生成的那么我打开两个vsocde一个vscode调试这个fftools代码一个vscode调试我自己的工程代码然后逐步调试然后看一下到底是哪里有差距最后发现是我的ffmpeg里面有个地方的payload的size和ffmepgtools差距40个字节然后再去晚上搜索什么原因最终修改代码。14 单元测试法在做vllm的时候遇到程序报错卡主等问题可以先跑一下DeepEP或者算子库的单元测试脚本先确保一些组件或者第三方库的单元测试没有问题。15 组件、算子替换法排查大模型精度问题在做vllm的时候比如遇到精度问题那么可以尝试用某些算子用triton算子替换如果替换后没问题那么说明就是这个算子的问题。16 挨段代码注释法有时候我们遇到比如说内存泄漏吧我用asan这种工具也没能解决各种方法尝试了都不行那么我们可以一点点注释代码看看注释掉哪一块代码之后错误消失了这样逐步缩小错误代码范围这种方法看似很笨但是有时候却很好用。17 把自己的代码再看一遍有时候上面的方法都没解决掉那么静下心来把自己的代码再看一遍捋一遍可能会有意外收获。18 重启法有一次在算能盒子上运行程序发现加载模型失败之前同样的代码都没问题的然后我在调试过程中发现盒子明显变得很慢卡顿的很厉害甚至有时候命令都没法输入怀疑是不是盒子有问题结果盒子重启之后问题解决。19 整体编译法有一个一个大的工程只是编译了其中一个模块并没有整体编译然后运行报错调试的时候发现堆栈都乱七八糟的了这时候就试试把整个工程整体编译一遍。参考文献遇到缺陷错误时别着急冷静思考-CSDN博客必应中的 Microsoft Copilot (bing.com)Kimi.ai - 帮你看更大的世界 (moonshot.cn)通义tongyi.ai_你的全能AI助手-通义千问 (aliyun.com)文心一言 (baidu.com)Linux应用调试之使用gdb和gdbserver_gdbserver安装-CSDN博客使用GDB调试python调用的C共享库_python 调用c语言库,如何gdb-CSDN博客Linux下生成core文件,并用gdb调试core文件/ gdb调试段错误方法_gdb a.out core-CSDN博客gdb调试python的segmentation fault错误_debian gdb 调试python segmentation fault-CSDN博客使用visual studio 远程编辑和调试linux代码_visual studio 远程编译-CSDN博客ubuntu上安装vscode并远程开发与远程调试服务器代码_vscode ssh远程连接ubuntu后,怎么打开项目代码-CSDN博客 vscode远程调试服务器的Python代码_vscode 远程调试python代码-CSDN博客搭建嵌入式GDB调试环境以及VSCodegdbserver 图形化调试_vscode gdbserver-CSDN博客Code Composer Studio (CCS) 集成开发环境及TI仿真器的使用_code composer studio target configurations-CSDN博客ARM裸板调试之JTAG原理-CSDN博客ARM裸板调试之JTAG调试体验_制作 arm jtag-CSDN博客ARM裸板调试之JTAG调试命令行调试_arm 如何用jtag来调试-CSDN博客ARM裸板调试之JTAG调试源码级调试_arm jtag-CSDN博客C/C 中的__FILE__,__FUNCTION__,__LINE__,__DATE__,__TIME__,-CSDN博客Linux驱动调试之printk的原理-CSDN博客Linux驱动调试之printk的使用_linux printk-CSDN博客Linux驱动调试之打印到proc虚拟文件_linux驱动打印信息-CSDN博客ARM裸板调试之串口打印及栈初步分析_arm的串口调试-CSDN博客ARM裸板调试之点灯法_点灯法跟踪调试-CSDN博客记帮两个同事解决的一个奇怪bug-CSDN博客内存错误分析工具----asan(AddressSanitizer)的介绍和使用-CSDN博客内存泄漏查找工具----valgrind简介与使用-CSDN博客Linux应用调试之配置修改内核打印用户态段错误信息_段错误 打印详细信息-CSDN博客Linux应用调试之使用strace命令跟踪系统调用_strace detach-onexecve-CSDN博客在NVIDIA Jetson AGX Orin中使用jetson-ffmpeg调用硬件编解码加速处理_jetson orin 安装ffmpeg-CSDN博客Linux驱动调试之段错误分析_根据pc值确定出错的代码位置_怎么根据驱动ko加载地址确定-CSDN博客 Linux驱动调试之段错误分析_根据栈信息确定函数调用过程_linux 内核调用栈函数关系 无法显示栈地址-CSDN博客Linux驱动调试之自制工具_寄存器编辑器_linux ram 寄存器驱动程序-CSDN博客 程序遇到问题错误bug时的19种解决方法途径总结以及之前的一些具体例子
目录1 信心--没有解决不了的bug2 耐心、不要着急、静下心来、用脑思考2.1 开始解决问题前不要着急先思考2.2 在解决问题的过程中也不要着急要冷静思考3 灵活运用、不要局限或痴迷于某一种方法4 不要经验主义、不要局限于以前的经验或者知识点5 网络搜索、Github搜索、善用开源的东西、善用现成的东西6 借助AI大模型6.1 以前ChatGPT、Gemini、DeepSeek、GLM、kimi、通义千问、豆包----并且是几个大模型换着用6.2 现在借助cursor、codex、claude code7 看芯片手册、SDK手册、官方demo、开源代码的源码8 寻求技术支持、技术交流群9 gdb调试9.1 集成开发环境调试:vscode、clion、visual studio等9.2 gdb命令调试9.3 硬件仿真器调试、ARM裸板调试J-Link、ST-Link、TI的XDS调试器9.4 hipgdb抓vLLM进程卡主位置10 打印10.1 应用程序的printf、cout以及第三方log10.2 驱动程序的printk、串口打印10.3 借助打印排查vLLM卡主问题10.4 借助打印排查vLLM精度问题11 利用一些工具11.1 内存泄漏分析工具工具asan、valgrind11.2 跟踪系统调用11.3 hipprof调试海光GPU的vmfault coredump13 对比调试法一次解决ffmpeg错误的方法记录14 单元测试法15 组件、算子替换法排查大模型精度问题16 挨段代码注释法17 把自己的代码再看一遍18 重启法19 整体编译法参考文献1 信心--没有解决不了的bug在解决问题前要有信心相信只要自己去做那么bug就一定能解决没有解决不了的bug在解决bug的过程中如果经过多次尝试各种方法还是没能解决也不要放弃再继续尝试说不定突然就解决了以前你的很多bug都是不放弃最终解决掉了。2 耐心、不要着急、静下心来、用脑思考2.1开始解决问题前不要着急先思考当程序遇到问题或者错误的时候不要经过思考直接去网上搜答案或者直接去调试应该先静下心来思考有哪些可能得原因是不是自己哪里配置错误而不是程序有问题比如遇到缺陷错误时别着急冷静思考-CSDN博客当整体大方向确定没问题之后再想办法去解决问题。2.2 在解决问题的过程中也不要着急要冷静思考在解决问题的过程中可能你尝试了一些方法都没能解决这时候也不要像无头苍蝇一样继续尝试各种方法而是应该静下心来思考因为你已经试了一些方法了那么你肯定对这个问题有初步的认识了那么这时候应该基于前面的尝试去考虑下这个问题最大的可能性是什么边思考边尝试而不是一股脑的着急用各种不同的方法尝试解决。3 灵活运用、不要局限或痴迷于某一种方法这些方法是要灵活运用的而不是只用一种比如之前你觉得大模型挺好用的遇到问题就去问大模型然而有时候自己网上搜索反而能找到答案还有就是用IDE调试的方法确实挺好用的但是你不能遇到问题也不思考就打开了调试器去调试然后陷到这种方法里面了有时候认真看看代码就能解决没必要直接vscode调试。4 不要经验主义、不要局限于以前的经验或者知识点不要觉得以前是怎么解决的然后这次也应该怎么怎么样不要因为经验导致一些错误的判断然后就一直走进死胡同了很多时候要抛弃经验多尝试不一样的新的方法。比如从副来看你看音p的可以直接去网上搜别人的博客找现成的开发板而不是基于自己以前的经验在那里想怎么开发I2ST41的开发板配网可以直接web而不是就只用串口的方法T41的glibc可以去github上搜还有很多算法都是可以直接去github上找到开源的东西的所以怎么说呢有时候多尝试不同的方法不要老是基于自己以前的经验去判断。5 网络搜索、Github搜索、善用开源的东西、善用现成的东西当遇到报错的时候最长想到的就是去网上搜一下这个需要注意的是尽量首选x歌然后才是x度因为x歌的搜索结果确实很节省时间有时候x度搜索前几页都没有标准答案而x歌第一条就是正确解决方法。不只是解决bug有时候对于一些未知的不知道怎么解决的不知道怎么查找资源比如从副业来看你看音p的可以直接去网上搜别人的博客找现成的开发板而不是自己想怎么开发I2ST41的glibc可以去github上搜还有很多算法都是可以直接去github上找到开源的东西的所以怎么说呢多找现成的资源多找开源的东西不要老是想着自己写不要老是想着自己解决。6 借助AI大模型6.1 以前ChatGPT、Gemini、DeepSeek、GLM、kimi、通义千问、豆包----并且是几个大模型换着用随着大模型的兴起我们遇到问题可以直接问大模型大模型相比网络搜索有时候能够省掉你的时间但是有一个需要注意的不是痴迷于大模型有时候大模型没有的自己去网上搜索反而能找到答案你最开始觉得大模型好用就什么问题直接问大模型大模型没有你觉得就懒得搜了这个意识要改掉。这里还有个问题就是每个大模型擅长的点是不一样的很多时候你遇到问题比如用GPT没法解决的用了豆包立马解决以后遇到问题要综合几个大模型一个解决不了的另一个大模型可能就帮你解决了。6.2 现在借助cursor、codex、claude code以前排查问题是把问题复制到大模型里面问有了这些ai编程工具之后可以直接用编程工具打开代码目录这样排查问题效率更高更容易发现问题7 看芯片手册、SDK手册、官方demo、开源代码的源码有时候在用一些芯片的时候如果遇到一些错误码那么可以去芯片手册看看这个错误码代表哪种类型的错误还有有时候用的接口报错那么去SDK手册里面看一下这个接口的使用条件或者传入的参数是不是有什么要求或者自己的调用流程是不是不对。还有看一下官方的demo然后是不是自己使用的跟官方的demo有什么不一样还有就是比如再用opencv、ffmpeg等这些开源代码的时候可以去看一下开源代码的源码或者他们的头文件介绍比如下面这个错误当初去看一下opencv头文件的函数介绍也许解决的效率就更高了。记帮两个同事解决的一个奇怪bug-CSDN博客8 寻求技术支持、技术交流群有时候用的是一些厂家芯片网上就没有资料那么这时候就是去找厂家的技术支持只能这样解决要不然自己摸索也不会有答案。9 gdb调试9.1 集成开发环境调试:vscode、clion、visual studio等这个是我最常用的一个方法用集成开发环境调试能够打断点看程序执行单步执行能够看到各种变量能看堆栈看函数调用层次关系特别方便但还是一个注意事项就是不要局限于这种方法有时候如果这种方法一直没能找到错误原因那就换一个虽然这个方法很好用但不要痴迷于他。使用visual studio 远程编辑和调试linux代码_visual studio 远程编译-CSDN博客ubuntu上安装vscode并远程开发与远程调试服务器代码_vscode ssh远程连接ubuntu后,怎么打开项目代码-CSDN博客vscode远程调试服务器的Python代码_vscode 远程调试python代码-CSDN博客搭建嵌入式GDB调试环境以及VSCodegdbserver 图形化调试_vscode gdbserver-CSDN博客9.2 gdb命令调试使用gdb命令调试也可以看一些变量重点是可以bt查看堆栈信息。尤其是有时候在一些小的嵌入式开发板上用集成开发环境调试不太方便的时候可以用gdb命令去调试一些错误。Linux应用调试之使用gdb和gdbserver_gdbserver安装-CSDN博客gdb调试python的segmentation fault错误_debian gdb 调试python segmentation fault-CSDN博客使用GDB调试python调用的C共享库_python 调用c语言库,如何gdb-CSDN博客Linux下生成core文件,并用gdb调试core文件/ gdb调试段错误方法_gdb a.out core-CSDN博客9.3 硬件仿真器调试、ARM裸板调试J-Link、ST-Link、TI的XDS调试器对于ARM芯片我们可以直接用硬件仿真器去调试这样能看到他内部的寄存器值也能像IDE那样单步执行查看变量的值设置断点对于ARM逻辑调试时这个硬件仿真器就很有用还有TI的硬件仿真器还可以直接抓取音频的波形还可以把内存的值保存成文件。Code Composer Studio (CCS) 集成开发环境及TI仿真器的使用_code composer studio target configurations-CSDN博客ARM裸板调试之JTAG原理-CSDN博客ARM裸板调试之JTAG调试体验_制作 arm jtag-CSDN博客ARM裸板调试之JTAG调试命令行调试_arm 如何用jtag来调试-CSDN博客ARM裸板调试之JTAG调试源码级调试_arm jtag-CSDN博客9.4 hipgdb抓vLLM进程卡主位置在做大模型推理的时候遇到vllm起服务卡主的问题然后这种情况可以用hipgdb去看程序卡主的位置的具体命令如下gdb -p pid 把 gdb 挂到已经在跑的进程上不重新启动它。等于「去看这个进程现在卡在哪」。挂上后目标进程会被暂停。 attach pid 效果同上只是写法不同先开空的 gdb再手动 attach。和 -p 二选一即可。 info threads 列出这个进程里所有线程以及每个线程当前停在什么函数/地址。 卡住问题时先扫一眼谁在 futex/poll/ioctl谁在干活。当前线程前面会有 *。 thread 1 切换到线程 1一般是主线程。后续 bt 看的就是这个线程的栈。 线程编号以 info threads 左边那列为准不一定永远是 1。 btbacktrace 打印当前线程的调用栈从最底层往上看「谁调谁最后停在哪」。 段错误时看崩溃点卡住时看它在等什么例如 hipStreamSynchronize。 thread apply all bt 对每一个线程都执行一次 bt。 适合死锁/多线程卡住一眼看清所有线程各自堵在哪避免漏掉非主线程。当然有时候这个hipgdb只能是定位卡在哪个kernel还得不到整体流程这时候需要加打印辅助找到具体的流程和卡主位置。10 打印10.1 应用程序的printf、cout以及第三方log这个不用多说了虽然已经有前面的IDE以及gdb调试了但是有些时候printf打印反而能解决一些调试没法或者不太好解决的问题打印除了打印出来变量的值以外还可以打印出来行号和函数名具体方法在下面博客C/C 中的__FILE__,__FUNCTION__,__LINE__,__DATE__,__TIME__,-CSDN博客Linux应用调试之配置修改内核打印用户态段错误信息_段错误 打印详细信息-CSDN博客10.2 驱动程序的printk、串口打印对于驱动程序可以用printk的方法进行打印调试这个printk很多时候就能帮我们解决很多问题了。Linux驱动调试之printk的原理-CSDN博客Linux驱动调试之printk的使用_linux printk-CSDN博客Linux驱动调试之打印到proc虚拟文件_linux驱动打印信息-CSDN博客ARM裸板调试之串口打印及栈初步分析_arm的串口调试-CSDN博客ARM裸板调试之点灯法_点灯法跟踪调试-CSDN博客10.3 借助打印排查vLLM卡主问题在做大模型推理的时候遇到vllm起服务卡主的问题然后这种情况可以用hipgdb去看程序卡主的位置的具体命令如下gdb -p pid 把 gdb 挂到已经在跑的进程上不重新启动它。等于「去看这个进程现在卡在哪」。挂上后目标进程会被暂停。 attach pid 效果同上只是写法不同先开空的 gdb再手动 attach。和 -p 二选一即可。 info threads 列出这个进程里所有线程以及每个线程当前停在什么函数/地址。 卡住问题时先扫一眼谁在 futex/poll/ioctl谁在干活。当前线程前面会有 *。 thread 1 切换到线程 1一般是主线程。后续 bt 看的就是这个线程的栈。 线程编号以 info threads 左边那列为准不一定永远是 1。 btbacktrace 打印当前线程的调用栈从最底层往上看「谁调谁最后停在哪」。 段错误时看崩溃点卡住时看它在等什么例如 hipStreamSynchronize。 thread apply all bt 对每一个线程都执行一次 bt。 适合死锁/多线程卡住一眼看清所有线程各自堵在哪避免漏掉非主线程。当然有时候这个hipgdb只能是定位卡在哪个kernel还得不到整体流程这时候需要加打印辅助找到具体的流程和卡主位置。10.4 借助打印排查vLLM精度问题有时候有些大模型精度问题不仅是可以通过将算子替换成triton算子解决还可以通过添加打印看一些算子输出的数据有没有异常这个在某次排查vllm EP高吞吐的scatter算子时很有帮助。11 利用一些工具11.1 内存泄漏分析工具工具asan、valgrind写C/C代码有时就会遇到一些内存泄漏那么可以借助内存泄漏分析工具进行查找。内存错误分析工具----asan(AddressSanitizer)的介绍和使用-CSDN博客内存泄漏查找工具----valgrind简介与使用-CSDN博客11.2 跟踪系统调用下面这几个方法我没用过我只是看了学习视频做了笔记以后我用到再看。Linux应用调试之使用strace命令跟踪系统调用_strace detach-onexecve-CSDN博客Linux驱动调试之段错误分析_根据pc值确定出错的代码位置_怎么根据驱动ko加载地址确定-CSDN博客Linux驱动调试之段错误分析_根据栈信息确定函数调用过程_linux 内核调用栈函数关系 无法显示栈地址-CSDN博客Linux驱动调试之自制工具_寄存器编辑器_linux ram 寄存器驱动程序-CSDN博客Linux驱动调试之修改系统时钟中断定位系统僵死问题_linux系统时钟卡死-CSDN博客11.3 hipprof调试海光GPU的vmfault coredump海光 GPU vmfault coredump排查方法与步骤HSA_ENABLE_COREDUMP hipprof --input-core-CSDN博客13 对比调试法一次解决ffmpeg错误的方法记录有一次在使用ffmpeg做视频解码的时候解码mp4视频报错然后我用vscode各种调试都找不到原因那怎么办这时候我试了下用下面的命令是可以的ffmpeg -c:v h264_nvmpi -i cars.mp4 -f null -然后这个ffmpeg命令是ffmpeg的fftools编译生成的那么我打开两个vsocde一个vscode调试这个fftools代码一个vscode调试我自己的工程代码然后逐步调试然后看一下到底是哪里有差距最后发现是我的ffmpeg里面有个地方的payload的size和ffmepgtools差距40个字节然后再去晚上搜索什么原因最终修改代码。14 单元测试法在做vllm的时候遇到程序报错卡主等问题可以先跑一下DeepEP或者算子库的单元测试脚本先确保一些组件或者第三方库的单元测试没有问题。15 组件、算子替换法排查大模型精度问题在做vllm的时候比如遇到精度问题那么可以尝试用某些算子用triton算子替换如果替换后没问题那么说明就是这个算子的问题。16 挨段代码注释法有时候我们遇到比如说内存泄漏吧我用asan这种工具也没能解决各种方法尝试了都不行那么我们可以一点点注释代码看看注释掉哪一块代码之后错误消失了这样逐步缩小错误代码范围这种方法看似很笨但是有时候却很好用。17 把自己的代码再看一遍有时候上面的方法都没解决掉那么静下心来把自己的代码再看一遍捋一遍可能会有意外收获。18 重启法有一次在算能盒子上运行程序发现加载模型失败之前同样的代码都没问题的然后我在调试过程中发现盒子明显变得很慢卡顿的很厉害甚至有时候命令都没法输入怀疑是不是盒子有问题结果盒子重启之后问题解决。19 整体编译法有一个一个大的工程只是编译了其中一个模块并没有整体编译然后运行报错调试的时候发现堆栈都乱七八糟的了这时候就试试把整个工程整体编译一遍。参考文献遇到缺陷错误时别着急冷静思考-CSDN博客必应中的 Microsoft Copilot (bing.com)Kimi.ai - 帮你看更大的世界 (moonshot.cn)通义tongyi.ai_你的全能AI助手-通义千问 (aliyun.com)文心一言 (baidu.com)Linux应用调试之使用gdb和gdbserver_gdbserver安装-CSDN博客使用GDB调试python调用的C共享库_python 调用c语言库,如何gdb-CSDN博客Linux下生成core文件,并用gdb调试core文件/ gdb调试段错误方法_gdb a.out core-CSDN博客gdb调试python的segmentation fault错误_debian gdb 调试python segmentation fault-CSDN博客使用visual studio 远程编辑和调试linux代码_visual studio 远程编译-CSDN博客ubuntu上安装vscode并远程开发与远程调试服务器代码_vscode ssh远程连接ubuntu后,怎么打开项目代码-CSDN博客 vscode远程调试服务器的Python代码_vscode 远程调试python代码-CSDN博客搭建嵌入式GDB调试环境以及VSCodegdbserver 图形化调试_vscode gdbserver-CSDN博客Code Composer Studio (CCS) 集成开发环境及TI仿真器的使用_code composer studio target configurations-CSDN博客ARM裸板调试之JTAG原理-CSDN博客ARM裸板调试之JTAG调试体验_制作 arm jtag-CSDN博客ARM裸板调试之JTAG调试命令行调试_arm 如何用jtag来调试-CSDN博客ARM裸板调试之JTAG调试源码级调试_arm jtag-CSDN博客C/C 中的__FILE__,__FUNCTION__,__LINE__,__DATE__,__TIME__,-CSDN博客Linux驱动调试之printk的原理-CSDN博客Linux驱动调试之printk的使用_linux printk-CSDN博客Linux驱动调试之打印到proc虚拟文件_linux驱动打印信息-CSDN博客ARM裸板调试之串口打印及栈初步分析_arm的串口调试-CSDN博客ARM裸板调试之点灯法_点灯法跟踪调试-CSDN博客记帮两个同事解决的一个奇怪bug-CSDN博客内存错误分析工具----asan(AddressSanitizer)的介绍和使用-CSDN博客内存泄漏查找工具----valgrind简介与使用-CSDN博客Linux应用调试之配置修改内核打印用户态段错误信息_段错误 打印详细信息-CSDN博客Linux应用调试之使用strace命令跟踪系统调用_strace detach-onexecve-CSDN博客在NVIDIA Jetson AGX Orin中使用jetson-ffmpeg调用硬件编解码加速处理_jetson orin 安装ffmpeg-CSDN博客Linux驱动调试之段错误分析_根据pc值确定出错的代码位置_怎么根据驱动ko加载地址确定-CSDN博客 Linux驱动调试之段错误分析_根据栈信息确定函数调用过程_linux 内核调用栈函数关系 无法显示栈地址-CSDN博客Linux驱动调试之自制工具_寄存器编辑器_linux ram 寄存器驱动程序-CSDN博客