Process fault positioning method and system and medium

Abstract

The invention relates to a process fault positioning method and system and a medium, and relates to the technical field of testing, and the method comprises the steps: receiving a data packet returned by a vehicle end through a vehicle cloud link; analyzing the data packet to extract key information, wherein the key information comprises an abnormal code and a running state; on the basis of the key information, the number of code lines where process crash occurs is positioned; and providing a positioning result to a developer for troubleshooting and repairing. According to the method, the code line number of the problem is quickly and accurately positioned by analyzing the returned data packet.

Description

Technical Field

[0001] The present invention relates to the field of testing technologies, and in particular, to a method, system, and medium for process fault location. Background Art

[0002] Currently, the problem of process crashes mainly relies on internal logs within modules for diagnosis and analysis. These logs are automatically generated by the system when a crash occurs, and developers can load the logs and coredump files in a local environment through traditional debugging tools (such as GDB) to gradually troubleshoot the root cause of the problem.

[0003] With the increase in the number of vehicles and the improvement of environmental complexity, the diagnostic method relying solely on internal logs exposes multiple deficiencies. The log information may be incomplete and unable to cover all problem scenarios; it has a high dependence on the debugging environment and requires manual installation of necessary underlying libraries, increasing complexity; in addition, for large-scale vehicle fault problems, the traditional method cannot efficiently locate the specific code line, resulting in low diagnostic efficiency and difficulty in meeting mass production requirements. Summary of the Invention

[0004] In view of the above-mentioned disadvantages of the prior art, the present invention provides a method, system, and medium for process fault location, which can quickly and accurately locate the code line of the problem by parsing the backhaul data packet.

[0005] To achieve the above object, the present invention adopts the following technical solutions.

[0006] In a first aspect, a method for process fault location provided by the present invention includes: Receiving a data packet backhauled from the vehicle end through a vehicle-cloud link; Parsing the data packet to extract key information, where the key information includes an exception code and a running status; Based on the key information, locating the code line where the process crash occurs; Providing the location result to the developer for fault troubleshooting and repair.

[0007] Further, as an implementation manner of the present invention, the data packet includes a minidump file and a coredump file.

[0008] Further, as an implementation manner of the present invention, it further includes: First, parsing the minidump file for preliminary problem analysis; Deciding whether to parse the coredump file according to the result of the preliminary problem analysis.

[0009] Further, as an implementation manner of the present invention, it further includes: Encapsulating a debugging environment in a cloud server; Provide the debugging environment for developers or testers to download and use.

[0010] Furthermore, as an implementation manner of the present invention, the debugging environment includes a GNU debugger.

[0011] Furthermore, as an implementation manner of the present invention, it further includes: Supplement the underlying libraries missing in the GNU debugger.

[0012] Furthermore, as an implementation manner of the present invention, the steps of locating the line number of the code where the process crash occurs include: Parse the exception code in the data packet; Analyze the program execution path corresponding to the exception code; Determine the specific line number of the code where the process crash occurs according to the program execution path and the running status.

[0013] Furthermore, as an implementation manner of the present invention, it further includes: Preprocess the data packet, including decompression and format conversion.

[0014] Furthermore, as an implementation manner of the present invention, it further includes: Establish a mapping relationship between the positioning result and the source code; Mark the specific location where the process crash occurs in the source code.

[0015] Furthermore, as an implementation manner of the present invention, it further includes: Automatically generate a fault report according to the positioning result, and the fault report includes the line number of the code where the crash occurs, the exception type, and the status of relevant variables.

[0016] In a second aspect, a process fault location system provided by the present invention includes: A data acquisition module, at least used to receive the data packet transmitted back by the vehicle end through the vehicle-cloud link; A data extraction module, at least used to parse the data packet to extract key information, and the key information includes an exception code and a running status; A fault location module, at least used to locate the line number of the code where the process crash occurs based on the key information; A result output module, at least used to provide the positioning result to the developer for fault troubleshooting and repair.

