Program exception crash positioning method, electronic equipment and storage medium

Abstract

The invention relates to the technical field of computers, in particular to a program abnormal crash positioning method, electronic equipment and a computer readable storage medium, which are applied to a Linux system of an embedded ARM (advanced RISC machines) architecture, and are characterized in that when a gcc compiler is used for compiling and linking a main application program, calling of a function gnumcountnc is inserted, and stack backtracking is performed in the function gnumcountnc, so that the abnormal crash of the program can be positioned. And obtaining an address of the current calling function, obtaining a thread pid and a thread name, and sending the information data to a watchdog process for storage. And when the main application program crashes abnormally, the watchdog process stores the stored information data to a log file according to a preset sequence, so that the abnormal crash of the main application program can be positioned. According to the positioning process, the difficulty and time consumption of reproducing problems on a client site are avoided, and the program abnormal crash positioning efficiency is improved.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method for locating program abnormal crash, an electronic device and a computer-readable storage medium. Background Art

[0002] As we all know, in the video surveillance industry, video surveillance equipment, such as cameras, usually use embedded systems, such as embedded ARM architecture Linux systems. The memory and flash space of these embedded systems are very limited. In order to ensure that video surveillance equipment can run stably under limited memory and flash space, the debugging tools in the release version are basically optimized. Therefore, when the video surveillance equipment has an abnormal application crash problem at the customer site, it is often difficult to capture effective information. The video surveillance equipment is located in different scenes at the customer site, and various abnormal crash problems will occur, including segmentation errors, illegal instructions, double release of dynamic memory pointers, etc. The existing methods are difficult to directly analyze such problems at the customer site. Most of them need to rely on the compiled debug version to reproduce the problem locally, capture the coredump file, and then perform further analysis based on the coredump file. Such an analysis process is inefficient. In addition, this analysis method also has defects such as the debug version software is large in size and cannot be directly put into the flash space for execution; the generated coredump file is too large to be stored in the flash space of the video surveillance device; and when the stack is destroyed, the coredump file cannot obtain effective information. Summary of the invention

[0003] In view of this, the present invention proposes a program abnormal crash positioning method, an electronic device and a computer-readable storage medium, aiming to solve the problem of low efficiency in program abnormal crash positioning in the existing Linux system based on embedded ARM architecture.

[0004] In order to solve the above problems, the present invention adopts the following technical solutions:

[0005] In a first aspect, the present invention proposes a method for locating a program abnormal crash, which is applied to a Linux system of an embedded ARM architecture, comprising:

[0006] Compile and link the main application program through the gcc compiler; wherein the compile and link include using the -pg parameter for the main application program during compilation, and inserting a call to the function __gnu_mcount_nc at the entry of each function of the main application program;

[0007] By performing stack backtracing in the function __gnu_mcount_nc, the address of the current calling function is obtained, and the thread pid and thread name of the current thread are obtained; wherein the address of the current calling function, the thread pid and thread name of the current thread together constitute information data;

[0008] Sending the information data to the watchdog process so that the watchdog process stores the information data in a buffer;

[0009] When the watchdog process detects that the main application program has crashed abnormally, the information data stored in the buffer is saved to a log file in a preset order, so that the abnormal crash of the main application program can be located by analyzing the log file.

[0010] Furthermore, compiling and linking the main application program by using the gcc compiler includes:

[0011] When the main application is compiled and linked by the gcc compiler, the -Wl parameter and the -Map parameter are used to generate a map file during the compilation and linking process. At the same time, the -marm parameter and the -mapcs parameter are used so that the generated code complies with the AAPCS specification; wherein the map file includes the address and size of each function;

[0012] Put the function __gnu_mcount_nc into a separate file to form a file containing the function __gnu_mcount_nc; when compiling and linking the file containing the function __gnu_mcount_nc, do not use the -pg parameter;

[0013] When compiling and linking files other than the one containing the function __gnu_mcount_nc, use the -pg parameter.

[0014] Furthermore, performing stack backtracing in the function __gnu_mcount_nc includes:

[0015] According to the stack frame structure conforming to the AAPCS specification, the lr register data stored in the stack is searched through the fp register to obtain the return address of the function, and at the same time, the fp register data of the previous level function stored in the stack is searched through the fp register to obtain the stack bottom address of the previous level function;

[0016] The return address of the function and the stack bottom address of the previous level function are calculated to obtain the calling relationship of each level of function.

[0017] Further, locating the abnormal crash of the main application by analyzing the log file includes:

[0018] By analyzing the log file, the address of the calling function, thread pid and thread name of the main application before the abnormal crash is obtained, and the abnormal crash of the main application is located in combination with the map file and the source code of the main application.

[0019] Further, the obtaining of the thread pid and thread name of the current thread includes: obtaining the thread pid of the current thread by calling the getpid() function, and obtaining the thread name of the current thread by calling the prctl(PR_GET_NAME) function;

[0020] The sending of the information data to the watchdog process includes: sending the serial number, the address of the currently called function, the thread pid of the current thread and the thread name of the current thread to the watchdog process through a message queue; wherein the serial number is generated in ascending order of data.

[0021] Furthermore, the preset order is the order of the data of the serial number from small to large, and the buffer is a 64K ring buffer.

[0022] Furthermore, the watchdog process detects that the main application program crashes abnormally, including:

[0023] The watchdog process executes a ps command once every preset period to obtain information about the currently running process;

[0024] It is determined whether the currently running process information includes the process information of the main application. If not, it is determined that the main application crashes abnormally.

[0025] Furthermore, after the watchdog process detects that the main application program crashes abnormally, it also includes: executing an automatic system restart operation.

[0026] In a second aspect, the present invention further provides an electronic device, comprising:

[0027] a memory for storing program instructions; and

