A multi-thread software crash information collection method and device and related medium

Abstract

The application discloses a kind of multithread software crash information collection method, device and related medium, the method includes: pre-setting a global static hash table;When the code program of software is developed and completed, the monitoring object is implanted by code injection tool to code program;When code program runs to target function, call constructor;The thread ID of current thread is obtained by constructor, and the first crash identification string list associated with thread ID is obtained in hash table;When target function runs end, call release constructor;The thread ID of current thread is called by release constructor, and the second crash identification string list associated with thread ID is obtained in hash table;Obtain the target list of crash identification string list not empty;List content collection and analysis of target list.This application can improve the collection efficiency of software crash information, reduce the collection and analysis cost of software crash information.

Description

Technical Field

[0001] This invention relates to the field of computer software technology, and in particular to a method, apparatus and related medium for collecting multi-threaded software crash information. Background Technology

[0002] In Windows systems, the traditional method for collecting crash information of online software involves calling the exception listener function `SetUnhandledExceptionFilter` to set a callback interface. When the software crashes, the callback function generates a dump file (a memory image of the process), which is then uploaded to a server. Software engineers then download and analyze the dump files one by one to pinpoint the problem. This method significantly increases the cost of analyzing problems and the complexity of locating the root cause when encountering multi-threaded software crashes. Furthermore, this method not only incurs server maintenance costs but also consumes the time of software engineers dedicated to problem analysis and localization. In addition, this method requires a certain level of skill from the software engineers, which also increases labor costs. Summary of the Invention

[0003] This invention provides a method, apparatus, computer device, and storage medium for collecting multi-threaded software crash information, aiming to improve the efficiency of software crash information collection and reduce the cost of collecting and analyzing software crash information.

[0004] In a first aspect, embodiments of the present invention provide a method for collecting multi-threaded software crash information, including:

[0005] A global static hash table is pre-configured; wherein the hash table is indexed by storing thread IDs and contains a list of crash identifier strings;

[0006] Once the software code is developed, a code injection tool is used to inject monitoring objects into the code; wherein, the monitoring objects include constructors and destructors;

[0007] Run the code program, and when the code program reaches the target function, call the constructor through the monitored object;

[0008] The constructor obtains the thread ID of the current thread, and the hash table retrieves a list of first crash identifier strings associated with the thread ID.

[0009] When the target function finishes running, the destructor function is called through the monitored object;

[0010] The destructor function calls the current thread's thread ID and retrieves a list of second crash identifier strings associated with the thread ID from the hash table;

[0011] Traverse the hash table and obtain a list of targets where the list of crash identifier strings is not empty;

[0012] The list content data format of the target list is converted to obtain crash data, and the crash data is reported. Then, the reported crash data is collected and analyzed.

[0013] Secondly, embodiments of the present invention provide a multi-threaded software crash information collection device, comprising:

[0014] A hash table setting unit is used to pre-set a globally static hash table; wherein the hash table is indexed by the storage thread ID and contains a list of crash identifier strings;

[0015] The event tracking and injection unit is used to inject monitoring objects into the software code program through a code injection tool after the software code program has been developed; wherein, the monitoring objects include constructors and destructors;

[0016] The first calling unit is used to run the code program, and when the code program runs to the target function, it calls the constructor through the monitoring object;

[0017] The first acquisition unit is used to obtain the thread ID of the current thread through the constructor and to obtain a list of first crash identifier strings associated with the thread ID from the hash table;

[0018] The second calling unit is used to call the destructor function through the monitoring object when the target function finishes running;

[0019] The second acquisition unit is used to call the thread ID of the current thread through the destructor function and retrieve a list of second crash identifier strings associated with the thread ID from the hash table;

[0020] The hash table traversal unit is used to traverse the hash table and obtain a target list in which the list of crash identifier strings is not empty;

[0021] The reporting and collection unit is used to convert the list content data format of the target list to obtain crash data, report the crash data, and then collect and analyze the reported crash data.

[0022] Thirdly, embodiments of the present invention provide a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the multi-threaded software crash information collection method as described in the first aspect.

[0023] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the multi-threaded software crash information collection method as described in the first aspect.