[0017] In a third aspect, a readable storage medium provided by the present invention adopts the following technical solution: A readable storage medium stores computer instructions, and when the computer instructions are executed by a processor, a process fault location method as described in any one of the above first aspects is implemented.

[0018] In summary, compared with the prior art, the present invention includes at least one of the following beneficial technical effects: By designing a data feedback mechanism for the vehicle-cloud link and an efficient data packet parsing algorithm, the present invention realizes the rapid upload and accurate parsing of vehicle-side process crash data, and can quickly locate the specific line number of the crash code. Compared with the traditional method that relies on internal module logs and manual debugging, the present invention solves the problems of incomplete log information and high dependence on the debugging environment, and greatly improves the accuracy and efficiency of problem diagnosis. In addition, the present invention has a high degree of automation, is applicable to large-scale problem troubleshooting of mass-produced vehicles, helps to shorten the fault resolution time, reduce the maintenance cost, and improve the stability and reliability of the vehicle system. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required for the description of the embodiments. Obviously, the drawings in the following description are only some embodiments of the present application. For those skilled in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0020] Figure 1 It is a flowchart of a specific embodiment of the process fault location method of the present invention.

[0021] Figure 2 It is a flowchart of another specific embodiment of the process fault location method of the present invention.

[0022] Figure 3 It is a schematic structural diagram of a specific embodiment of the process fault location system of the present invention. DETAILED DESCRIPTION OF THE EMBODIMENTS

[0023] The following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. Obviously, the described embodiments are only some embodiments of the present application, rather than all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative efforts belong to the scope of protection of the present application. In addition, it should be understood that the specific embodiments described herein are only used to illustrate and explain the present application, and are not used to limit the present application.

[0024] It should be noted that the description order of the following embodiments does not limit the preferred order of the embodiments of the present application. And in the following embodiments, each embodiment is described with emphasis. For parts not detailed in a certain embodiment, reference may be made to the relevant descriptions of other embodiments.

[0025] For the method steps described in the embodiments of the present invention, their execution order can be carried out in the order described in the specific implementation manner, or can be adjusted according to actual needs on the premise of being able to solve the technical problem, and the execution orders of the steps are not listed one by one here.

[0026] Refer to Figure 1 , a process fault location method provided by an embodiment of the present invention includes the following steps.

[0027] S1, receive the data packet transmitted back by the vehicle end through the vehicle-cloud link.

[0028] In some embodiments, the data packet can be uploaded to the cloud server through an in-vehicle network module (such as LTE, 5G or Wi-Fi).

[0029] In some embodiments, key data segments can also be transmitted to the cloud in a low-latency mode through the real-time data stream method, or in the way of batch data upload, first cache the data at the vehicle end, and then upload it in batches through the scheduling strategy.

[0030] In addition, in some embodiments, to ensure the stability and security of the transmission, the data packet can be protected by using an encrypted transmission protocol (such as TLS) to avoid data leakage or tampering.

[0031] In some embodiments, the transmission mechanism can also include a retransmission mechanism to cope with the transmission failure caused by network interruption and ensure that the data reaches the cloud completely and reliably.

[0032] S2, parse the data packet to extract key information, where the key information includes an exception code and a running state.

[0033] In some embodiments, the structure of the data packet can be parsed by using predefined parsing rules, and the exception code and the running state are extracted from the fixed fields.

[0034] In some embodiments, based on the dynamic parsing method, the data packet format can be identified through a protocol description file (such as protobuf or JSON schema) to flexibly process data structures of different versions.

[0035] In some embodiments, a data stream processing framework (such as Apache Kafka or Flink) can also be used to parse the data packets transmitted in real time, or an offline batch parsing tool can be used to process the cached historical data packets.

[0036] In some embodiments, to improve the efficiency and accuracy of parsing, a classification or extraction model based on machine learning can also be introduced to identify specific patterns of abnormal codes and running states, so as to adapt to the diversity of complex scenarios and data formats.

[0037] S3. Based on the key information, locate the line number of the code where the process crash occurs.

