Documentation
Rate This Document
Findability
Accuracy
Completeness
Readability
SubmitClose

C/C++ Process Suspends

Fault Locating

If the C/C++ process is not executed as expected and the process is still running in the background, the process is suspended. This is usually caused by deadlock or infinite loop of the process. C/C++ Process Suspends shows how to locate and rectify the fault.

Figure 1 Fault locating for C/C++ process suspension
  1. Run the top command to check whether the related process is running. It is found that the process is suspended.
  2. Recompile a program version that can be debugged. Run the new version to reproduce the problem. Debug the new version using GDB.
  3. Analyze the stack information and service logic to find out the cause.
  4. Modify and recompile the code. Then perform a verification.
    • If the problem is resolved, integrate the modification into the code.
    • If the problem persists, add the location information, and recompile and run the program.

Cases

Symptom

A server stops responding when some software is running on it.

Fault Locating

  1. Run the top command to check whether the process exists. If the process exists, the process is suspended.
  2. Recompile a program that can be debugged, run the new program, reproduce the problem, and query the process ID.
  3. Enter the debugging mode of the program.
    gdb attach 2573

    2573 is the process ID of the program.

  4. Enable logging and export the stack information to a file.
    1
2
3
    set logging file core_info.log
set logging on
thread apply all bt
  5. Check the thread status.
    1
    info threads

    Most threads are in the __lll_lock_wait state. There are mainly two waiting lock variables: resource1 and resource2.

  6. Run the print command to view the information about the two lock variables. __owner indicates the thread ID of the lock holder.

    As shown in the preceding figure, resource1 is held by thread 3889, and resource2 is held by thread 3892.

  7. Find the logs of the threads whose IDs are 3889 and 3892 from the collected log file.

    According to the status information of the two threads, thread 3889 holds the lock resource1 but requests resource2; thread 3892 holds the lock resource2 but requests resource1. As a result, a deadlock occurs, and all other threads that depend on the two locks are in the waiting state.

  8. According to the preceding stack information, threadOne and threadTwo calls each other, causing a deadlock. Check the service code logic, modify the code, and recompile and run the code. After confirming that the problem does not recur, integrate the modification into the code. The problem is resolved.
Parent topic: Troubleshooting