[0024] This invention provides a method, apparatus, computer device, and storage medium for collecting multi-threaded software crash information. The method includes: pre-setting a globally static hash table; wherein the hash table is indexed by storing thread IDs and contains a list of crash identifier strings; after the software code program is developed, a monitoring object is injected into the code program using a code injection tool; wherein the monitoring object includes a constructor and a destructor; the code program is run, and when the code program reaches a target function, the constructor is called through the monitoring object; the thread ID of the current thread is obtained through the constructor, and a first list of crash identifier strings associated with the thread ID is obtained from the hash table; when the target function finishes running, the destructor is called through the monitoring object; the thread ID of the current thread is called through the destructor, and a second list of crash identifier strings associated with the thread ID is obtained from the hash table; the hash table is traversed, and a target list in which the crash identifier string list is not empty is obtained; the data format of the list content of the target list is converted to obtain crash data, and the crash data is reported, and then the reported crash data is collected and analyzed. This invention utilizes the features of object-oriented languages ​​to inject monitoring objects into the code program, and then obtains a list of crash identifier strings through the monitoring objects. This can improve the efficiency of collecting software crash information and reduce the cost of collecting and analyzing software crash information. Attached Figure Description

[0025] To more clearly illustrate the technical solutions of the embodiments of the present invention, the drawings used in the following description of the embodiments will be briefly introduced. Obviously, the drawings described below are some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0026] Figure 1 A flowchart illustrating a multi-threaded software crash information collection method provided in an embodiment of the present invention;

[0027] Figure 2 A flowchart illustrating the calling of a constructor in a multi-threaded software crash information collection method provided in an embodiment of the present invention;

[0028] Figure 3 A flowchart illustrating the calling of a destructor function in a multi-threaded software crash information collection method provided in an embodiment of the present invention;

[0029] Figure 4 This is a schematic diagram of the crash information collection process in a multi-threaded software crash information collection method provided in an embodiment of the present invention;

[0030] Figure 5 This is a flowchart illustrating a multi-threaded software crash information collection method provided in an embodiment of the present invention. Detailed Implementation

[0031] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0032] It should be understood that, when used in this specification and the appended claims, the terms "comprising" and "including" indicate the presence of the described features, integrals, steps, operations, elements and / or components, but do not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or collections thereof.

[0033] It should also be understood that the terminology used in this specification is for the purpose of describing particular embodiments only and is not intended to limit the invention. As used in this specification and the appended claims, the singular forms “a,” “an,” and “the” are intended to include the plural forms unless the context clearly indicates otherwise.

[0034] It should also be further understood that the term "and / or" as used in this specification and the appended claims refers to any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0035] Please see below. Figure 1 , Figure 1 The flowchart of a multi-threaded software crash information collection method provided in this embodiment of the invention specifically includes steps S101 to S108.

[0036] S101. A global static hash table is pre-set; wherein the hash table is indexed by the stored thread ID and contains a list of crash identifier strings;

[0037] S102. After the software code program is developed, a code injection tool is used to inject monitoring objects into the code program; wherein, the monitoring objects include constructors and destructors;

[0038] S103. Run the code program, and when the code program reaches the target function, call the constructor through the monitoring object;

[0039] S104. Obtain the thread ID of the current thread through the constructor, and obtain the list of first crash identifier strings associated with the thread ID from the hash table;

[0040] S105. When the target function finishes running, the destructor function is called through the monitoring object;

[0041] S106. Call the current thread's thread ID through the destructor function, and retrieve the list of second crash identifier strings associated with the thread ID from the hash table;

[0042] S107. Traverse the hash table and obtain the target list where the list of crash identifier strings is not empty;

[0043] S108. Convert the list content data format of the target list to obtain crash data, report the crash data, and then collect and analyze the reported crash data.

[0044] In this embodiment, a hash table is first created, indexed by thread IDs and containing a list of crash flag strings. Then, a monitoring object is injected into the code using a code injection tool. When the code reaches the target function, the constructor of the monitoring object is called, and the current thread ID is obtained through the constructor. Based on this thread ID, the corresponding first list of crash flag strings is retrieved from the hash table. When the target function returns, the destructor of the monitoring object is called, and the current thread ID is obtained through the destructor. Based on this thread ID, the corresponding second list of crash flag strings is retrieved from the hash table. The hash table is then traversed to obtain a non-empty target list, which is then formatted and reported.