[0038] In some embodiments, the specific code line can be directly located by mapping the abnormal code to a symbol table.

[0039] In some embodiments, in combination with the coredump file, debugging tools (such as GDB) can be used to load debugging symbols and execution environments, gradually restore the crash scene and determine the code location.

[0040] In some embodiments, in combination with the backhaul running state information, the context at the time of the crash can be inferred through log timestamps, call stack analysis, or thread states, so as to more accurately locate the problem code.

[0041] In some embodiments, to improve efficiency, an automated location script or toolchain can also be used to match similar faults in the historical problem library according to the abnormal pattern, and quickly determine the location of potential problem codes.

[0042] S4. Provide the location result to the developer for troubleshooting and repair.

[0043] In some embodiments, by generating a detailed fault report, the located line number of the code, abnormal code, call stack information, and running state can be directly presented to the developer.

[0044] In some embodiments, in the way of an integrated development environment (IDE) plugin, the location result can be automatically loaded into the code editor, and the problem code is highlighted for quick modification.

[0045] In some embodiments, the result can also be uploaded to a defect tracking system (such as JIRA or Bugzilla), with detailed debugging information and proposed repair solutions attached, which is convenient for team collaboration.

[0046] Meanwhile, in some embodiments, a chart or flowchart for problem location can also be generated through a visualization tool to more intuitively display the cause and path of the fault, helping the developer quickly understand and solve the problem.

[0047] The process fault location method described in the embodiments of the present invention realizes the efficient backhaul of data through the vehicle-cloud link. Combining parsing and location algorithms, it can quickly and accurately determine the specific code line where the process crash occurs and present the results to developers in various ways. Compared with the traditional method that relies on logs and manual debugging, this method has the advantages of strong real-time performance, high location accuracy, and high degree of operation automation, significantly shortening the time for problem troubleshooting and repair. At the same time, its flexible data backhaul mechanism and intelligent parsing method are applicable to complex fault scenarios of large-scale vehicles, improving the efficiency and reliability of fault diagnosis, reducing maintenance costs, and providing an important guarantee for the stable operation of mass-produced vehicles.

[0048] Further, as an implementation manner of the present invention, the data packet includes a minidump file and a coredump file.

[0049] Specifically, the data packet includes a minidump file and a coredump file, which are respectively used for fault analysis in different scenarios. The minidump file is small in size and contains basic information at the time of crash, such as thread status, call stack, and register values, facilitating quick upload and preliminary problem location, and is suitable for scenarios with high real-time requirements. The coredump file records the complete memory state at the time of process crash, including global variables, stack information, and the running states of all threads, and can provide more comprehensive debugging information for in-depth analysis of complex problems.

[0050] By combining the use of these two dump files, fast and accurate fault diagnosis can be achieved on the premise of taking into account both data transmission efficiency and analysis depth.

[0051] Further, as an implementation manner of the present invention, the process fault location method further includes: first parsing the minidump file for preliminary problem analysis; and deciding whether to parse the coredump file according to the result of the preliminary problem analysis.

[0052] Specifically, the process fault location method adopts a hierarchical analysis strategy in data parsing, that is, first parsing the minidump file for preliminary problem analysis. By parsing the minidump, basic exception information such as call stack, thread status, or error code can be quickly obtained, thereby preliminarily locating the problem module or functional area.

[0053] In some implementation manners, if the preliminary analysis fails to provide sufficient diagnostic information, or the problem is more complex and involves deeper system behaviors, the coredump file is further parsed.

[0054] This method effectively balances the efficiency and depth of data transmission and analysis, providing more detailed diagnostic support for complex problems while ensuring timely response.

[0055] Further, as an implementation of the present invention, the process fault location method further includes: encapsulating a debugging environment in a cloud server; providing the debugging environment for developers or testers to download and use.

[0056] Specifically, the process fault location method provides convenient tool support for developers and testers by encapsulating a debugging environment in a cloud server.

