Troubleshooting of program timing problems in C Language

Troubleshooting of program timing problems in C Language

Abstr:]

For software that works collaboratively with multiple modules, the timing of program processing is very important. When the order of message processing is disordered, an exception occurs in the program.

This article is based on the author's practical project experience. The timing problems between software modules are analyzed in detail, which provides a deliberate disciplinary test for analyzing and solving software problems.

Key Words]

C language timing module development message

I. Problem Description

In A software version, two modules (module A and Module B) need to communicate with each other.

After the communication link is established. Module A sends A message to Module B, which carries the user number and serial number. After the message is successfully sent, module A stores the user number in A global variable according to the serial number.

Module B receives the message sent by module. Parse the user number and process it.

After processing, Module B returns the user number and serial number to module A as they are. Module A first searches for the original user number based on the received serial number, and compares it with the user number returned by Module B. If the user number is the same, you may be able to process it.

As shown in figure 1.

Figure 1 communication between module A and Module B

 

During Auto-renewal of the software version, it is found that the user number sent by module A does not match the user number returned by Module B, so the process may not continue.

View the log of module. The printed user number is the same as the received user number. The serial number is the same, but there is a problem when the strncmp function is used (the user number variable is of the string type) for comparison.

Ii. program running process of module

Because the user number ratio is completed in module A, the main focus is on the program running process of module.

Module A's program running process 2 shows:

Figure 2 program running process of module

See figure 2. In the message interaction process between module A and Module B, the time sequence is very important. The message processing sequence is not defined. The module A program is terminated abnormally.

 

Iii. Preliminary Analysis of the Cause

To determine whether the sent user number is really different from the received user number, we added a specific log before the program statement for comparing the two numbers. Print the user number, serial number, and the received user number and serial number to be sent.

 

After logs are added, we run the program again and find that the received user number and serial number are correct, while the sent user number and serial number print out a null value.

How can this happen? Didn't I copy the user number and serial number to the global variable during sending?

We added the log after copying the Program Statement for sending the user number and serial number, and wanted to print the value of the user number and serial number of the departure message.

Run the program again. The user number and serial number sent are correct. It seems that the copy is successful.

Through the above analysis, we can basically determine that there is no problem with copying and parsing. It seems that the processing sequence causes the user numbers to be mismatched.

Iv. Problem locating

We checked the log and found a strange phenomenon, that is, the message returned by the receiving module B printed in the log is earlier than the time when the user number and serial number are copied.

 

Why? We compared and checked the code. After messages are sent to Module B, module A is dormant for A period of time before copying messages. Module B returns the message in A very short time, and module A is still in sleep period. The message cannot be copied to the global variable.

Is it the fault of module A's sleep time? To verify our conjecture, we directly stare at the running dormant code for a trial. After the program runs again, check the log and find that everything is normal. No information is printed that the user number sent by module A does not match the user number returned by Module B, and the xingxu process of module A also runs.

It seems that this sleep time is in trouble.

This is indeed the case. Module B has a very short response time, so that when compared with the user number in the global variable, in fact, a user number of the string type is compared with a null value. Of course, a fault will occur.

This is also consistent with the fact that the user number and serial number are null.

Now that the truth is clear. We started to modify the code, copy the user number in module A to A global variable according to the serial number, put the code before sending the message to Module B, and keep module A's dormant code. Once again, I tried the modified program and everything was okay.

 

V. Summary

In the troubleshooting of this time series problem, program logs are mainly used to locate the problem.

 

Troubleshoot the problem. We have summarized the following experiences:

(1) detailed logs help locate the problem. To better understand where the problem occurs. We can add some pilot test logs to the key statements of the program. For analysis.

(2) In a program whose message processing order is very important, it is necessary to clarify the relationship between the processes and processes. Prevent the process from being "Offside.

(3) In the troubleshooting process, do not let alone any clues, and verify your ideas in a timely manner. Test the program.

If it is a program, there will be bugs. Therefore, we should not worry about the problems in the program. It is necessary to master the troubleshooting methods, so that we can achieve "don't change ". Solve different problems. We can be trained to improve our development capabilities.