[0045] This embodiment effectively reduces the costs of collecting crash information and analyzing and locating problems. Specifically, firstly, this embodiment does not use dump files for crash collection. Instead, it leverages a feature of object-oriented languages: an object is automatically released when it goes out of scope. Therefore, this embodiment uses a code injection tool to inject monitoring objects into each function of the source code, and then determines the location of the crash by analyzing the lifecycle of these monitoring objects. It should be noted that under normal circumstances, a monitoring object is created and destroyed. However, if a crash occurs, the monitoring object is only created and not destroyed. Therefore, after a crash in multi-threaded software, searching for undestroyed monitoring objects can locate all the functions that caused the crash. Furthermore, the undestroyed monitoring objects have a sequential order: the last one is the crashing function, and the functions preceding the crashing function are the functions that called it. This allows the entire chain of crash calls to be listed. Furthermore, in practical applications, the aforementioned crash call process is usually not very long, generally not exceeding 8,000 characters to describe completely. Therefore, the list of crash function call chains can be reported via GA4 (a free service provided by Google), and then analyzed and statistically analyzed using Google's backend analytics tools, easily generating crash analysis tables. Using the method provided in this embodiment not only reduces server costs but also lowers the cost of development, crash analysis, and localization. It can even utilize Google's reporting functions to generate charts showing the percentage of crashes and various version information. In addition, this embodiment does not require highly skilled personnel, thus possessing high applicability and scalability.

[0046] In a specific implementation, the code for defining a globally static hash table is expressed as: static QHash <qint64,QList <qstring>*>threadHashTbl.

[0047] In one embodiment, step S102 includes:

[0048] Traverse the code program and generate a class diagram;

[0049] The class diagram information is obtained through the ClassView plugin; wherein, the class diagram information includes function names, code files, and line numbers.

[0050] The monitored object is injected into the beginning of the function body according to the class diagram information;

[0051] Define the variables in the code program as CrashMonitor parameters;

[0052] It iterates through all function names in the class diagram provided by the classview plugin, locates the line number of the code file by the function name, and then searches down for variables containing the CrashMonitor definition to identify the injected monitoring object.

[0053] In this embodiment, when injecting the monitored object into the code program using a code injection tool, the corresponding code files are first traversed, and a corresponding class diagram is generated. Here, this embodiment adopts the open-source solution of Qt. Qt provides the ClassView plugin, so the ClassView plugin is used to obtain information such as all function names, code files, and line numbers in the class diagram. Then, based on this information, the monitored object is injected into the beginning of the function body. Because it is a local variable, the variable can be uniformly defined as CrashMonitor crashMonitor(monitorPointStr), where monitorPointStr can contain the name of the current function, the code file where the function is located, and the line number, etc., depending on the actual needs.

[0054] When it's necessary to scan already injected locations, iterate through all function names in the class diagram provided by the ClassView plugin, then locate the line number of the code in the specified file using the function, and then search downwards to see if it contains the variable defined by CrashMonitor. Through the above, we've completed three key points regarding code location (locating functions), injection (injecting objects into the beginning of functions), and de-location (identifying the monitored objects contained in a function).

[0055] In addition, the code injection tool described in this embodiment has the following functions: 1. It can quickly scan all source code and organize a class diagram tree structure, with the tree's sub-items listing all member functions; 2. It can inject all or select the source code range to be injected, and perform code injection on different code ranges of monitored objects; 3. It can scan the already injected locations and can batch delete or replace new monitored object code.

[0056] In one embodiment, step S102 further includes:

[0057] A monitoring object is created by tracking the location of the data point, and additional information for crash location is set for the monitoring object; wherein, the additional information includes class name, function name and source code line number.

[0058] In this embodiment, the monitoring object only needs to implement a constructor and a destructor. The constructor takes a string parameter, expressed in the code as follows: `CrashMonitor(const QString&monitorPointStr)`. This parameter is used to inject information such as the tracking point location when injecting the "monitoring object". It should be noted that the tracking point location mentioned in this embodiment can be understood as a function name. Specifically, the tracking point location is usually set to the start point of a function; that is, when execution reaches the start point of the function, the monitoring object is created. When execution reaches the end point of the function, the monitoring object is destroyed. Additionally, some information can be attached when the monitoring object is created, such as the class name, function name, and source code line number. This information can be considered as supplementary information, and after a crash, it can be uploaded to the backend via Ga4.

