Skills for finding defects in embedded software design

Article title: Skills for finding defects in embedded software design. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.

Most software development projects identify software defects by combining code checks, structure tests, and functional tests. Although these traditional technologies are important and can discover most software problems, they cannot identify many Common Errors in today's complex systems. This article describes how to avoid hidden but common errors and describes several techniques to help engineers discover hidden errors in software.

Structure testing or white-box testing can effectively detect logic, control flow, computing, and data errors in the code. This test requires a clear view of the internal work of the software (hence known as "white box" or "glass box") in order to understand the details of the software structure. It checks each conditional expression, mathematical operation, input, and output. Due to the large number of details to be tested, a structure test checks a software unit every time, usually a function or class.

Code reviews also use techniques that are as complex as implementing defects and identifying potential problems. Like a white box test, reviews are typically performed on individual software units, as an effective review process requires a centralized and detailed inspection.

Unlike review and white-box testing, functional testing or black-box testing assumes that there is no idea about the implementation of the software, and it tests the output driven by controlled inputs. Functional Testing consists of testing processes written by testers or developers that specify the expected program output for a specific set of program inputs. After the test is run, the tester compares the actual output with the expected output to find the problem. Black box testing can effectively identify unimplemented requirements, interface problems, performance problems, and errors in the most common functions of the program.

While combining these techniques can identify most of the errors hidden in a particular software program, they also have limitations. Code review and white-box testing only target a small amount of code each time, ignoring other parts of the system. Black box testing usually processes the system as a whole, ignoring the implementation details. Some important problems can be discovered only when they focus on the interaction of the entire system. traditional methods cannot identify these problems reliably. Check the software system as a whole to find out the specific cause of the problem. It is usually unlikely that every detail in the program is thoroughly analyzed and the interaction between the program and all other parts of the code, therefore, the analysis should be targeted at specific aspects of the program that may cause problems. This article will explore three of potential problem areas:

* Stack Overflow

* Competitive conditions

* Deadlock

Readers can read the second part of this article online. it will discuss the following questions:

* Timing problems

* Reentrant condition

All the above problems are common in systems that adopt multi-task real-time design technology.

Stack Overflow

The processor uses the stack to store temporary variables, pass parameters to the called functions, and save the "state" of the thread. If the system does not use virtual memory (in other words, it cannot transfer the memory page to the disk to release the memory space for other purposes), the stack will be fixed to the size of the product when it leaves the factory. If, for some reason, the stack gets out of the number range assigned by the programmer, the program becomes uncertain. Such instability may cause serious system faults. Therefore, it is critical to ensure that the system can be allocated to enough stacks in the worst case.

The only way to ensure that Stack Overflow never occurs is to analyze the code, determine the maximum stack usage of the program in various possible situations, and then check whether sufficient stacks are allocated. The test is unlikely to trigger a specific instantaneous input combination, resulting in the worst case of the system.

The concept of deep stack analysis is relatively simple:

1. create a call tree for each independent thread.

2. determine the stack usage of each function in the call tree.

3. check each call tree to determine which call path from the root to the external "leaf" requires the most stacks.

4. add the maximum stack usage of each independent thread call tree.

5. determine the maximum stack usage of each interrupt service program (ISR) within each interrupt priority and calculate the sum. However, if the ISR itself uses the stack of the interrupted thread without a stack, the maximum number of stacks used by the ISR should be added to each thread stack.

6. for each priority, plus the number of stacks used to save the processor status when the interrupt occurs.

7. if RTOS is used, the maximum number of stacks required for the internal use of RTOS is added (different from the system call triggered by the application code, which is included in step 2 ).

[1] [2] [3] [4] Next page