[0028] The processor is used to execute the program instructions to implement the steps of the program abnormal crash location method as described above.

[0029] In a third aspect, the present invention further proposes a computer-readable storage medium, wherein the computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the program abnormal crash location method as described above are implemented.

[0030] Compared with the prior art, the beneficial effects of the present invention are: a method for locating abnormal program crash, an electronic device and a computer-readable storage medium, which are applied to a Linux system with an embedded ARM architecture, comprising: compiling and linking a main application through a gcc compiler; wherein the compiling and linking includes using a -pg parameter for the main application during compilation, and inserting a call to a function __gnu_mcount_nc at the entry of each function of the main application; obtaining the address of the current calling function and obtaining the thread pid and thread name of the current thread by performing stack backtracing in the function __gnu_mcount_nc; wherein the address of the current calling function, the thread pid and thread name of the current thread together constitute information data; sending the information data to a watchdog process so that the watchdog process saves the information data in a buffer; when the watchdog process detects that the main application has an abnormal crash, saving the information data saved in the buffer to a log file in a preset order, so that the abnormal crash of the main application can be located by analyzing the log file. It can be seen that the program abnormal crash positioning method, electronic device and computer-readable storage medium insert the call of the function __gnu_mcount_nc when compiling and linking the main application using the gcc compiler, and perform stack backtracing in the function __gnu_mcount_nc to obtain the address of the current calling function, and obtain the thread pid and thread name, and send these information data to the watchdog process for preservation. When the main application crashes abnormally, the watchdog process saves the saved information data to the log file in a preset order so as to be used to locate the abnormal crash of the main application. This positioning process avoids the difficulty and time-consuming of reproducing the problem at the customer site, and there is no need to make a debugging version to capture the coredump file, which improves the efficiency of locating the program abnormal crash, enhances the stability of the program, and has strong feasibility and good user experience. BRIEF DESCRIPTION OF THE DRAWINGS

[0031] Various other advantages and benefits will become apparent to those of ordinary skill in the art by reading the detailed description of the preferred embodiments below. The accompanying drawings are only for the purpose of illustrating the preferred embodiments and are not to be considered as limiting the present invention. Moreover, the same reference symbols are used throughout the accompanying drawings to represent the same components. In the accompanying drawings:

[0032] Figure 1 A schematic diagram of the flow chart of the first embodiment of the method for locating abnormal program crash of the present invention;

[0033] Figure 2 A schematic diagram of a flow chart of a second embodiment of a method for locating abnormal program crashes according to the present invention;

[0034] Figure 3This is a function stack frame structure diagram that complies with the AAPCS specification;

[0035] Figure 4 A schematic diagram of a flow chart of a third embodiment of a method for locating abnormal program crashes according to the present invention;

[0036] Figure 5 Schematic diagram of the stack data when function testA calls function testB;

[0037] Figure 6 It is a schematic diagram of the structure of an electronic device in a hardware operating environment involved in an embodiment of the present invention. DETAILED DESCRIPTION

[0038] The scheme in the embodiment of the present invention will be clearly and completely described below in conjunction with the drawings in the embodiment of the present invention. Obviously, the described embodiment is only a part of the embodiments of the present invention, not all of the embodiments. Based on the embodiments of the present invention, all other embodiments obtained by ordinary technicians in this field without creative work are within the scope of protection of the present invention.

[0039] It should be noted that if the embodiments of the present invention involve directional indications (such as up, down, left, right, front, back, etc.), the directional indications are only used to explain the relative position relationship, movement status, etc. between the components under a certain specific posture (as shown in the accompanying drawings). If the specific posture changes, the directional indication will also change accordingly.

[0040] In addition, if there are descriptions involving "first", "second", etc. in the embodiments of the present invention, the descriptions of "first", "second", etc. are only used for descriptive purposes and cannot be understood as indicating or suggesting their relative importance or implicitly indicating the number of technical features indicated. Therefore, the features defined as "first" and "second" may explicitly or implicitly include at least one of the features. In addition, the technical solutions between the various embodiments can be combined with each other, but they must be based on the ability of ordinary technicians in the field to implement them. When the combination of technical solutions is contradictory or cannot be implemented, it should be deemed that such a combination of technical solutions does not exist and is not within the scope of protection required by the present invention.

[0041] It should be noted that the embedded ARM (Advanced RISC Machine) architecture Linux system is a Linux operating system running on an embedded device based on the ARM architecture. The ARM architecture is a low-power, high-performance processor architecture that is widely used in mobile devices, embedded systems, and IoT devices. The embedded ARM architecture Linux system is usually tailored and optimized to adapt to the resource constraints of embedded devices, while providing complete operating system functions and support, enabling embedded devices to run complex applications and implement various functions.

[0042] It should be noted that gcc (GNU Compiler Collection) is an open source compiler collection that includes compilers for compiling multiple programming languages, such as C, C++, Objective-C, Fortran, and Ada. gcc is a powerful and widely used compiler suite that runs on multiple operating systems, including Linux, Unix, and Windows.

[0043] See also Figure 1 As shown, it is a flow chart of the first embodiment of the program abnormal crash location method of the present invention.

[0044] In this embodiment, the program abnormal crash location method is applied to the Linux system of embedded ARM architecture, including:

[0045] Step S100: compile and link the main application program using the gcc compiler.

[0046] The compiling and linking includes using a -pg parameter for the main application during compiling, and inserting a call to the function __gnu_mcount_nc at the entry of each function of the main application.