[0059] In one embodiment, step S104 includes:

[0060] Determine whether the thread ID exists in the hash table;

[0061] If the thread ID does not exist in the hash table, an empty list of crash identifier strings is created, the empty list of crash identifier strings is linked to the thread ID in the hash table, and the crash identifier string is added to the end of the list.

[0062] If the thread ID exists in the hash table, then obtain the first list of crash identifier strings associated with the thread ID, and add the crash identifier string to the end of the list.

[0063] In this embodiment, combined with Figure 2 The constructor retrieves the currently running thread ID and then queries the global static hash table `threadHashTbl` using that thread ID. If a thread with that ID exists in `threadHashTbl`, the first list of crash flag strings associated with it is retrieved, and the crash flag string `monitorPointStr` is appended to the end of the list. If a thread with that ID does not exist in `threadHashTbl`, an empty list of crash flag strings is created, associated with the current thread ID, and stored in the hash table (this process requires multi-threaded mutual exclusion operations), and then the crash flag string `monitorPointStr` is appended to the end of the list.

[0064] In one embodiment, step S106 includes:

[0065] Determine whether the thread ID exists in the hash table;

[0066] When it is determined that the thread ID exists in the hash table, a second list of crash identifier strings associated with the thread ID is obtained, and the crash identifier strings at the end of the list are deleted.

[0067] In this embodiment, combined with Figure 3 The destructor function retrieves the current thread's thread ID, which is then used to query the global static hash table `threadHashTbl`. If a thread with that ID exists in `threadHashTbl`, the associated second crash identifier string list is retrieved, and `monitorPointStr` (the crash identifier string) is removed from the end of the list. If no thread with that ID exists in `threadHashTbl`, no action is taken.

[0068] In one embodiment, step S107 includes:

[0069] Register a crash callback function through the exception handling interface function;

[0070] The crash callback function is used to traverse the hash table and retrieve a list of non-empty crash identifier strings associated with the stored thread ID from the hash table.

[0071] In this embodiment, the crash callback function onCrash is registered through the SetUnhandledExceptionFilter interface function. This function is automatically called by the system when the software system crashes. The main functions of this function are as follows: traverse the threadHashTbl table, find the list of crash identifier strings that have not been cleared under all threads, i.e., the target list, and then convert it into a general log character description format and report it through Ga4 or other methods.

[0072] In one embodiment, step S108 includes:

[0073] The contents of the target list are converted into a data format compatible with data analysis tools to obtain the crash data;

[0074] The crash data is reported through the data analysis tool plugin, and the reported crash data is collected through the data analysis tool background;

[0075] The collected crash data is exported to obtain tracking points, and analysis tables are generated, along with data statistics.

[0076] In this embodiment, combined with Figure 4 First, a target list of non-empty crash identifier strings is obtained by traversing the hash table. Then, the contents of the target list are converted into the corresponding data format. Since data is reported via GA4 as mentioned earlier, the contents of the target list are converted into a data format compatible with GA4. The GA4 plugin then reports the crash data, and GA collects the reported crash data. Simultaneously, the collected crash data is exported as tracking points, an analysis table is generated, and GA4's analysis tools are used for data statistics and other analysis operations.

[0077] Figure 5 This is a schematic block diagram of a multi-threaded software crash information collection device 500 provided in an embodiment of the present invention. The device 500 includes:

[0078] Hash table setting unit 501 is used to pre-set a globally static hash table; wherein the hash table is indexed by the storage thread ID and contains a list of crash identifier strings;

[0079] The instrumentation injection unit 502 is used to inject monitoring objects into the software program through a code injection tool after the software code program is developed; wherein, the monitoring objects include constructors and destructors;

[0080] The first calling unit 503 is used to run the code program, and when the code program runs to the target function, it calls the constructor through the monitoring object;

[0081] The first acquisition unit 504 is used to obtain the thread ID of the current thread through the constructor and to obtain a list of first crash identifier strings associated with the thread ID from the hash table;

[0082] The second calling unit 505 is used to call the destructor function through the monitoring object when the target function finishes running.

[0083] The second acquisition unit 506 is used to call the thread ID of the current thread through the destructor function and obtain a list of second crash identifier strings associated with the thread ID from the hash table;