[0057] The debugging environment includes all necessary underlying libraries, debugging tools (such as GDB), and configuration files to ensure that dump files (such as coredump) can be directly loaded and parsed.

[0058] Developers or testers can download the encapsulated environment from the cloud server, avoiding manually installing debugging tools locally or dealing with compatibility issues, thereby quickly reproducing the problem scenario and locating the cause of the fault.

[0059] This method improves the debugging efficiency, while ensuring the consistency and repeatability of the debugging environment, which helps with team collaboration and the standardized management of problem-solving.

[0060] Further, as an implementation of the present invention, the debugging environment includes the GNU debugger.

[0061] Specifically, the debugging environment contains the GNU debugger (GDB) for in-depth analysis and fault location of process crash problems. GDB is a powerful open-source debugging tool that supports loading dump files (such as coredump) and parsing the call stack, thread state, and memory layout through symbol tables to help developers quickly locate the code line where the crash occurred. At the same time, GDB supports setting breakpoints, checking variable values, and stepping through the code, facilitating in-depth analysis of the root cause of the problem. By integrating GDB into the encapsulated debugging environment, developers can use powerful debugging functions without additional installation and configuration, thereby improving the efficiency and accuracy of problem troubleshooting.

[0062] Further, as an implementation of the present invention, the process fault location method further includes: supplementing the underlying libraries missing in the GNU debugger.

[0063] Specifically, the process fault location method ensures the normal operation of the GNU debugger (GDB) when parsing core dump files (coredump) by supplementing the missing underlying libraries.

[0064] In an actual scenario, the debugging environment may be restricted in some debugging functions due to the lack of library files that match the system or program. For example, it may not be able to correctly load the symbol table or parse the call stack.

[0065] Therefore, in this embodiment, by analyzing the list of underlying libraries required for GDB to run, the missing library files are extracted from the target device or the corresponding system environment and installed into the debugging environment.

[0066] In addition, to improve portability and applicability, these supplementary libraries are encapsulated into a cloud debugging image, and developers and testers do not need to repeat the configuration when using it, thus ensuring the integrity and consistency of the debugging process.

[0067] Further, as an embodiment of the present invention, referring to Figure 2 , in step S3, locating the line number of the code where the process crashes includes the following sub-steps.

[0068] S31, parse the exception code in the data packet.

[0069] In some embodiments, the exception code value is directly extracted from the data packet through predefined exception code parsing rules.

[0070] In some embodiments, a protocol description file (such as protobuf or JSON schema) can be used to dynamically parse the fields in the data packet and extract the exception information.

[0071] In some embodiments, a pattern matching algorithm can also be used to analyze the format and position of the exception code in the data packet.

[0072] In addition, the parsing process can also be combined with an error code mapping table to associate the exception code with the corresponding error type or context information for subsequent analysis.

[0073] At the same time, for data packets in various encoding formats (such as ASCII, binary, or compressed format), the exception code can be parsed through the corresponding decoding module to ensure flexibility and accuracy in processing.

[0074] S32, analyze the program execution path corresponding to the exception code.

[0075] In some embodiments, the mapping relationship between the exception code and the symbol table can be used to directly determine the functions and modules where the exception occurs in the program.

[0076] In some embodiments, the call stack information in the dump file can be combined, and the program execution path can be reconstructed by tracing back layer by layer according to the stack frames.

[0077] In some embodiments, the execution flow before an exception can be deduced by associating context information with runtime logs and timestamps.

[0078] In some embodiments, static analysis tools can also be used to locate relevant branches based on the control flow graph of the program and the exception code, or dynamic analysis techniques can be used to reproduce the program behavior in the same environment, thereby deducing the detailed execution path.

[0079] S33. Determine the specific line number of the code where the process crash occurs according to the program execution path and the running state.

[0080] In some embodiments, a symbol table can be used to map the call stack address to the specific line number in the source code.

[0081] In some embodiments, debugging tools such as GDB can be used to load the dump file and, in combination with the symbol information of the program, directly parse out the code line that triggers the exception.

