这里是BUG回报板块!

发布于 2010-04-30 17:54:12    浏览:75538

论坛里没有一个BUG回报的集中点,那么以后就在这里回报吧!

下载附件 rtthread.rar

查看更多

128 个回答
shellstudio
shellstudio 2010-04-30
This guy hasn't written anything yet

RTT的时基函数是rt_tick_increase(),该函数有个不妥之处,比如我把每个线程的时间片长度设置为1个时基。
那么,有以下情况可能发生:rt_timer_check()函数使更高优先级的线程就绪,而该线程的时间片为1。此后rt_thread_self()函数返回的就是这个就绪线程,接下来紧接着时间片计数器就被减1,变为0,也就是说线程还没执行就被rt_thread_yield()函数当作放弃了执行对待!

这就是不妥之处!望Bernard兄妥善解决。

shellstudio
shellstudio 2010-04-30
This guy hasn't written anything yet

RTT的定时计数器变量rt_tick在每个Tick中断内自增,自增到0xffffffff再溢出到0周而复始。

所有定时器对象的定时结束时基计算为:timer->timeout_tick = rt_tick_get() + timer->init_tick;
在时基中断,检查if (rt_tick >= t->timeout_tick)是否成立,如果成立则定时时间到。似乎很合理,但是错误就出现在这里。

如果来了20个tick的定时请求在执行timer->timeout_tick = rt_tick_get() + timer->init_tick;时,若rt_tick0xfffffff0,于是得出定时结束时间为0x00000004,于是该节点加入定时器列表等待超时。结果,下一次进入中断的rt_tick为0xfffffff1,使if (rt_tick >= t->timeout_tick)检查成立,所以定时时间结束,错误发生了!
这个错误平时发现不了,是因为等到rt_tick接近溢出需要很长时间(如果1毫秒一个tick的话,需要50天,10毫秒一个tick就需要500天,哈哈!),Bernard兄是不是考虑到这个情况才故意放过这个臭虫的呢?如果要解决该问题,必定添加不少冗余代码,影响性能。但留着这个漏洞又很不舒服,怎么办呢?

shellstudio
shellstudio 2010-05-01
This guy hasn't written anything yet
RTT还需要很长的时间来完善才能用于商业乃至工业现场啊!今天又发现了一个很要命的漏洞,这种漏洞是对临界代码段的理解太随意导致的。
我知道,很多人有时候为了所谓的实时性,都忽略了临界代码段的重要性。但是,如果不仔细推敲代码而随意放任的话,系统会变得异常脆弱!
下面我就来给你分析以下rt_object_find()函数的漏洞。
rt_object_find()函数是通过对象的名称来查找对象,并返回指针。调用该函数之前,线程大都不会关中断来保护rt_object_find(),而该函数自身更是没有临界段保护措施,这样就造成了下面的漏洞:
在遍历链表节点的过程中,node指向当前所检查的对象节点,而在此判断过程中,有可能高优先级线程得到运行,从而导致当前对象节点有可能被删除,这时,对象的链表指针next,prev就指向它自身。之后,CPU上下文回到调用rt_object_find()函数的线程,继续遍历对象链表,结果node = node->next语句总是使node指向它自身,而且符合node != &(information->object_list)条件,因此,for()循环形成了死循环!该函数将无法退出,其结果无法预测!
我是一个思维很严谨的人,总是很小心的对待代码,即使是在单任务软件开发过程中,我也很注意中断函数和main()循环之间的临界代码段问题。希望大家能跟我一样多查看内核代码,尽快完善RTT!
(我的经验都来自ucos源代码,因为国外对RTOS的认证是很严格的,ucos是经过航空级认证的RTOS)
bernard
bernard 2010-05-01
This guy hasn't written anything yet
哦,原来这里有个归总的,谢谢shellstudio的反馈。以后就使用这个做为RT-Thread的BUG反馈集中贴吧。
bernard
bernard 2010-05-01
This guy hasn't written anything yet
RTT的时基函数是rt_tick_increase(),该函数有个不妥之处,比如我把每个线程的时间片长度设置为1个时基。那么,有以下情况可能发生:rt_timer_check()函数使更高优先级的线程就绪,而该线程的时间片为1。此后rt_thread_self()函数返回的就是这个就绪线程,接下来紧接着时间片计数器就被减1,变为0,也就是说线程还没执行就被rt_thread_yield()函数当作放弃了执行对待!这就是不妥之处!望Bernard兄妥善解决。


