在rt-thread中使用iperf触发断言卡死

问题触发

最近在适配sdio device驱动，CP芯片与AP芯片对接（RK3399），准备使用iperf测试下能否AP与CP能否正常通信。CP芯片跑的是rt-thread系统，在使用sdio_eth_dev_init命令初始化后，使用iperf -c 192.168.1.3测试。AP那边做服务端，先执行了iperf -s。

然后触发了rt_timer_stop函数的断言，系统卡住。

断言（assert）及其作用

断言是一种除错机制，用于验证代码是否符合编码人员的预期。编码人员在开发期间应该对函数的参数、代码中间执行结果合理地使用断言机制，确保程序的缺陷尽量在测试阶段被发现。

问题分析

首先知道卡在了547行，于是将rt_object_get_type(&timer->parent)打印出来，值是0x0，而正常要等于RT_Object_Class_Timer（0xa），所以要知道为什么这里rt_object_get_type(&timer->parent)变成了0x0，而且从打印中可以看到这个值之前一直都是0xa。

由于我是在FPGA上使用TRACE32+劳德巴赫工具调试的，所以打算直接监控ddr上的地址什么时候被写成0了。

监控的地址是object->type。正常时这个值为0x8A，经过583行运算得到0xa。出问题之前这个值被改成了0，所以返回0。

断点设置好后，把程序跑起来，然后触发到了，发现是在我的device驱动里调用的一个打印函数
rt_printf(“[zrc] <%s %d>\n”, func, LINE);的调用该到了这个值，俗称“踩内存”了。然后尝试注释掉这行代码，重复之前步骤测试不会卡死。

那为什么这行打印函数会踩内存？

怀疑线程栈越界导致的，于是将tcpip的栈大小从1024改成4096，重复之前测试步骤不会卡死。问题解决。