[0047] Specifically, compiling and linking is the process of converting source code into an executable program. Compiling is the process of converting source code into target code. The generated target code is in the form of machine language, but it cannot be run directly. Linking refers to the process of combining various modules (such as library files and target files) together, resolving the reference relationship between modules, and generating the final executable program. During the linking process, symbol resolution, address redirection and other operations are also performed, and finally a complete executable program is generated, which can be run on the computer. The operation of compiling and linking is to ensure that the source code is correctly converted into an executable program. When using the gcc compiler to compile and link the main application, the gcc compiler will automatically perform preprocessing, compilation, assembly, linking and other steps on the source code file, simplifying the entire compiling and linking process. The purpose of compiling and linking is to insert a function call at the entrance of each function so that the function call path can be recorded when the program is executed, so that stack tracing can be more convenient when the program crashes abnormally, and finally the abnormal crash of the program can be located.

[0048] Specifically, the -pg parameter is an option of the gcc compiler, which is used to generate an executable file for performance analysis (Profiling) during compilation and linking. The __gnu_mcount_nc function is an internal function used to support function-level performance analysis. It is usually automatically inserted into the program by the compiler, and can record the function call path during program execution, that is, record the call relationship between functions. When compiling and linking, the -pg parameter is used and the call of the function __gnu_mcount_nc is inserted at the entrance of each function, in order to insert a section of code at the beginning of each function in the executable file generated by compilation and linking, which is used to call the __gnu_mcount_nc function. When the program is executed, each time a function is entered, the inserted code will call the __gnu_mcount_nc function, so that the function call path and other information can be recorded. Through this compilation and linking method, after the program runs, the call relationship of each function can be collected, so as to perform performance analysis or locate program exception crashes.

[0049] Specifically, an application includes the main application, the program for processing application services, and the core program of the product. The main application is the entry point of the entire application and is responsible for coordinating the operation and control flow of the entire application. It contains some initialization operations, functions that call other modules or libraries, etc. The program for processing application services is the module or component responsible for implementing the core business logic of the application. It contains the main functions of the application, such as data processing, business logic processing, algorithm implementation, etc. The core program of the product is the core function or module of the product, which is an important part of the product and usually contains the key features or functions of the product. The main application, the program for processing application services, and the core program of the product play different roles in an application / software system, each responsible for different functions and tasks, and together constitute a complete application or product. For example, in a video surveillance device using an embedded ARM architecture Linux system, the main application is the user interface program in the software, which is responsible for displaying the monitoring screen, providing a user interaction interface, allowing users to view the monitoring screen, set monitoring parameters, etc. The program for processing application services is the part of the software responsible for processing the specific functional logic of the monitoring device, such as video data processing, alarm logic implementation, etc. The core program of the product is the part of the software that implements the core functions of the video surveillance device, usually including functions such as video stream acquisition, encoding and decoding, and storage. It should be noted that because the main application is usually the entry point for user interaction, the last location executed when the program crashes abnormally is often in the main application. Therefore, by compiling and linking in the main application, the function call path and execution location of the main application can be obtained when the program crashes abnormally, helping developers quickly locate the problem.

[0050] Step S200: by performing stack backtracing in the function __gnu_mcount_nc, the address of the current calling function is obtained, and the thread pid and thread name of the current thread are obtained.

[0051] The address of the currently called function, the thread pid and the thread name of the current thread together constitute the information data.

[0052] Specifically, during the function call process, each function call will create a new stack frame on the stack to store function parameters, local variables, and information that needs to be restored after the function call. By performing stack backtracing in the __gnu_mcount_nc function, you can access the stack frame of the current function call, and by analyzing the information in the stack frame, you can get the address of the currently called function.

[0053] Specifically, the thread pid is a unique identifier assigned by the operating system to each thread to distinguish different threads. The thread pid can help the operating system manage thread resources, such as scheduling, resource allocation, etc. The thread name is a highly readable identifier set to facilitate developers to identify and debug threads, which can help developers better understand the code logic, debug problems, and improve the maintainability and readability of the code. To obtain the thread pid (thread id) and thread name of the current thread, different methods can be used, depending on the programming language and operating system used. Generally speaking, in most programming languages ​​and operating systems, an API (Application Programming Interface) or function for obtaining the current thread pid and thread name is provided.

[0054] Step S300: Send the information data to the watchdog process so that the watchdog process stores the information data in a buffer.

[0055] Specifically, the watchdog process is a common system process that can be used to monitor and manage the running status of other processes. The main function of the watchdog process is to detect whether the system or other processes have abnormal conditions. If an abnormality is detected, the watchdog process will take corresponding measures, such as restarting the system or process, to ensure the stability and reliability of the system. The watchdog process is also used to receive and save thread information for further processing or monitoring. A buffer is a data structure used in a computer to temporarily store data, usually used to temporarily save data for subsequent processing or transmission. A buffer can be a continuous space in memory or a part of a file. Sending information data to the watchdog process, and the watchdog process saving the information data in the buffer can help realize the temporary storage and processing of information data, so that the information data can be analyzed, monitored or otherwise operated later, further improving the stability and reliability of the system.

[0056] Step S400: When the watchdog process detects that the main application program crashes abnormally, the information data stored in the buffer is saved to a log file in a preset order, so as to locate the abnormal crash of the main application program by analyzing the log file.

[0057] Specifically, a log file is a file that records the operating status, events and error information of the system. By analyzing the log file, the operating status of the system and the causes of abnormalities can be understood. The information data is saved to the log file, and by analyzing the information data saved in the log file, the specific cause of the abnormal crash of the main application can be located. Normally, continuously saving the information data to the log file in the flash will take up a large storage space. Therefore, it is only saved when the main application crashes abnormally, which can reduce unnecessary overhead while ensuring the normal operation of the system. If the operation of saving information data is always performed, it may cause excessive consumption of system resources and affect system performance. Therefore, the information data is first saved in the buffer, and only when it is confirmed that the main application crashes abnormally, the information data saved in the buffer is saved to the log file in a preset order, so that enough information can be obtained for troubleshooting when needed, while avoiding unnecessary waste of resources.