[0082] In some embodiments, the specific conditions and context at the time of the exception can also be analyzed by comparing the call stack frame information and the running state in the program execution path, further accurately locating the code position.

[0083] In addition, by combining the historical problem database or exception pattern matching technology, the line numbers of known problems can be quickly identified.

[0084] In some unknown scenarios, restoring the scene by dynamically simulating the program execution flow can also help determine the problem code line.

[0085] By parsing the exception code, analyzing the program execution path, and combining the running state to determine the specific crash code line, an accurate mapping from data to code is achieved. Compared with the traditional method that relies on log troubleshooting or single call stack analysis, this method can automatically reconstruct the program execution path, integrate exception information and context conditions, and quickly locate the code line where the problem lies. Its technical advantages lie in high positioning accuracy, wide application range, the ability to handle various crash types in complex scenarios, significantly shortening the problem diagnosis time, improving the development and maintenance efficiency, and providing strong technical support for the stability of large-scale systems.

[0086] Further, as an embodiment of the present invention, the process fault location method further includes: preprocessing the data packet, including decompression and format conversion.

[0087] Specifically, the process fault location method preprocesses data packets to improve the efficiency and accuracy of subsequent parsing. The preprocessing includes two parts: decompression and format conversion. Decompression is used to unzip compressed data packets (such as ZIP, GZIP) to restore the complete original data content. Format conversion is used to convert data packets from binary or other special formats (such as protobuf) to a general format that is easy to parse (such as JSON or XML).

[0088] This process ensures that the key information in the data packet can be correctly recognized by subsequent parsing algorithms, and at the same time unifies the data format, laying a foundation for subsequent automated analysis. Through the preprocessing step, various data types and transmission formats can be compatible, improving the flexibility and applicability of the fault location method.

[0089] Further, as an implementation manner of the present invention, the process fault location method further includes: establishing a mapping relationship between the location result and the source code; marking the specific location where the process crash occurs in the source code.

[0090] Specifically, the symbol table can be used to map the address information in the location result to the specific line number of the source code, and mark the abnormal location in the source code in the form of comments or tags.

[0091] In some implementation manners, the location information can also be integrated into a version management tool (such as Git), and specific marks are inserted in the corresponding source code lines for developers to view.

[0092] In some implementation manners, an integrated development environment (IDE) plugin can also be used to automatically load the location result and highlight the problem code line.

[0093] In some implementation manners, a marked crash report can also be generated in the code review tool for team collaboration analysis.

[0094] For dynamic projects, a visualization tool can also be used to display the specific location and context relationship of the crash code in the system module, enhancing the understanding and troubleshooting efficiency of the problem.

[0095] Further, as an implementation manner of the present invention, the process fault location method further includes: automatically generating a fault report according to the location result, and the fault report includes the line number of the code where the crash occurs, the type of exception, and the status of related variables.

[0096] Specifically, using the line number of the crash code, the type of exception, and the status of related variables output by the location algorithm, these information are organized into report content in a structured format (such as JSON or XML).

[0097] In some embodiments, a visual fault report can be generated through scripts or automated tools, including highlighted code lines, call stack information, and exception descriptions.

[0098] The fault report can also embed the running values of variables or screenshots of the memory state to provide detailed context.

[0099] In addition, the report can be exported in document form (such as PDF, HTML), or directly uploaded to a defect tracking system (such as JIRA) for easy sharing and collaboration among the development team.

[0100] By automatically generating the fault report, not only the efficiency of fault troubleshooting is improved, but also the transparency of the diagnosis process and the integrity of information are ensured.

[0101] An embodiment of the present invention also discloses a process fault location system.

[0102] Refer to Figure 3 , a process fault location system, including a data acquisition module 1, a data extraction module 2, a fault location module 3, and a result output module 4.

