系统稳定性问题专题

《C专家编程》

7.7.1总线错误

事实上，总线错误几乎都是由于未对齐的读或写引起的。之所以称之为总线错误，出现未对齐的内存访问请求时，被组赛的组件就是地址总线。对齐的意思是数据项只能存储在地址是数据项大小的整数倍内存位置上。

7.7.2 段错误

段错误或段违规（segmentation violation）应该已经很清楚。因为前面对段模型已经做了解释。在sun硬件中，段错误是由于内存管理单元（负责支持虚拟内存的硬件）的异常导致，而该异常通常是由于解除引用一个未初始化或非法值的指针引起的。如果指针引用一个并不位于你地址空间中的地址，操作系统便会对此进行干涉。

一个微妙之处是，导致指针具有非法值通常是由于不同的编程错误引起的。和总线错误不同，段错误更像是一个间接引起的症状，而不是引起错误的原因。

一个更糟糕的微妙之处是，如果未初始化的指针恰好具有未对齐的值（对于指针索要访问的数据而言），他将会产生总线错误。对于绝大多数结构的计算机而言确实如此，因为CPU先看到地址，然后把它发送给MMU。

通常导致段错误的几个直接原因：

·解引用一个包含非法值的指针；

·解引用一个空指针（常常由于从系统程序中返回空指针，并且未经检查就使用）；

·在未得到正确的访问权限时进行访问。例如，试图往一个只读的文本段存储值就会引起段错误；

·用完了堆栈或堆空间；

要点记录

1. 若整个系统的 RAM 占用率在耗尽的边缘，整个系统就不稳定，会出现各种各样的问题。

问题1 卡死在 configASSERT( pxQueue->uxItemSize == 0 );

是否找到答案：否

问题描述：

环境：FreeRTOS version 10.3.x + lwIP v2.1.2 + stm32f407ve

现象：因为lwIP的lwipopts.h参数配置，很容易导致stm32f407的RAM耗尽，所以稍有配置不合理，就会出现莫名的错误，比如 stm32f407 的 HardFault 。 

这次出现的问题是，程序卡死在了 while(1), 也就是 xQueueSemaphoreTake 函数的 configASSERT( pxQueue->uxItemSize == 0 ); 处。

通过调整lwIP的内存占用，此问题不再出现。确认，是由内存分配不合理造成的。

其他参考：

参考1

A stack overflow might cause this kind of internal data corruption. Did you enable stack checking ? See https://www.freertos.org/Stacks-and-stack-overflow-checking.html

参考2

@vanderareosa This issue is likely caused by memory corruption (e.g., due to a stack overflow). I'm closing this issue as there's not much actionable information we can go on. Please feel free to reopen this issue if the error occurs again.

Here are some things you could also try.

• Increase your task stack sizes and see if the issue goes away
• Check the addresses of the semaphore, your task stack's start and end addresses, and the uxTaskGetStackHighWaterMark() of each task, to see if any of them overlap.