[0058] Specifically, the execution subject of the program abnormal crash location method of the embodiment of the present invention is an embedded system, including main process and watchdog process. The execution subject of step S100, step S200 and step S300 is the main process. The main process is mainly used for obtaining the address of the current calling function according to pile function (__gnu_mcount_nc), and the address of the current calling function and the thread pid and thread name of the current thread are sent to the watchdog process through the message queue. The execution subject of step S400 is the watchdog process. The watchdog process maintains a 64k ring buffer, circulates and saves the data information sent by the main process, and monitors whether the main process is abnormal, if abnormal, the information data in the buffer is saved in the flash log file, for subsequent analysis and location.

[0059] Compared with the prior art, the program abnormal crash positioning method of the embodiment of the present invention inserts the call of the function __gnu_mcount_nc when the main application is compiled and linked using the gcc compiler, and performs stack backtracing in the function __gnu_mcount_nc to obtain the address of the current calling function, and obtain the thread pid and thread name, and send these information data to the watchdog process for storage. When the main application crashes abnormally, the watchdog process saves the saved information data to the log file in a preset order so as to be used for locating the abnormal crash of the main application. This positioning process avoids the difficulty and time-consuming of reproducing the problem at the customer site, and there is no need to make a debugging version to capture the coredump file, which improves the efficiency of locating the program abnormal crash, enhances the stability of the program, and has strong feasibility and good user experience.

[0060] See also Figure 2As shown, it is a flow chart of the second embodiment of the program abnormal crash location method of the present invention.

[0061] Compared with other embodiments of the method for locating a program abnormal crash, this embodiment describes in detail the steps of compiling and linking the main application program by using the gcc compiler.

[0062] In this embodiment, in step S100, compiling and linking the main application program by using the gcc compiler includes:

[0063] Step S101: When the main application is compiled and linked by the gcc compiler, the –Wl parameter and the -Map parameter are used to generate a map file during the compilation and linking process. Meanwhile, the –marm parameter and the -mapcs parameter are used so that the generated code complies with the AAPCS specification.

[0064] The map file includes the address and size of each function.

[0065] Specifically, the -Wl parameter is used to pass parameters to the linker, and the -Map parameter is used to generate a map file for the linker. By combining these two parameters, a map file can be generated during the compilation and linking process. By viewing the map file, developers can understand the address distribution of each symbol (such as function, variable) in the program to help locate problems. When compiling and linking, the generated map file usually contains the following content;

[0066] a. Sections: Describes the location and size of each section (such as .text, .data, .bss, etc.) in the final executable file.

[0067] b. Symbol Table: Lists all global symbols (such as functions and global variables) and their addresses.

[0068] c. Memory Regions: describes the starting address and size of the memory region (such as .text, .data, .bss, etc.).

[0069] Specifically, the -marm parameter is used to generate code for the ARM instruction set, and the -mapcs parameter is used to generate code that complies with the AAPCS specification. Combining these two parameters can ensure that the generated ARM instruction set code complies with the AAPCS specification. AAPCS (ARM Architecture Procedure Call Standard) is the procedure call standard under the ARM architecture, which defines parameter passing, return value processing, register usage rules, etc. when calling a function. The AAPCS specification is designed to ensure that the code generated by different compilers can call each other, thereby improving the interoperability, portability and compatibility of the code. See Figure 3 As shown in the figure, it is a function stack frame structure diagram that complies with the AAPCS specification. Among them, fp points to the bottom of the current stack frame, and sp points to the top of the stack frame. The AAPCS specification requires that when entering a function, pc, lr, sp, and fp should be pushed into the stack in sequence, and when exiting, they should be popped out of the stack in sequence.

[0070] Step S102: putting the function __gnu_mcount_nc into a separate file to form a file containing the function __gnu_mcount_nc; when compiling and linking the file containing the function __gnu_mcount_nc, the -pg parameter is not used.

[0071] Step S103: When compiling and linking files other than the file containing the function __gnu_mcount_nc, use the -pg parameter.

[0072] Specifically, step S102 is a step of processing a file containing the function __gnu_mcount_nc. Step S103 is a step of processing other files except the file containing the function __gnu_mcount_nc. The function __gnu_mcount_nc is usually used for performance analysis and counts at each function call. In step S102, the function __gnu_mcount_nc is put into a separate file and the -pg parameter is not used when compiling and linking. The purpose of this is to accurately count the number of function calls during performance analysis and avoid affecting the result of abnormal crash positioning due to the interference of performance analysis. By processing the file containing the function __gnu_mcount_nc separately, the accuracy of performance analysis can be ensured. In step S103, the -pg parameter is used when compiling and linking files except the file containing the function __gnu_mcount_nc. The purpose of this is to collect more debugging information when an abnormal crash occurs, including function call relationships, stack information, etc., so as to locate the program abnormal crash more quickly. Through the above two different processing methods, the needs of performance analysis and debugging information collection can be taken into account in the process of locating program abnormal crashes, thereby more effectively solving program abnormal crash problems.

[0073] Specifically, compiling and linking the main application program by using the gcc compiler includes:

[0074] (1) When compiling and linking, use the -Wl parameter and the -Map parameter to generate a map file. The map file contains the address and size of each function.

[0075] (2) Put the __gnu_mcount_nc function into a separate file and compile it without the pg parameter.

[0076] (3) When compiling and linking other files, add the -pg parameter and add a call to the stub function (__gnu_mcount_nc) at the entry of each function.

[0077] (4) When compiling and linking, use the -marm parameter and the -mapcs parameter to use the AAPCS specification and its stack frame structure to trace back function calls and calculate the address of the currently called function.

[0078] The following is a detailed description of the implementation process of the program abnormal crash location method of this embodiment, which specifically includes:

[0079] (1) Obtaining call data