[0103] The data acquisition module 1 receives the data packets transmitted back from the vehicle end through the vehicle-cloud link. Specifically, the data acquisition module 1 can integrate communication modules such as LTE, 5G, or Wi-Fi to establish a stable vehicle-cloud data transmission channel; achieve low-latency data upload through real-time data transmission protocols (such as MQTT or HTTP / HTTPS); or adopt a batch transmission mode, using caching and scheduling mechanisms to centrally upload data packets during a specific time period. In addition, the data acquisition module 1 can support data encryption transmission protocols (such as TLS) to ensure data security, and design a retransmission mechanism to handle network interruptions or data loss problems, thereby ensuring the reliability and integrity of the transmission. Through these embodiments, the data acquisition module 1 can efficiently collect key data for fault location from the vehicle end.

[0104] The data extraction module 2 extracts key information by parsing data packets. Specifically, the data extraction module 2 can directly extract the exception code and running status in the data packet through predefined data structure parsing rules; the data extraction module 2 supports dynamic parsing, automatically identifies the data packet format through protocol description files (such as protobuf or JSON schema) and extracts key fields; the data extraction module 2 can also extract key information from unstructured or compressed format data through pattern matching algorithms. In addition, to improve the extraction efficiency, the data extraction module 2 can adopt a streaming processing framework (such as Apache Flink) to achieve real-time data parsing; or use batch processing tools to centrally parse the stored data packets. The data extraction module 2 can also combine with an exception code mapping table to associate the extracted information with specific exception types and contexts, providing complete data support for subsequent positioning. The above methods ensure the accuracy and flexibility of data extraction.

[0105] The fault location module 3 locates the line number of the code where the process crash occurs by analyzing key information. Specifically, the fault location module 3 uses a symbol table to directly map the exception code or memory address to the specific line number in the source code; the fault location module 3 combines the call stack information in the dump file, traces back frame by frame and restores the program execution path to determine the crash point; the fault location module 3 can also analyze the running status information (such as register values, variable status) to comprehensively judge the context conditions at the time of the crash, so as to accurately locate the code line. The fault location module 3 can also combine with the historical problem database and pattern matching algorithms to quickly identify the location of known problems; for complex scenarios, dynamically simulate the program execution flow, reproduce the crash scene through simulation to locate the problem. The above methods can adapt to diverse fault scenarios, ensuring the efficiency and accuracy of location.

[0106] The result output module 4 provides the fault location result to developers in multiple ways to support troubleshooting and repair. Specifically, the result output module 4 can generate a detailed fault report, including the line number of the code where the crash occurs, the exception type, the call stack information and the relevant variable status, and export it in a structured format (such as JSON, XML) or a document format (such as PDF, HTML); the result output module 4 can also be integrated into the development environment (IDE) to automatically highlight and mark the problem code line for quick viewing and modification. In addition, the result output module 4 supports uploading the location result to a defect tracking system (such as JIRA), attaching diagnostic details for team collaboration; the result output module 4 can also generate charts through visualization tools to display the path and context relationship of problem location. Through these implementation methods, the result output module 4 improves the clarity and efficiency of information transmission, providing strong support for quick repair.

[0107] The process fault location system described in the embodiments of the present invention realizes an efficient closed-loop from fault data feedback to problem repair support through the full-process integration of data acquisition, parsing, location, and result output. Compared with traditional log troubleshooting and manual debugging methods, the system has significant advantages in terms of real-time performance, automation, and accuracy. The data acquisition module 1 ensures the stability and integrity of data transmission; the data extraction module 2 efficiently parses and extracts key diagnostic information; the fault location module 3 accurately determines the crash code line through intelligent algorithms; the result output module 4 presents the location results to the development team in an intuitive and detailed manner. The entire system is applicable to complex and large-scale scenarios, effectively shortening the fault diagnosis time, reducing the maintenance cost, and improving the reliability and stability of system operation.

[0108] The embodiments of the present invention also disclose a readable storage medium.