不会的,rt_thread_self()只会在当前线程的上下文环境执行,如果在中途被打断,上面相应的上下文会被保存,下一次恢复出来依然是当前这个线程对象。
bernard
bernard 2010-05-01
This guy hasn't written anything yet
RTT的定时计数器变量rt_tick在每个Tick中断内自增,自增到0xffffffff再溢出到0周而复始。
所有定时器对象的定时结束时基计算为:timer->timeout_tick = rt_tick_get() + timer->init_tick;
在时基中断,检查if (rt_tick >= t->timeout_tick)是否成立,如果成立则定时时间到。似乎很合理,但是错误就出现在这里。如果来了20个tick的定时请求在执行“timer->timeout_tick = rt_tick_get() + timer->init_tick;”时,若rt_tick为0xfffffff0,于是得出定时结束时间为0x00000004,于是该节点加入定时器列表等待超时。结果,下一次进入中断的rt_tick为0xfffffff1,使if (rt_tick >= t->timeout_tick)检查成立,所以定时时间结束,错误发生了!
这个错误平时发现不了,是因为等到rt_tick接近溢出需要很长时间(如果1毫秒一个tick的话,需要50天,10毫秒一个tick就需要500天,哈哈!),Bernard兄是不是考虑到这个情况才故意放过这个臭虫的呢?如果要解决该问题,必定添加不少冗余代码,影响性能。但留着这个漏洞又很不舒服,怎么办呢?


这个问题mbbill和阿干都和我讨论过,只是一直没能够找到比较好一些的办法,所以拖着没解决。呵呵,这个也是0.4.x分支必须要解决的问题之一(解决了会merge回0.3.x分支)。

因为RT-Thread目前主要面向小型应用,如果简单的解决这个问题,只需要更改32位为两个32位变量即可(当然这样仅仅是延长了很多出错的时间,从 50天或500天延长到了4294967295 * 50天或4294967295 * 500天),这样唯一的问题就是多了4个字节。
bernard
bernard 2010-05-01
This guy hasn't written anything yet
RTT还需要很长的时间来完善才能用于商业乃至工业现场啊!今天又发现了一个很要命的漏洞,这种漏洞是对临界代码段的理解太随意导致的。
我知道,很多人有时候为了所谓的实时性,都忽略了临界代码段的重要性。但是,如果不仔细推敲代码而随意放任的话,系统会变得异常脆弱!
下面我就来给你分析以下rt_object_find()函数的漏洞。
rt_object_find()函数是通过对象的名称来查找对象,并返回指针。调用该函数之前,线程大都不会关中断来保护rt_object_find(),而该函数自身更是没有临界段保护措施,这样就造成了下面的漏洞:
在遍历链表节点的过程中,node指向当前所检查的对象节点,而在此判断过程中,有可能高优先级线程得到运行,从而导致当前对象节点有可能被删除,这时,对象的链表指针next,prev就指向它自身。之后,CPU上下文回到调用rt_object_find()函数的线程,继续遍历对象链表,结果node = node->next语句总是使node指向它自身,而且符合node != &(information->object_list)条件,因此,for()循环形成了死循环!该函数将无法退出,其结果无法预测!
我是一个思维很严谨的人,总是很小心的对待代码,即使是在单任务软件开发过程中,我也很注意中断函数和main()循环之间的临界代码段问题。希望大家能跟我一样多查看内核代码,尽快完善RTT!
(我的经验都来自ucos源代码,因为国外对RTOS的认证是很严格的,ucos是经过航空级认证的RTOS)


这个确实是问题,其他的几个object函数都加了相应的保护,当时实现这个函数时仅仅是临时的,直接关中断又不忍心,而使用semaphore一类的机制后,那么整个object容器的操作将不能够在中断服务程序中使用。

这个地方确实处理得不太好,而且这个也不是主函数一类的,这个函数还是直接删除掉比较好,这样也比较容易分别进行对待。
xiao苦
xiao苦 2010-05-13
This guy hasn't written anything yet

如下。。。

.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_realloc (referred from region.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_strdup (referred from rtgui_object.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_free (referred from rtgui_system.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_malloc (referred from rtgui_system.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rtgui_filerw_create_file (referred from image.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_mq_create (referred from server.o).
.objrtthread-stm32.axf: Error: L6218E: Undefined symbol rt_thread_create (referred from server.o).

可以看到在实例里面的mdk里面, 内存管理的函数都提示没有定义, 无法调用。。。。

bernard
bernard 2010-05-13
This guy hasn't written anything yet

你的工程文件有问题?

关于使用RT-Thread/GUI的例子,可以参考STM32 Radio的例程

xiao苦
xiao苦 2010-05-14
This guy hasn't written anything yet
嗯, 谢谢, 是我的配置文件rtconfig.h没有配置好, 问题已经解决了, 但是还有个问题, 正式版里面的rtgui的液晶是用spi模式的, 但是我的是16位总线的驱动的, 这样原先的驱动虽然可以改,但是把基本函数改了之后会不会有很多问题, 目前已经把报错的全都改成适应16位color的。。。。就是不知道窗体会怎么样, 另外求stm32 radio的源码, 我找不到, 谢谢。。。

撰写答案

请登录后再发布答案,点击登录
关注者
1
被浏览
75.5k

发布
问题

分享
好友

手机
浏览

扫码手机浏览