[0080] In the stub function (__gnu_mcount_nc), the address of the calling function is determined by backtracing the stack content, and the thread pid (obtained by the gettid() function), the thread name (obtained by the prctl(PR_GET_NAME) function) and the serial number (increasing in sequence) are obtained.

[0081] (2) Send call data

[0082] In the pile function (__gnu_mcount_nc), the call data (FuncCallInfo) is sent to the watchdog process through the message queue. Among them, the call data FuncCallInfo (data information) includes the sequence number, the address of the current call function, the thread pid and the thread name of the current thread.

[0083] (3) Watchdog process receives data

[0084] In the watchdog process, the call data (FuncCallInfo) sent by the main process is received through the message queue and saved in the 64k ring buffer. The call data received by the 64k ring buffer includes FuncCallInfo(1), FuncCallInfo(2), FuncCallInfo(3)... FuncCallInfo(x) represents the xth function call data of the main application, including the execution sequence number, the address of the calling function, the thread pid and the thread name.

[0085] (4) Main application abnormality determination

[0086] The watchdog process executes the ps command every 5 seconds, and confirms whether there is relevant information about the main application process based on the return data of the ps command, so as to determine whether the main application is normal.

[0087] (5) Record logs

[0088] When it is determined that the main application crashes abnormally, the address of the calling function, thread pid, thread name and serial number in the buffer are saved in the log file in the flash in the order of the serial number for subsequent analysis.

[0089] (6) Analyze logs

[0090] By viewing the log file in the flash, you can know the thread and function call path before the abnormal exit. Combined with the compiled map file and source code, you can quickly locate the problem.

[0091] The program abnormal crash location method of this embodiment is applied to the case of limited resources, and can quickly locate the program abnormal crash problem. When the program has an abnormal crash problem, the log file is saved to the flash, which provides a basis for subsequent analysis. The program abnormal crash location method occupies less flash and memory, and is very efficient in locating the program abnormal crash problem.

[0092] See also Figure 4 As shown, it is a flow chart of the third embodiment of the program abnormal crash location method of the present invention.

[0093] Compared with other embodiments of the method for locating program abnormal crash, this embodiment describes in detail all steps except the step of compiling and linking the main application program by the gcc compiler, and adds the step of executing the automatic system restart operation.

[0094] In this embodiment, the program abnormal crash location method is applied to the Linux system of embedded ARM architecture, including:

[0095] Step S100: compile and link the main application program using the gcc compiler.

[0096] The compiling and linking includes using a -pg parameter for the main application during compiling, and inserting a call to the function __gnu_mcount_nc at the entry of each function of the main application.

[0097] Specifically, the __gnu_mcount_nc function is an empty function that does not perform actual functions. It is only used for performance analysis and tracking when the function is called, so it is called a stub function. Stub functions are usually automatically generated and inserted into the code by the compiler or tool chain, and developers do not need to write them manually. When compiling a source file, use the -pg parameter to add a call to the stub function (__gnu_mcount_nc) at the entry of each function in this source file.

[0098] Step S201: According to the stack frame structure that complies with the AAPCS specification, the lr register data stored in the stack is searched through the fp register to obtain the return address of the function. At the same time, the fp register data of the previous level function stored in the stack is searched through the fp register to obtain the stack bottom address of the previous level function.

[0099] Specifically, the AAPCS specification defines the stack frame structure when a function is called under the ARM architecture, including the pc register (Program Counter), lr register (Link Register), sp register (Stack Pointer), and fp register (Frame Pointer). The pc register stores the address of the instruction currently being executed, which is used to indicate the address of the next instruction to be executed by the CPU. The lr register stores the return address when the function is called, that is, the address of the next instruction to be returned after the function is executed. The sp register points to the address of the current top of the stack and is used to manage the data on the stack, including parameters and local variables when the function is called. The fp register points to the stack frame of the current function, that is, the space allocated on the stack by the current function, including local variables and parameters. The fp register can be used to easily access the stack frame content of the current function. In the stack frame structure defined by the AAPCS specification, the meanings and functions of these registers are interrelated. For example, the lr register stores the return address, which is used to jump to the correct location when the function returns; the sp register manages the data on the stack, including the storage of parameters and local variables; the fp register points to the stack frame of the current function, which is convenient for accessing local variables and parameters. These registers work together to ensure correctness and consistency of function calls.

[0100] Step S202: Calculate the return address of the function and the stack bottom address of the previous level function to obtain the calling relationship of each level of function.

[0101] Specifically, the stack backtracking process includes at least two backtrackings. The first backtracking is to find the return address of the current function and the stack bottom address of the previous level function, and the second backtracking is to find the return address of the previous level function and the stack bottom address of the higher level function. Through these two backtrackings, the calling relationship of each level of function can be established, thereby restoring the entire process of function calling.

[0102] Specifically, the stack backtracing process based on the AAPCS specification includes: according to the stack frame structure, the lr register data stored in the stack can be found through the fp register. This data is the return address of the function. At the same time, the fp register data of the previous function stored in the function stack can also be found. This data points to the bottom of the stack of the previous function. This constitutes the stack backtracing process. The whole process is centered on fp. It finds the lr and fp data stored in each function stack in turn, calculates the function return address and the bottom address of the previous function stack, and thus finds the function call relationship at each level. The following takes function testA calling function testB (the two functions have no visible parameters and no local variables) as an example to illustrate the stack backtracing process:

[0103] Assume that the stack bottom address of function testA is 0x7fff008C. After function testA executes the instruction, it pushes the fp / sp / lr / pc registers onto the stack and recalculates fp. At this time, fp is the stack bottom address of function testA (0x7fff008C), and sp is the stack top address of function testA (0x7fff0007C). ​​Call the testB function and jump to the testB function. At this time, lr (return address) is 0x10450. Push the fp / sp / lr / pc registers onto the stack and recalculate fp. At this time, fp is the stack bottom address of function testB (0x7fff007C), and sp is the stack top address of testB (0x7fff0006C). When executing the instruction (nop: e1a00000) in the testB function, the stack data is as follows: Figure 5 As shown, it is a schematic diagram of the stack data of function testA calling function testB. Perform stack backtracing on the testB function, find the stack bottom address of testB through fp, and take out the data lr from the testB function stack, that is, return to the address of function testA (0x10450), and find the previous level calling function. The data fp taken out from the testB function stack is the stack bottom address (0xfff0008C) of the previous level calling function testA. So far, the previous level function address and stack bottom address of testA are found from the testA function stack, and the stack backtracing is completed in this cycle. In addition, by returning to the previous level function address in the stack backtracing of the testB function and comparing the function address and function length in the map file, the specific calling function name can also be determined.

[0104] Step S203: Get the address of the currently called function, get the thread pid of the current thread by calling the getpid() function, and get the thread name of the current thread by calling the prctl(PR_GET_NAME) function.

[0105] The address of the currently called function, the thread pid and the thread name of the current thread together constitute the information data.

[0106] Specifically, the getpid() function is a system call used to obtain the process ID (PID) of the current process, that is, the unique identifier of the current thread. The prctl() function is a process control function, and the PR_GET_NAME parameter indicates obtaining the thread name. By calling this function, the thread name of the current thread can be obtained.

[0107] Specifically, the information data includes the address of the currently called function, the thread pid of the current thread, and the thread name. Among them, the address of the currently called function can help accurately locate the location of the current code execution, which helps to locate the problem. The thread pid of the current thread is a unique identifier assigned by the operating system to each thread. A thread can be uniquely identified by the thread pid, which is convenient for thread management and tracking in the system. The thread name of the current thread can help identify and distinguish different threads, and is convenient for identification and recording in log files and debugging information.

[0108] Step S301: Send the serial number, the address of the current calling function, the thread pid of the current thread and the thread name of the current thread to the watchdog process through the message queue, so that the watchdog process saves the information data in the buffer.

[0109] The serial number is generated in ascending order of data.

[0110] Specifically, the sequence number is generated in the order of increasing data, which means that the sequence number is generated in the order of increasing data, that is, starting from 1 and increasing by 1 each time. For example, the sequence number of the first message is 1, the sequence number of the second message is 2, and so on. This method can ensure that each message has a unique sequence number, and the sequence numbers are continuously increasing, which is convenient for the receiver to process the messages in sequence and avoid the situation of confusing the order of messages or repeated processing. The increasing sequence number also helps to perform fast sorting and search operations when processing a large number of messages. In practical applications, message queues are usually used for communication between different processes or threads, and these processes or threads may send multiple messages at the same time, so adding sequence numbers to messages can effectively distinguish different messages and ensure the integrity and correctness of the messages.

[0111] Specifically, a message queue is an important mechanism for asynchronous communication in a distributed system. It is usually used to pass messages between different applications or components to achieve the effect of decoupling and asynchronous communication. In a message queue, the sender of a message sends the message to the queue, and the receiver of the message gets the message from the queue for processing. A message queue can store a large number of messages, and even if the sender and receiver do not communicate at the same time, the reliable delivery of messages can be guaranteed. Common message queue systems include RabbitMQ, Kafka, and ActiveMQ, which have different characteristics and applicability in different scenarios.

[0112] In some embodiments of the present application, the buffer is a 64K ring buffer.

[0113] Specifically, a ring buffer is a data structure, also known as a circular buffer or a ring queue. The end of the ring buffer is connected to the beginning to form a ring structure. It has a fixed-size storage space and can recycle the space. A 64K ring buffer means that the total size of this buffer is 64K (64 kilobytes). When data is written to the buffer, the data is stored in the free position of the ring buffer until the buffer is filled. If data continues to be written, the new data will overwrite the previously written data, realizing the recycling of data. In short, a 64K ring buffer is a data structure with a fixed size of 64K and can recycle space. It is suitable for situations where data needs to be written continuously and the data storage space is limited, such as embedded devices.

[0114] Step S401: the watchdog process executes a ps command once at a preset period to obtain information about the currently running process.

[0115] Specifically, the ps command is a commonly used command in Unix and Unix-like operating systems, which is used to display the process information running in the current system. By executing the ps command, you can obtain detailed information about each process, such as process ID (PID), process status, CPU usage, memory usage, etc. The watchdog process is a monitoring program that monitors the operation of other processes and takes measures when necessary. The watchdog process can be set to execute the ps command once every certain preset period, such as 5s, to obtain the process information of the processes running in the current system. By analyzing this process information, the watchdog process can detect abnormal situations, such as the unexpected termination of a critical process, and take corresponding measures in time, such as sending an alarm to notify the administrator.

[0116] Step S402: determine whether the currently running process information includes the process information of the main application; if not, confirm that the main application crashes abnormally.

[0117] Specifically, use the ps command to view process information and determine the process of the main application by process name or other identifiers. View the process status of the main application. Usually, the status of a normally running application is "R" (Running). If the status of the main application is other values, such as "Z" (zombie process) or blank (indicating that the process has terminated), it indicates that the corresponding application has crashed abnormally. If it is confirmed that the main application has crashed abnormally, the cause of the abnormal crash can be further analyzed. For example, check the system log file to locate the problem of the abnormal crash of the program.

[0118] Step S403: Save the information data stored in the buffer to the log file in a preset order, so as to obtain the address of the calling function, thread pid and thread name of the main application before the abnormal crash by analyzing the log file, and locate the abnormal crash of the main application in combination with the map file and the source code of the main application.