[0109] A readable storage medium stores a computer program, and when the computer program is executed by a processor, it implements the steps of the process fault location method described in any one of the above embodiments. The computer-readable storage medium may include: any entity or device capable of carrying the computer program, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), and software distribution medium, etc. The computer program includes computer program code. The computer program code may be in the form of source code, object code form, executable file, or some intermediate form, etc. The computer-readable storage medium may include: any entity or device capable of carrying the computer program code, recording medium, USB flash drive, mobile hard disk, magnetic disk, optical disc, computer memory, read-only memory (ROM, Read-Only Memory), random access memory (RAM, Random Access Memory), and software distribution medium, etc.

[0110] Any process or method description shown in the flowchart or described in other ways herein can be understood as representing a module, segment, or part of code including one or more executable instructions for implementing a specific logical function or process. The scope of the preferred embodiments of the present invention includes additional implementations, where the functions may be executed in a substantially simultaneous manner or in the reverse order according to the functions involved, rather than in the order shown or discussed, which should be understood by those skilled in the technical field to which the embodiments of the present invention belong.

[0111] The logic and / or steps represented in the flowchart or otherwise described herein, for example, can be considered as a definable sequence list of executable instructions for implementing logical functions, and can be specifically implemented in any computer-readable medium for use by an instruction execution system, apparatus, or device (such as a computer-based system, a system including a processing module, or other systems that can fetch and execute instructions from the instruction execution system, apparatus, or device), or used in conjunction with these instruction execution systems, apparatuses, or devices.

[0112] 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 foregoing embodiments, those of ordinary skill in the art should understand that: they can still modify the technical solutions recorded in the foregoing embodiments, or perform equivalent replacements on some of the technical features; and these modifications or replacements do not make the essence of the corresponding technical solutions deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A process fault location method, characterized in that: include: Receive data packets sent back from the vehicle through the vehicle-cloud link; Parsing the data packet to extract key information, the key information including an abnormality code and an operating status; Based on the key information, locate the code line where the process crash occurs; Provide the positioning results to developers for troubleshooting and repair.

2. The process fault location method according to claim 1, characterized in that: The data package includes a mini dump file and a core dump file.

3. The process fault location method according to claim 2, characterized in that: Also includes: Firstly, the minidump file is parsed to perform a preliminary problem analysis; Whether to parse the core dump file is determined according to the result of the preliminary problem analysis.

4. The process fault location method according to claim 1, characterized in that: Also includes: Encapsulate the debugging environment in the cloud server; The debugging environment is provided to developers or testers for downloading and use.

5. The process fault location method according to claim 4, characterized in that: The debugging environment includes a GNU debugger.

6. The process fault location method according to claim 5, characterized in that: Also includes: Supplement the missing low-level libraries of the GNU debugger.

7. The process fault location method according to claim 5, characterized in that: The code lines where the positioning process crash occurs include: Parsing the abnormal code in the data packet; Analyze the program execution path corresponding to the abnormal code; The specific number of code lines where the process crash occurs is determined according to the program execution path and the running status.

8. The process fault location method according to claim 1, characterized in that: Also includes: The data packet is preprocessed, including decompression and format conversion.

9. The process fault location method according to claim 1, characterized in that: Also includes: Establishing a mapping relationship between the positioning result and the source code; Mark the exact location in the source code where the process crash occurred.

10. The process fault location method according to claim 1, characterized in that: Also includes: A fault report is automatically generated based on the positioning result, and the fault report includes the number of code lines where the crash occurred, the exception type, and the status of related variables.

11. A process fault location system, characterized in that: The system comprises: A data acquisition module, at least used to receive data packets sent back by the vehicle through the vehicle-cloud link; A data extraction module, at least used to parse the data packet to extract key information, wherein the key information includes an abnormality code and an operation status; A fault location module, at least used to locate the code line number where the process crash occurs based on the key information; The result output module is at least used to provide the positioning results to developers for troubleshooting and repair.

12. A readable storage medium, characterized in that: The readable storage medium stores computer instructions, and when the computer instructions are executed by a processor, a process fault locating method according to any one of claims 1 to 10 is implemented.

Images