[公告] RT-Thread 0.3.2中mailbox存在bug：107+LWIP ping死机问题
我用的RTT+LWIP，工程就是内核包里的project_107工程，根据我板子上用的是DM9161和RMII，适当该了驱动后能跑起来，能ping通，当时过一会就会出下面的错误，然后系统停在sys_arch_assert里死循环了。finsh>>pbuf_free: p->ref > 0
Assertion: 563 in ..\..\..\net\lwip\src\core\pbuf.c, thread tcpip
(0) assert failed at sys_arch_assert:319
我分析之后是pbuf.c里面的pbuf_free函数，判断p->ref等于0造成的，不知道是什么原因造成的，请大家给我分析下！
====
ffxz:
新添加的rt_mb_send实现存在问题，会导致接收侧线程 error 号被中断服务例程错误更改，而从出现从邮箱中接收消息会发生重复接收的问题，最终导致：
pbuf_free: p->ref > 0
的LwIP asert问题。
受影响的版本：RT-Thread 0.3.2
受影响的分支：所有移植分支
建议：不再使用RT-Thread 0.3.2版本，更改为后续发布的RT-Thread 0.3.3或使用RT-Thread 0.4.x系列。（RT-Thread 0.3.1不受影响，RT-Thread 0.4.0 svn版本不受影响（0.4.0 beta2未知））
补丁后续会发布，并发布0.3.3版本。
感谢 bieahoff 的反馈。 没人对我的提问给回复啊，我把我的新的实验结果告诉大家，我前面的问题是在RT-Thread-0.3.2里面做的实验，昨天我又下载了RT-Thread-0.3.1，但是跑起来有问题，后来发现好像是107的驱动问题，所以我把RT-Thread-0.3.1部分的107驱动换成了RT-Thread-0.3.2里面的驱动，跑起来后没问题，然后我就ping，开了3个ping，包的大小分别是1000,1100,1300，然后一直ping，从昨天晚上大概16点40开始一直到现在，晚上通宵运行，估计一共有17个小时了，都没有出现上面说的问题，所以我看是不是RT-Thread-0.3.2的系统是不是有问题啊，希望ffxz能看到我这个问题，谢了！ 通常这个问题是由于内存越界引起的，你是否加了一些上层应用代码，或者修改的驱动不对？
另外建议使用0.4.0，这个是以后的方向…… 我做的测试绝对没有加任何上层的应用代码，直接在project_107工程上做了点小改动以适合DM9161和RMII，修改的地方无非是将PHY_ADDRESS改为0x00,屏蔽MII_MODE，添加RMII_MODE的定义，然后就是管脚的修改，其他没做任何修改哦，说白了我的板子是对着神舟IV号开发板做的，RT-Thread-0.3.2和RT-Thread-0.3.1都是这么改的，这些驱动的修改应该不会引起内存越界吧。
而且我看网上别人也有用RT-Thread-0.3.2出上面的问题。
0.4.0不是还没出稳定版本吗？ 好的，我已经在邮件列表中反馈这个问题，会对RT-Thread 0.3.2的STM32F107做一个回归测试。 为何不考虑使用keil带的tcpnet 这个问题很奇怪了，比较了下RT-Thread 0.3.1/0.3.2，lwip方面的修改仅是把邮件发送更改为 等待方式的邮件发送。 rt_mb_send_wait函数比rt_mb_send函数多了判断是否邮箱满，满的话就根据超时定义值等待，看来是rt_mb_send_wait这个内核代码有问题啊！
我看STM32网站上的移植代码是邮箱发送函数里没做什么操作，满了就退出，重复判断是在sys_mbox_post里面多调几次邮箱发送
while((i<10) && ((ubErr = OSQPost( mbox->pQ, msg)) != OS_NO_ERR))
{
i++;//if full, try 10 times
OSTimeDly(5);
} 但是svn 0.4.0上相同的代码，又没有这个问题。是否可能是，0.3.1本身也存在这个问题，但是不那么容易复现出来？
当然，svn的版本lwip方面已经做了些改进工作，需要更多的测试。 0.3.1应该没问题吧，自从我换成0.3.1之后一直到现在我几乎每天都是开着ping,每天上班板子上电后，电脑开机后我就开始ping它，深沉次的原因还得你们找哦。
别的芯片0.3.2没这个问题吗？比如说stm32f103ze+dm9000. 新添加的rt_mb_send实现存在问题，会导致接收侧线程 error 号被中断服务例程错误更改，而从出现从邮箱中接收消息会发生重复接收的问题，最终导致：
pbuf_free: p->ref > 0
的LwIP asert问题。
受影响的版本：RT-Thread 0.3.2
受影响的分支：所有移植分支
建议：不再使用RT-Thread 0.3.2版本，更改为后续发布的RT-Thread 0.3.3或使用RT-Thread 0.4.x系列。（RT-Thread 0.3.1不受影响，RT-Thread 0.4.0 svn版本不受影响（0.4.0 beta2未知））
补丁后续会发布，并发布0.3.3版本。
感谢 bieahoff 的反馈。 这个很大程度上是因为svn的一些缺陷导致的多分枝bugfix没办法互通。
这个bug在6月份引入，7月份在trunk中就已经修复了。但是这部分代码merge到0.3.2是6月份，后续的bugfix没有更新进去。
同样的情况很可能也会出现在其他的地方，比如trunk里面fix了一个bug，在其他branch很可能也需要fix。
对这个case来说原先的rt_mb_recv也是有bug的，只是在lwip中容易暴露出来，而不引入这个patch的结果就是lwip mbox溢出问题几乎无解，这是为了解决bug而引入的一个feature，所以我并不觉得我们的稳定版分支会因为这个patch而变成一个笑话。
关键还是在版本控制上没做好。 lwip mbox溢出应该没想象中严重吧？这个case，实际上是因为rt_mb_send的代码引起的，而原来rt_mb_send代码并不存在这个问题，应该是新引入的bug。
这个与svn应该关系不大，记得最终会做手工合并，并做0.3.2与trunk代码对比。所以归根到底，还是我们在版本发布中出现了问题，缺少了相应的测试。类似你目前写的网络测试工具就非常好，网络方面，只要用你写的这个自动化测试工具一跑，网卡驱动、协议栈如果有问题就会暴露出来。只是在内核方面我们还缺少这样的工具。 修复方法：
src/ipc.c中的1294行：
thread->error = -RT_EFULL;
删除掉即可。 过完中秋节回来就看见你们对这个问题有了最终答案，真是不错，静候新版本的出世。
送上晚到的中秋祝福！ 期待新版本！ 我用的LPC1766+DP83848平台，参照上述更改办法后，还是出现长时间（几个小时）通信后不能PING通，复位后通信正常的情况，后来查找原因是DP83848驱动程序中断中未做发送接收溢出错误INT_RX_OVERRUN、INT_TX_UNDERRUN处理导致，希望对大家有所提示。 回复【16楼】weihby
我用的lpc1766+dp83848平台，参照上述更改办法后，还是出现长时间（几个小时）通信后不能ping通，复位后通信正常的情况，后来查找原因是dp83848驱动程序中断中未做发送接收溢出错误int_rx_overrun、int_tx_underrun处理导致，希望对大家有所提示。
-----------------------------------------------------------------------
我在用lpc1768+dp83848平台, 每100ms发送大约8K数据, 经过4个多小时后,ping命令就出现time out. 传输断开,复位后通信正常.
能提供你 修改后的 dp83848驱动程序吗?
谢谢!!! 技术不精，只能是mark党了 LWIP问题多多.....希望可以建一个专门的贴，来讨论里面的BUG 记下，好东东的
页:
[1]