[0084] Hash table traversal unit 507 is used to traverse the hash table and obtain a target list in which the list of crash identifier strings is not empty;

[0085] The reporting and collection unit 508 is used to convert the list content data format of the target list to obtain crash data, report the crash data, and then collect and analyze the reported crash data.

[0086] In one embodiment, the embedding unit 502 includes:

[0087] The code traversal unit is used to traverse the code program and generate a class diagram;

[0088] The class diagram information acquisition unit is used to acquire the class diagram information of the class diagram through the ClassView plugin; wherein, the class diagram information includes function names, code files, and line numbers;

[0089] An initial injection unit is used to inject the monitored object into the starting position of the function body according to the class diagram information;

[0090] A variable definition unit is used to define variables in the code program as CrashMonitor parameters;

[0091] The injection identification unit is used to traverse all function names in the class diagram provided by the classview plugin, locate the line number of the code file by the function name, and then search downwards for variables containing the CrashMonitor definition in order to identify the injected monitoring object.

[0092] In one embodiment, the first acquisition unit 504 includes:

[0093] The first judgment unit is used to determine whether the thread ID exists in the hash table;

[0094] The list creation unit is used to create an empty list of crash identifier strings if the thread ID does not exist in the hash table, establish a hash table association between the empty list of crash identifier strings and the thread ID, store it in the hash table, and add a crash identifier string to the end of the list.

[0095] The first list acquisition unit is used to acquire a first list of crash identifier strings associated with the thread ID if the thread ID exists in the hash table, and to add the crash identifier string to the end of the list.

[0096] In one embodiment, the second acquisition unit 506 includes:

[0097] The second judgment unit is used to determine whether the thread ID exists in the hash table;

[0098] The second list acquisition unit is used to acquire a second list of crash identifier strings associated with the thread ID when it is determined that the thread ID exists in the hash table, and to delete the crash identifier strings at the end of the list.

[0099] In one embodiment, the hash table traversal unit 507 includes:

[0100] The function registration unit is used to register crash callback functions through the exception handling interface function;

[0101] The third list retrieval unit is used to traverse the hash table using the crash callback function and retrieve a list of non-empty crash identifier strings associated with the stored thread ID from the hash table.

[0102] In one embodiment, the reporting and collection unit 508 includes:

[0103] The format conversion unit is used to convert the list content of the target list into a data format that is compatible with the data analysis tool to obtain the crash data;

[0104] The data reporting unit is used to report the crash data through the data analysis tool plugin, and to collect the reported crash data through the data analysis tool background.

[0105] The tracking point export unit is used to export tracking points from the collected crash data, generate analysis tables, and perform data statistics.

[0106] In one embodiment, the embedding unit 502 further includes:

[0107] An attached configuration unit is used to create a monitoring object based on the location of the data entry point and to set additional information for the monitoring object for crash location; wherein, the additional information includes class name, function name and source code line number.

[0108] Since the embodiments of the apparatus and the embodiments of the method correspond to each other, please refer to the description of the embodiments of the method for the embodiments of the apparatus, which will not be repeated here.

[0109] This invention also provides a computer-readable storage medium storing a computer program thereon, which, when executed, can perform the steps provided in the above embodiments. The storage medium may include various media capable of storing program code, such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0110] This invention also provides a computer device, which may include a memory and a processor. The memory stores a computer program, and when the processor calls the computer program in the memory, it can implement the steps provided in the above embodiments. Of course, the computer device may also include various network interfaces, power supplies, and other components.

[0111] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For the systems disclosed in the embodiments, since they correspond to the methods disclosed in the embodiments, the descriptions are relatively simple; relevant parts can be referred to in the method section. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

[0112] It should also be noted that, in this specification, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.< / qstring>

Claims

1. A method for collecting multi-threaded software crash information, characterized in that, include: A global static hash table is pre-configured; wherein the hash table is indexed by storing thread IDs and contains a list of crash identifier strings; Once the software code is developed, a code injection tool is used to inject monitoring objects into the code; wherein, the monitoring objects include constructors and destructors; Run the code program, and when the code program reaches the target function, call the constructor through the monitored object; The constructor obtains the thread ID of the current thread, and the hash table retrieves a list of first crash identifier strings associated with the thread ID. When the target function finishes running, the destructor function is called through the monitored object; The destructor function calls the current thread's thread ID and retrieves a list of second crash identifier strings associated with the thread ID from the hash table; Traverse the hash table and obtain a list of targets where the list of crash identifier strings is not empty; The list content data format of the target list is converted to obtain crash data, and the crash data is reported. Then, the reported crash data is collected and analyzed.