[0119] Specifically, simply relying on the function call path and thread information may not be able to fully determine the specific location of the abnormal crash, especially in complex applications, where there may be multi-threaded interactions, nested function calls, etc., and more information is needed to help locate the problem. The map file can provide a mapping relationship between the compiled address and the source code line number, which helps to map the address information in the log file to the specific location in the source code. If the application involves multi-threaded operations, it is also necessary to check the multi-threaded synchronization mechanism in the source code to avoid problems such as race conditions and deadlocks. Based on the above reasons, combining the function call path and thread information with the map file and source code for analysis can more accurately locate the program abnormal crash and improve the accuracy and reliability of positioning. Among them, the serial number is the serial number of the data, which increases in sequence and is used to indicate the order of data. The thread pid is used to record the thread pid when applying for memory. The thread name is used to record the thread name when applying for memory. The calling address of the function is the address of the currently executing function when the program is running.

[0120] Specifically, storing the log file that saves the information data in the flash is persistent, the information data will not be lost, and it is conducive to various subsequent data analysis. However, saving the information data in the buffer is temporarily stored in the memory, and the information data will be lost after the system is restarted or the power is off.

[0121] In some embodiments of the present application, the preset order is the order of the serial number data from small to large.

[0122] Specifically, the preset order is the order of the serial number data from small to large. Saving the information data to the log file according to the preset order can simplify the logic of data processing and make the data processing more intuitive and efficient.

[0123] Step S500: Execute the system automatic restart operation.

[0124] Specifically, when the main application crashes abnormally, the watchdog process can immediately perform an automatic system restart. By automatically restarting the system, the normal operation of the system and programs can be quickly restored, reducing system downtime and improving system availability and stability. It can also reduce the need for manual intervention, avoid the possibility of manual delays in recovery time or operational errors, and improve the system's automation level.

[0125] The program abnormal crash positioning method of the present embodiment can solve the problem of embedded device quickly locating program abnormal crash exit in customer environment or production environment. The program abnormal crash positioning method includes a watchdog program, which is used to monitor whether the main application is running normally, and saves the function call path sent when determining that the main application crashes abnormally. The program abnormal crash positioning method uses gcc-pg parameters to the main application when compiling and linking, and adds a pile function (__gnu_mcount_nc) at the beginning of each function of the main application. When the program is running, stack backtracking is performed in the pile function (__gnu_mcount_nc), the address of the current calling function is analyzed by the stack content, the current thread pid and thread name are obtained, and the sequential sequence number is added, and the data such as sequence number, function call address, thread pid, thread name are sent to the watchdog process through the message queue, and the watchdog process saves these data in the ring buffer successively, and when the main application crashes abnormally, the data in the ring buffer are saved in the log file according to the sequence number order. By analyzing the log file, the engineer can know the function call path and the thread before the main application crashes abnormally, and can quickly locate the problem in combination with the map file and the source code. When an application crashes abnormally, quickly locating the last executed position (thread and function) is of great significance for analyzing such problems. For problems such as segmentation errors, memory out of bounds, double free, etc. that cause application crashes abnormally, this program crash location method does not need to make a debug version to capture the core dump file. It can quickly locate the crashed thread and the function call path before the crash by simply viewing the log file in the flash, which improves the efficiency of solving such problems and thus improves the stability of the program.

[0126] The following is an embodiment of the electronic device provided by the present invention. The embodiment of the electronic device and the embodiment of the program abnormal crash location method described above are of the same concept, and the details not described in detail in the embodiment of the electronic device can refer to the embodiment of the program abnormal crash location method described above.

[0127] See also Figure 6 As shown, it is a schematic diagram of the structure of an electronic device in a hardware operating environment involved in an embodiment of the present invention.

[0128] In this embodiment, an electronic device includes:

[0129] Memory 1005, used to store program instructions; and

[0130] The processor 1001 is used to execute the program instructions to implement the steps of the program abnormal crash location method as described above.

[0131] The electronic device of the embodiment of the present invention can be a computing device such as a desktop computer, a notebook, a palm computer, and a server. Figure 6 As shown, the electronic device may include: a processor 1001 (e.g., a CPU), a network interface 1004, a user interface 1003, a memory 1005, and a communication bus 1002. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit, such as a keyboard (Keyboard), and the optional user interface 1003 may also include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may also be a storage device independent of the aforementioned processor 1001.

[0132] Those skilled in the art will understand that Figure 6 The electronic device structure shown in the figure does not constitute a limitation of the electronic device, and may include more or less components than shown in the figure, or combine certain components, or arrange the components differently.

[0133] like Figure 6 As shown, the memory 1005 as a computer storage medium may include an operating system, a network communication module, a user interface module and a computer program.

[0134] exist Figure 6 In the electronic device shown, the network interface 1004 is mainly used to connect to the background server and communicate data with the background server; the user interface 1003 is mainly used to connect to the client (user end) and communicate data with the client; and the processor 1001 can be used to call the computer program stored in the memory 1005. When the computer program is called and executed by the processor 1001, the steps of the above-mentioned program abnormal crash locating method are implemented.

[0135] The following is an embodiment of the computer-readable storage medium provided by the present invention. The embodiment of the computer-readable storage medium and the embodiment of the program abnormal crash location method and the electronic device described above belong to the same concept, and the details not described in detail in the embodiment of the computer-readable storage medium can refer to the embodiment of the program abnormal crash location method and the electronic device described above.

[0136] In this embodiment, a computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the program abnormal crash location method described above are implemented.

[0137] Since the electronic device and computer-readable storage medium of the present invention can implement the steps of the above-mentioned program abnormal crash locating method, they at least have all the beneficial effects brought by the technical solutions of the above-mentioned program abnormal crash locating method step embodiments, which will not be described one by one here.

