车机全链路的问题分析总结（软件视角）

编译问题：
1、 was not declared in this scope
缺少声明，查看.h 文件是否做了声明或者需要引入新的.h 文件
2、 redefined
重定义，,o 文件合并链接形成的可执行文件的符号表中，有两个以及以上的相同符号。修改符号变量名，或者修改代码逻辑
3、 由于代码中缺少， 或者{ } 不匹配 等语法问题导致的一系列报错
编译导致的问题往往是因为耦合导致的，如果可以的话，是一个很好的机会对系统进行小的解耦合优化。

coredump 问题:
1、系统端问题
dnp 这个进程往往出现系统端的错误。一般是由于系统端初始化出了相关问题导致，coredump 之前系统端跑起来的代码很少（从coredump 的log 就可以得知），这时候使用gdb --args ./bin --flag = xxx， 使用gdb 进行调试。
○ 使用bt 打印崩掉的进程之前进入的函数堆栈，看到崩掉之前都进入了哪些函数。
○ 使用 f n; 可以进入到 在函数堆栈中 编号为n 函数中
○ 使用info frame 查看当前堆栈中的存储信息， 或者使用 info args 以及 info locals 分别查看当前函数的各个参数值以及局部变量数值
系统端的问题往往是系统环境导致的，或者是系统配置文件导致的，与代码逻辑一般没有关系， 如果没有修改的话，建议 重启板子，检查运行脚本，或者查看关于dds 的 init 文件的情况。
2、因为逻辑导致的系统不适配或者错误问题
dnp_dds_test 这个进程往往出逻辑错误。因为dnp_dds_test 因为需求的原因，以及系统层面没有严格设计，所以经常需要适配。出问题最多的地方 是dnp输入信息的解析相关的一系列代码。调试的方法为多分打印（其实就是基于二分的思想快速定位哪一行导致bug）。打印关键信息，确定问题

依赖错误：
项目内部，因为项目被conan 切分为不同的模块，如果bug 定位到与某一个模块相关，可以咨询相关负责人，找到正确的依赖，或者寻找相关负责人修改相应的bug

上车调试问题
1、上车调试要验证dnp 的逻辑问题时候，或者验证其他功能时候，进行上车的调试。上车调试一般需要打印相应的log， 来定位问题。但是可能出现编译之后，运行的结果仍然是上一次的编译结果的情况。上车调试时候，每次编译都建议使用 clear.sh 脚本，先删除上一次的编译产物 build 以及prebuild 这俩文件夹。原则上应该尽量减少上车进行调试问题，再次编译。问题的原因可能如下：
● 编译器没有检测到代码的修改
● 编译器使用了之前的编译结果缓存

2、 scp 传输一些文件导致似乎没有被更新
● 编译器的缓存问题，清除编译器的缓存，再次编译以及传输

3、上车有时候ssh 进入板子之后，会非常非常卡，这时候一般重启板子即可

4、上车如果ssh 进入了板子，然后运行相关程序，那么但杀掉ssh 这个进程的话，ssh 打开的相关进程也会被杀死（关闭ssh 会发送 kill 的信号 给所有进程）

5、上车执行dnp 时候建议 先杀掉dnp 的程序，要不然因为context 的原因会导致dnp 的程序不会正常启动
● 代码有一些全局缓存以及其他的缓存，需要将缓存清除

链路调试问题
1、 这个一般需要和测试配合，测试对于硬件的系统架构会清晰一些，软件人员需要注意IP 以及端口 以及 dds 的topic 是否正确。测试保证硬件链路ok。软件人员要向测试咨询一下硬件拓扑关系。

2、 嵌入式工作层面偏硬件，其会基于硬件提供一些基础网络服务，以及网络适配问题。

3、关于链路车can 相关，也可以找系统的同事进行咨询