2. The multi-threaded software crash information collection method according to claim 1, characterized in that, Once the software code is developed, a code injection tool is used to inject monitoring objects into the code, including: Traverse the code program and generate a class diagram; The class diagram information is obtained through the ClassView plugin; wherein, the class diagram information includes function names, code files, and line numbers. The monitored object is injected into the beginning of the function body according to the class diagram information; Define the variables in the code program as CrashMonitor parameters; It iterates through all function names in the class diagram provided by the classview plugin, locates the line number of the code file by the function name, and then searches down for variables containing the CrashMonitor definition to identify the injected monitoring object.

3. The multi-threaded software crash information collection method according to claim 1, characterized in that, The step of obtaining the thread ID of the current thread through the constructor and retrieving the list of first crash identifier strings associated with the thread ID from the hash table includes: Determine whether the thread ID exists in the hash table; If the thread ID does not exist in the hash table, an empty list of crash identifier strings is created, the empty list of crash identifier strings is linked to the thread ID in the hash table, and the crash identifier string is added to the end of the list. If the thread ID exists in the hash table, then obtain the first list of crash identifier strings associated with the thread ID, and add the crash identifier string to the end of the list.

4. The multi-threaded software crash information collection method according to claim 1, characterized in that, The step of calling the current thread's thread ID through the destructor function and retrieving the list of second crash identifier strings associated with the thread ID from the hash table includes: Determine whether the thread ID exists in the hash table; When it is determined that the thread ID exists in the hash table, a second list of crash identifier strings associated with the thread ID is obtained, and the crash identifier strings at the end of the list are deleted.

5. The multi-threaded software crash information collection method according to claim 1, characterized in that, The step of traversing the hash table and obtaining a target list in which the list of crash identifier strings is not empty includes: Register a crash callback function through the exception handling interface function; The crash callback function is used to traverse the hash table and retrieve a list of non-empty crash identifier strings associated with the stored thread ID from the hash table.

6. The multi-threaded software crash information collection method according to claim 1, characterized in that, The process involves converting the list content data format of the target list to obtain crash data, reporting the crash data, and then collecting and analyzing the reported crash data, including: The contents of the target list are converted into a data format compatible with data analysis tools to obtain the crash data; The crash data is reported through the data analysis tool plugin, and the reported crash data is collected through the data analysis tool background; The collected crash data is exported to obtain tracking points, and analysis tables are generated, along with data statistics.

7. The multi-threaded software crash information collection method according to claim 1, characterized in that, The step of injecting monitoring objects into the software code program using a code injection tool after the software code program is developed also includes: A monitoring object is created by tracking the location of the data point, and additional information for crash location is set for the monitoring object; wherein, the additional information includes class name, function name and source code line number.

8. A multi-threaded software crash information collection device, characterized in that, include: A hash table setting unit is used to pre-set a globally static hash table; wherein the hash table is indexed by the storage thread ID and contains a list of crash identifier strings; The event tracking and injection unit is used to inject monitoring objects into the software code program through a code injection tool after the software code program has been developed; wherein, the monitoring objects include constructors and destructors; The first calling unit is used to run the code program, and when the code program runs to the target function, it calls the constructor through the monitoring object; The first acquisition unit is used to obtain the thread ID of the current thread through the constructor and to obtain a list of first crash identifier strings associated with the thread ID from the hash table; The second calling unit is used to call the destructor function through the monitoring object when the target function finishes running; The second acquisition unit is used to call the thread ID of the current thread through the destructor function and retrieve a list of second crash identifier strings associated with the thread ID from the hash table; The hash table traversal unit is used to traverse the hash table and obtain a target list in which the list of crash identifier strings is not empty; The reporting and collection unit is used to convert the list content data format of the target list to obtain crash data, report the crash data, and then collect and analyze the reported crash data.

9. A computer device, characterized in that, The system includes a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, implements the multi-threaded software crash information collection method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the multi-threaded software crash information collection method as described in any one of claims 1 to 7.

Images