[0138] The above description is only a partial or preferred embodiment of the present invention. Neither the text nor the drawings can limit the scope of protection of the present invention. All equivalent structural changes made by using the contents of the present invention specification and drawings under the overall concept of the present invention, or direct / indirect application in other related technical fields are included in the scope of protection of the present invention.

[0139] Those skilled in the art will appreciate that the embodiments of the present application may be provided as methods, systems or computer program products. Therefore, the present application may adopt the form of a complete hardware embodiment, a complete software embodiment, or an embodiment in combination with software and hardware. Moreover, the present application may adopt the form of a computer program product implemented on one or more computer-usable storage media (including but not limited to disk storage, CDROM, optical storage, etc.) containing computer-usable program codes.

[0140] The present application is described with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present application. It should be understood that each process and / or box in the flowchart and / or block diagram, as well as the combination of processes and / or boxes in the flowchart and / or block diagram, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, an embedded processor or other programmable data processing device to generate a machine, so that the instructions executed by the processor of the computer or other programmable data processing device generate instructions for implementing the processes in the flowchart and / or block diagram. Figure 1 A process or multiple processes and / or boxes Figure 1 A device that provides the functions specified in a block or multiple blocks.

[0141] These computer program instructions may also be stored in a computer-readable memory capable of directing a computer or other programmable data processing device to operate in a specific manner, so that the instructions stored in the computer-readable memory produce an article of manufacture comprising an instruction device, which implements the process Figure 1 A process or multiple processes and / or boxes Figure 1 A function specified in one or more boxes.

[0142] These computer program instructions can also be loaded onto a computer or other programmable data processing device so that a series of operating steps are executed on the computer or other programmable device to produce a computer-implemented process, thereby providing instructions for implementing the process. Figure 1 A process or multiple processes and / or boxes Figure 1 The steps for the functions specified in one or more boxes.

[0143] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention rather than to limit it. Although the present invention has been described in detail with reference to the above embodiments, ordinary technicians in the relevant field should understand that the specific implementation methods of the present invention can still be modified or replaced by equivalents. Any modification or equivalent replacement that does not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A method for locating abnormal program crashes, applied to an embedded ARM architecture Linux system, characterized in that: include: Compile and link the main application program through the gcc compiler; wherein the compile and link include using the -pg parameter for the main application program during compilation, and inserting a call to the function __gnu_mcount_nc at the entry of each function of the main application program; By performing stack backtracing in the function __gnu_mcount_nc, the address of the current calling function is obtained, and the thread pid and thread name of the current thread are obtained; wherein the address of the current calling function, the thread pid and thread name of the current thread together constitute information data; Sending the information data to the watchdog process so that the watchdog process stores the information data in a buffer; When the watchdog process detects that the main application program has crashed abnormally, the information data stored in the buffer is saved to a log file in a preset order, so that the abnormal crash of the main application program can be located by analyzing the log file.

2. The method for locating abnormal program crash according to claim 1, characterized in that: The main application is compiled and linked by the gcc compiler, including: When the main application is compiled and linked by the gcc compiler, the -Wl parameter and the -Map parameter are used to generate a map file during the compilation and linking process. At the same time, the -marm parameter and the -mapcs parameter are used so that the generated code complies with the AAPCS specification; wherein the map file includes the address and size of each function; Put the function __gnu_mcount_nc into a separate file to form a file containing the function __gnu_mcount_nc; when compiling and linking the file containing the function __gnu_mcount_nc, do not use the -pg parameter; When compiling and linking files other than the one containing the function __gnu_mcount_nc, use the -pg parameter.

3. The method for locating abnormal program crash according to claim 2, characterized in that: The stack backtrace is performed in the function __gnu_mcount_nc, including: According to the stack frame structure conforming to the AAPCS specification, the lr register data stored in the stack is searched through the fp register to obtain the return address of the function, and at the same time, the fp register data of the previous level function stored in the stack is searched through the fp register to obtain the stack bottom address of the previous level function; The return address of the function and the stack bottom address of the previous level function are calculated to obtain the calling relationship of each level of function.

4. The method for locating abnormal program crash according to claim 2, characterized in that: The locating the abnormal crash of the main application by analyzing the log file includes: By analyzing the log file, the address of the calling function, thread pid and thread name of the main application before the abnormal crash is obtained, and the abnormal crash of the main application is located in combination with the map file and the source code of the main application.

5. The method for locating abnormal program crash according to claim 1, characterized in that: The obtaining of the thread pid and thread name of the current thread comprises: obtaining the thread pid of the current thread by calling the getpid() function, and obtaining the thread name of the current thread by calling the prctl(PR_GET_NAME) function; The sending of the information data to the watchdog process includes: sending the serial number, the address of the currently called function, the thread pid of the current thread and the thread name of the current thread to the watchdog process through a message queue; wherein the serial number is generated in ascending order of data.

6. The method for locating abnormal program crash according to claim 5, characterized in that: The preset order is the order of the data of the serial number from small to large, and the buffer is a 64K ring buffer.

7. The method for locating abnormal program crash according to claim 1, characterized in that: The watchdog process detects that an abnormal crash of the main application occurs, including: The watchdog process executes a ps command once every preset period to obtain information about the currently running process; It is determined whether the currently running process information includes the process information of the main application. If not, it is determined that the main application crashes abnormally.

8. The method for locating abnormal program crash according to claim 1, characterized in that: After the watchdog process detects that the main application program crashes abnormally, the process further includes: executing an automatic system restart operation.

9. An electronic device, characterized in that: include: A memory for storing program instructions; as well as A processor is used to execute the program instructions to implement the steps of the program abnormal crash location method according to any one of claims 1 to 8.

10. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, and when the computer-executable instructions are executed by a processor, the steps of the program abnormal crash location method according to any one of claims 1 to 8 are implemented.

Images