Program maintenance method and device, equipment and medium

Abstract

The invention relates to a program maintenance method and device, equipment and a medium in the technical field of programs, and the method comprises the steps: responding to a program crash event, capturing corresponding crash stack data and symbol mapping data, correspondingly pushing the crash stack data and the symbol mapping data to a to-be-analyzed queue, and storing the crash stack data and the symbol mapping data to a symbol database; responding to the crash interpretation event, calling symbol mapping data required for parsing the crash stack data in the to-be-parsed queue in a symbol database, and parsing readable crash information; according to the total number of information in each category obtained by classifying the readable crash information, marking the repair priority of the category, and storing the corresponding category and the repair priority associated with each piece of readable crash information into a crash information base for display on a crash platform; and responding to the crash report event, analyzing the corresponding readable crash information in the crash information base according to the corresponding report demand detailed rule to obtain a crash report, and pushing the crash report to a crash platform for display. The application can systematically assist the user in timely maintaining the crash program.

Description

Technical Field

[0001] This application relates to the field of program technology, and in particular, to a program maintenance method, its corresponding device, computer equipment, and computer-readable storage medium. Background Art

[0002] In today's digital age, application programs are widely born in various fields, from simple mobile applications to complex large enterprise systems, which bring great convenience to people's lives and work. However, program development is not a one-time job. When the program is officially released and put into actual use, due to the existence of various complex factors, crashes are inevitable. Once the program crashes, it will not only affect the normal user experience, but may also cause serious losses to enterprises and organizations. In order to ensure the stable operation of the program, it is necessary to solve the crash problem in a timely manner. Therefore, continuous maintenance of the program is crucial.

[0003] Traditional technologies have deficiencies in crash data processing. Once symbol mapping data is obtained, it is immediately used to parse the stack. Such a serial process has a high degree of coupling, resulting in a sharp drop in parsing efficiency in high-concurrency scenarios. Moreover, there is a lack of a dynamic priority evaluation mechanism for crash information, and it is difficult to automatically adjust the repair order according to the scope of the fault impact, resulting in a lag in responding to key issues.

[0004] In view of the deficiencies of traditional technologies, the applicant has made corresponding explorations. Summary of the Invention

[0005] The primary objective of this application is to solve at least one of the above problems and provide a program maintenance method, its corresponding device, computer equipment, and computer-readable storage medium.

[0006] To meet the various objectives of this application, the following technical solutions are adopted:

[0007] A program maintenance method provided to meet one of the objectives of this application includes the following steps:

[0008] Respond to a program crash event, capture the crash stack data corresponding to the event and push it to the queue to be parsed, and capture the symbol mapping data corresponding to the event and store it in the symbol database;

[0009] Respond to a crash interpretation event, pull the crash stack data from the queue to be parsed, and call the symbol mapping data required to parse the crash stack data in the symbol database to parse out the corresponding readable crash information;

[0010] Classifying the readable crash information, marking the repair priority of each category according to the total number of information in each category, and associating each readable crash information with the category to which it belongs and the repair priority of the category in the crash information library for visualization in the crash platform;

[0011] In response to a crash report event, according to the corresponding reporting requirements of the event, the corresponding readable crash information in the crash information library is analyzed to obtain a crash report, and the crash report is pushed to the crash platform for display.

[0012] On the other hand, a program maintenance device provided to meet one of the purposes of the present application includes a program crash module, a crash interpretation module, a crash annotation module and a report display module, wherein the program crash module is used to respond to a program crash event, capture the crash stack data corresponding to the event and push it to a queue to be parsed, and capture the symbol mapping data corresponding to the event and store it in a symbol database; the crash interpretation module is used to respond to a crash interpretation event, pull the crash stack data in the queue to be parsed, and call the symbol mapping data required to parse the crash stack data in the symbol database to parse the corresponding readable crash information; the crash annotation module is used to classify the readable crash information, mark the repair priority of the category according to the total number of information in each category, associate each readable crash information with the category to which it belongs and the repair priority of the category, and store it in a crash information library for visual display in the crash platform; the report display module is used to respond to a crash report event, analyze the corresponding readable crash information in the crash information library according to the report requirement details corresponding to the event, obtain a crash report, and push it to the crash platform for display.

[0013] On the other hand, a computer device provided to meet one of the purposes of the present application includes a central processing unit and a memory, wherein the central processing unit is used to call and run a computer program stored in the memory to execute the steps of the program maintenance method described in the present application.

[0014] On the other hand, a computer-readable storage medium is provided to meet another purpose of the present application, which stores a computer program implemented according to the program maintenance method in the form of computer-readable instructions. When the computer program is called and executed by a computer, the steps included in the method are executed.

[0015] The technical solution of this application has many advantages, including but not limited to the following:

[0016] In the process of program maintenance, when the monitoring program crashes, this application automatically responds to the crash event, captures the crash stack data and pushes it to the queue to be parsed, and at the same time captures the symbol mapping data and stores it in the symbol database. When it is necessary to interpret the cause of the crash, the crash stack data is pulled from the queue to be parsed, and the symbol mapping data in the symbol database is called for parsing to obtain readable crash information. Then, these readable crash information are classified, the number of information in each category is counted, and the repair priority is marked according to the quantity. Finally, this information is stored in the crash information library, and according to the detailed requirements of the crash report event, a crash report is generated and pushed to the crash platform for display, for the maintenance personnel to refer to and process. It can be seen that by storing the crash stack data and the symbol mapping data separately (the queue to be parsed and the symbol database), and implementing asynchronous parsing and dynamic resource scheduling, avoiding the traditional serial processing mode, the symbol parsing module can call the mapping data as needed, effectively reducing the probability of I / O blocking, improving the throughput of processing high-concurrency crash events. Moreover, an adaptive priority marking based on the total amount of information is implemented, and the appropriate repair priority is assigned by quantitatively analyzing the volume of various crashes, ensuring that important and urgent crashes are processed first. Furthermore, by matching the report requirement details and summarizing the crash report in a timely manner and displaying it, the users in the platform can clearly understand the overall crash situation and take appropriate program maintenance measures in a timely manner. Brief Description of the Drawings

[0017] The above and / or additional aspects and advantages of this application will become obvious and easy to understand from the following description of the embodiments in conjunction with the drawings, where:

[0018] Figure 1 is a schematic flowchart of a typical embodiment of the program maintenance method of this application;

[0019] Figure 2 is a schematic block diagram of the principle of the program maintenance device of this application;

[0020] Figure 3 is a schematic structural diagram of a computer device adopted by this application. Detailed Embodiments

[0021] The embodiments of this application are described in detail below. The examples of the embodiments are shown in the drawings, where the same or similar reference numerals indicate the same or similar elements or elements with the same or similar functions from beginning to end. The embodiments described below by referring to the drawings are exemplary and are only used to explain this application, and cannot be construed as limiting this application.

[0022] Those skilled in the art can understand that, unless specifically stated otherwise, the singular forms "a", "an", "the" and "said" used herein may also include the plural forms. It should be further understood that the term "comprising" used in the specification of this application means the presence of the stated features, integers, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integers, steps, operations, elements, components and / or their groups. It should be understood that when we say that an element is "connected" or "coupled" to another element, it can be directly connected or coupled to other elements, or there may also be intermediate elements. In addition, the "connection" or "coupling" used herein may include wireless connection or wireless coupling. The phrase "and / or" used herein includes all or any unit and all combinations of one or more of the associated listed items.

[0023] Those skilled in the art can understand that, unless otherwise defined, all terms used herein (including technical terms and scientific terms) have the same meaning as the general understanding of those of ordinary skill in the art to which this application belongs. It should also be understood that terms such as those defined in a general dictionary should be understood to have a meaning consistent with the meaning in the context of the prior art, and will not be interpreted in an idealized or overly formal sense unless specifically defined as here.

[0024] Those skilled in the art can understand that the "client", "terminal", and "terminal device" used herein include both devices with a wireless signal receiver that only has the ability to receive and no ability to transmit, and devices with receiving and transmitting hardware that can perform two-way communication on a two-way communication link. Such devices can include: cellular or other communication devices such as personal computers, tablet computers, etc., which have a single-line display or a multi-line display or a cellular or other communication device without a multi-line display; PCS (Personal Communications Service), which can combine voice, data processing, fax, and / or data communication capabilities; PDA (Personal Digital Assistant), which can include a radio frequency receiver, a pager, Internet / intranet access, a web browser, a notepad, a calendar, and / or a GPS (Global Positioning System) receiver; conventional laptop and / or palm-top computers or other devices, which are conventional laptop and / or palm-top computers or other devices with and / or including a radio frequency receiver. The "client", "terminal", and "terminal device" used herein can be portable, transportable, installed in a vehicle (air, sea, and / or land), or suitable for and / or configured to run locally, and / or run in a distributed form at any other location on the earth and / or in space. The "client", "terminal", and "terminal device" used herein can also be a communication terminal, an Internet access terminal, a music / video playback terminal, for example, it can be a PDA, a MID (Mobile Internet Device), and / or a mobile phone with music / video playback function, or it can also be a smart TV, a set-top box, etc.

[0025] The hardware referred to by names such as "server", "client", and "service node" in this application is essentially an electronic device with the equivalent capabilities of a personal computer, and is a hardware device with the necessary components disclosed by the von Neumann principle, including a central processing unit (including an arithmetic unit and a controller), a memory, an input device, and an output device. The computer program is stored in its memory, and the central processing unit loads the program stored in the external memory into the memory for execution, executes the instructions in the program, and interacts with the input / output devices to complete specific functions.

[0026] It should be noted that the concept of "server" in this application can similarly be extended to apply to server clusters. According to the network deployment principles understood by those skilled in the art, the servers should be logically divided. Physically, these servers can either be independent of each other but can be called through interfaces, or integrated into a single physical computer or a set of computer clusters. Those skilled in the art should understand this flexibility and should not be restricted by it in the implementation of the network deployment method of this application.

[0027] One or several technical features of this application, unless expressly specified, can either be deployed on the server and accessed by the client remotely invoking the online service interface provided by the server, or directly deployed and run on the client for access.

[0028] The neural network models cited or possibly cited in this application, unless expressly specified, can either be deployed on a remote server and remotely invoked by the client, or deployed on a client with sufficient device capabilities for direct invocation. In some embodiments, when it runs on the client, its corresponding intelligence can be obtained through transfer learning to reduce the requirements for the client's hardware operating resources and avoid over-occupying the client's hardware operating resources.

[0029] All kinds of data involved in this application, unless expressly specified, can either be remotely stored on the server or stored on the local terminal device, as long as it is suitable for being invoked by the technical solution of this application.

[0030] Those skilled in the art should be aware that although the various methods of this application are described based on the same concept and thus show commonality with each other, unless otherwise specified, these methods can all be executed independently. Similarly, for the various embodiments disclosed in this application, they are all proposed based on the same inventive concept. Therefore, for concepts with the same expression, as well as concepts that are only appropriately transformed for convenience although the expression is different, they should be equivalently understood.

[0031] For the various embodiments to be disclosed in this application, unless expressly stated to be mutually exclusive, the relevant technical features involved in each embodiment can be cross-combined to flexibly construct new embodiments, as long as this combination does not deviate from the creative spirit of this application and can meet the requirements in the prior art or solve certain deficiencies in the prior art. Those skilled in the art should be aware of this flexibility.

[0032] A program maintenance method of the present application can be programmed as a computer program product and implemented by running on a client or a server. For example, in an exemplary application scenario of the present application, it can be deployed and implemented in the server of an e-commerce platform. Thus, by accessing the interface opened after the computer program product runs, human-computer interaction can be performed with the process of the computer program product through a graphical user interface to execute this method.

[0033] Please refer to Figure 1 , in a typical embodiment of the program maintenance method of the present application, the following steps are included:

[0034] Step S1100: Respond to a program crash event, capture the crash stack data corresponding to this event and push it to the queue to be parsed, and capture the symbol mapping data corresponding to this event and store it in the symbol database;

[0035] In a recommended embodiment, the queue to be parsed is stored in Redis to ensure high-speed reading and writing of the queue.

[0036] A crash reporting service is pre-deployed in the crash platform to monitor the running status of Android applications and iOS applications. When any application crashes, it adapts to the type and crash layer of the application, or adapts to the type of the application to capture the corresponding crash stack data and push it to the queue to be parsed. <Object:

[0037] To report the corresponding crash stack data generated by a crash event that occurs in the Java layer of an Android application, the crash reporting service configures an exception handler (UncaughtExceptionHandler) for each thread in the thread pool running in the application in advance. It can detect the situation where a certain thread terminates due to an uncaught exception. Thus, when a crash occurs in the Java layer of the application, the crash stack data can be obtained from the method of UncaughtExceptionHandler.uncaughtException.

[0038] The configuration of the exception handler can be achieved through the Thread.setDefaultUncaughtExceptionHandler method. In this method, it can be defined to upload the generated crash stack data to the crash platform. Subsequently, the crash reporting service in the crash platform is called to push the received crash stack data to the queue to be parsed. In addition, the specific content to be written in the crash stack data can also be defined in this method, mainly including the crash stack trace information, crash timestamp, version number of the application, and can also include any one or more of the device UID, model, CPU architecture, manufacturer, Android version number, logcat log, syslog log, etc., as the content for crash assisted analysis, which is written by those skilled in the art as needed.

[0039] In order to report the corresponding crash stack data generated by a crash event occurring in the Native layer of an Android application, the crash reporting service configures BreakPad in the project file of the application in advance. Thus, when a crash occurs in the Native layer of this application, the client component in BreakPad reads information such as the status of the current thread, loaded executable files, shared libraries, etc., writes them into a Minidump file and outputs it. In addition, it can also be configured that BreakPad uploads the Minidump file to the crash platform using an HTTP POST request. Subsequently, the crash reporting service in the crash platform is called to push the received Minidump file to the queue to be parsed as crash stack data. It can be understood that those skilled in the art can also flexibly configure this application so that any one or more of the device UID, model, CPU architecture, manufacturer, application version number, Android version number, logcat log, syslog log, etc. corresponding to the device at the time of its crash can be obtained. After being uploaded together with the Minidump file as the content for crash assisted analysis, they form the crash stack data.

[0040] The Minidump file usually contains a Minidump Header: providing general information about the dump file including the version and the number of streams; Thread List: providing context information of all threads at the time of the crash; Module List: providing the paths and symbol information of all loaded blocks (such as DLL files); Exception: providing the exception information that caused the crash; Memory List: providing the memory ranges dumped at the time of the crash.

[0041] The crash reporting service generates corresponding crash stack data for reporting crash events that occur in iOS applications. By pre-configuring a log export tool (e.g., libimobiledevice) in the application, when the application crashes, the crash stack log (crash stack log) is exported and uploaded to the crash platform. Subsequently, the crash reporting service in the crash platform is called, and the received crash stack log is pushed as crash stack data to the parsing queue. It can be understood that a person skilled in the art can also flexibly configure the application so that any one or more of the UID, model, CPU architecture, manufacturer, application version number, etc. of the corresponding device can be obtained when the application crashes, as content for crash-assisted analysis. After being uploaded together with the crash stack log, they form the crash stack data.

[0042] The symbol processing service is pre-deployed in the crash platform, which serves to collect the symbol mapping tables generated by the CI / CD system and process them into symbol mapping data for storage in the symbol database.

[0043] It can be understood that applications developed for Android are written in Java code, and there are many software tools on the market that can easily decompile these files. To protect the intellectual property rights of the software and prevent competitors or malicious attackers from easily obtaining and understanding the code logic, ProGuard or R8 needs to be used to compress, obfuscate, and optimize the code, comprehensively reducing the storage volume occupied by the application. Thus, for the symbol processing service to parse the corresponding crash stack data generated by crash events occurring in the Java layer of Android applications, when the project of the application is released and an APK is generated, the mapping file is found from the build output directory of the project, and its storage path is usually under app / build / outputs / mapping / release. The mapping file is used as the symbol mapping table, and the id of the symbol mapping table is set to the version number of the application concatenated with the timestamp corresponding to the release of the application. The symbol mapping table is associated with its id to form symbol mapping data for storage in the symbol database.

[0044] For the symbol processing service to parse the corresponding crash stack data generated by crash events occurring in the Native layer of Android applications, by calling the dump_sys component in BreakPad, when the compiler of the application edits the binary code of the application, a symbol mapping table is generated, and the id of the symbol mapping table is set to the binary program file name (UUID) of the application. Usually, this UUID is generated by applying a hash algorithm such as the MD5 algorithm. The symbol mapping table is associated with its id to form symbol mapping data for storage in the symbol database.

[0045] The symbol processing service, in order to parse the corresponding crash stack data generated by a crash event occurring in an iOS application, after the application is compiled by the compiler of the application, obtains the dSYM file generated correspondingly in the project file of the application, and then, by running the instruction: xcrun dwarfdump --uuid <the full name of the dSYM file>, queries the UUID of the dSYM file, uses the dSYM file as a symbol mapping table, and sets the ID of the symbol mapping table to the UUID. Associates the symbol mapping table with its ID to form symbol mapping data and stores it in the symbol database.

[0046] Step S1200: In response to a crash interpretation event, pull the crash stack data in the to-be-parsed queue, and call the symbol mapping data required to parse the crash stack data in the symbol database to parse out the corresponding readable crash information;

[0047] A crash interpretation service is pre-deployed in the crash platform to monitor the to-be-parsed queue. When there is crash stack data in the queue, it pulls the crash stack data in the queue one by one following the first-in, first-out principle. Then, it queries and obtains the symbol mapping data required to parse the crash stack data in the symbol database, and based on the symbol mapping data, parses the unreadable crash stack content in the crash stack data into readable crash stack content. Finally, it combines the readable crash stack content with the remaining readable crash assistance content in the crash stack data to form readable crash information.

[0048] The crash interpretation service, in order to parse the corresponding crash stack data generated by a crash event occurring in the Java layer of an Android application, where the unreadable crash stack content is the crash stack trace information. According to the crash timestamp and the version number of the application in the crash stack data, it queries the matching ID in the symbol database, obtains the symbol mapping table associated with the ID, and calls the retrace tool to perform de-obfuscation parsing on the crash stack trace based on the symbol mapping table, that is, the mapping file, to obtain the readable original crash stack content. Here, "matching" means that the release timestamp in the ID is equal to or after the crash timestamp, and the version number in the ID is equal to the version number of the application in the crash stack data.

[0049] The crash interpretation service generates corresponding crash stack data to analyze the crash events that occur in the Native layer of Android applications. The unreadable crash stack content is the Minidump file. Call the processor component in Breakpad to read this Minidump file. First, query the symbol database for the matching id based on the UUID in the Minidump file, and obtain the symbol mapping table associated with this id. Then, call the Stackwalker component to symbolize the Minidump file based on this symbol mapping table to obtain readable crash stack content. Here, "matching" means that the UUID in the Minidump file is equal to the UUID in the id.

[0050] The crash interpretation service generates corresponding crash stack data to analyze the crash events that occur in iOS applications. The unreadable crash stack content is the crash stack log. Query the symbol database for the matching id based on the UUID in this crash stack log, and obtain the symbol mapping table associated with this id, which is the dSYM file. Then, call the symbolicatecrash tool to symbolize this crash stack log based on the dSYM file to obtain readable crash stack content. Here, "matching" means that the UUID in the crash stack log is equal to the UUID in the id.

[0051] Step S1300: Classify the readable crash information, label the repair priority of each category according to the total number of information in each obtained category, and store each readable crash information associated with its category and the repair priority of this category in the crash information library for visual display on the crash platform.

[0052] In a further embodiment, the step of classifying the readable crash information and labeling the repair priority of each category according to the total number of information in each obtained category includes the following steps:

[0053] Step S1310: Perform abstract representation processing on the specific address elements in each of the readable crash information to determine the text similarity between the processed readable crash information.

[0054] Abstract representation processing means replacing the specific address elements in the readable crash information with the same character representation, so as to eliminate the ambiguity of the specific address detail text and replace this part of the content with a character with unified semantics. This character can be set by those skilled in the art as needed, for example, [num].

[0055] For ease of understanding, a demonstrative example is as follows:

[0056] Readable crash information: java.lang.OutOfMemoryError: pthread_create(1024KB stack) failed: Try again;

[0057] at com.***.base.taskexecutor.threadpool.NameThread.start(Unknown Source:12). Among them, the specific address elements are 1024 and 12. After replacing them with [num], it is as follows:

[0058] Processed readable crash information: java.lang.OutOfMemoryError: pthread_create([num]KB stack) failed: Try again;

[0059] at com.***.base.taskexecutor.threadpool.NameThread.start(Unknown Source:[num]).

[0060] In one embodiment, a pre-trained deep learning model applicable to the NLP field can be adopted. It has been pre-trained to a convergent state and has learned to represent the semantics of the input text with high-dimensional dense vectors, so that the closer the semantics of the texts, the closer the distances of the corresponding high-dimensional dense vectors mapped in the semantic space. Those skilled in the art can flexibly select an open-source deep learning model according to the disclosure here, such as the Bert model. Thus, each readable crash information is used as the input text respectively, the deep semantic information of each input text is extracted, and the high-dimensional dense vectors corresponding to each deep semantic information are represented. Then, a vector similarity algorithm such as the cosine similarity algorithm is used to calculate the vector distance between each high-dimensional dense vector as the text similarity corresponding to each input text.

[0061] In another embodiment, the simhash algorithm can be used to encode each readable crash information to determine the corresponding simhash values. Then, for every two simhash values, the result corresponding to the bitwise exclusive OR of these two simhash values can be calculated. Then, the number of 1s in this result is accumulated, and the accumulated number is divided by the total number of values included in this result to obtain the text similarity between the two readable crash information corresponding to these two simhash values.

[0062] Step S1320: Group the readable crash information whose text similarity meets the preset conditions into the same category to determine the corresponding categories;

[0063] Classify readable crash information with text similarity exceeding a preset threshold into the same category. The preset threshold can be set by those skilled in the art as needed, such as 0.95. The specific implementation can be as follows: First, store all readable crash information in an initial dataset. Then, start iteration, create a dataset representing a single category, take out a readable crash information from the initial dataset and add it to the dataset of this category. Furthermore, take out the readable crash information in the initial dataset whose text similarity with this readable crash information exceeds the preset threshold and add it to the dataset of this category. In this way, iterate multiple times until the initial dataset is empty and the iteration ends. Thus, datasets for each category can be obtained, and the readable crash information stored in each dataset belongs to this category.

[0064] Step S1330: Sort all categories according to the total number of information in the category, and mark the corresponding repair priorities according to the rankings of each category.

[0065] After sorting all categories in descending order according to the total number of information in the category, determine the rankings of each category. In one embodiment, the rankings of each category can be directly marked as the repair priorities of this category. In another embodiment, first, store all rankings based on the current sorting in an array. Start iteration, each time take out the top N rankings corresponding to each category from the array and divide them into the same repair priority. The repair priority determined each time is one level lower than the repair priority determined last time. When the total number of rankings in the array is less than N, end the iteration, and divide each category corresponding to the rankings in the current array into a repair priority one level lower than the repair priority determined last time; when the total number of rankings in the array is zero, end the iteration. N can be set by those skilled in the art as needed.

[0066] Step S1400: Respond to the crash report event, analyze the corresponding readable crash information in the crash information library according to the report requirement details corresponding to this event to obtain a crash report, and push it to the crash platform for display.

[0067] In one embodiment, in the crash platform, a task for periodically displaying crash reports can be preset. Each time the task reaches the scheduled time, it automatically triggers and responds to a crash report event once. The scheduled time can be set by those skilled in the art as needed, such as 9:00 am and 6:00 pm every day, or every hour, or every day, etc.

[0068] In another embodiment, in the crash platform, the user of this platform can touch the control for displaying crash reports as needed by himself, or manually trigger and respond to a crash report event through other entrances for displaying crash reports.

[0069] In one embodiment, the report requirement details can count any one or more of the PV Crash rate and / or UV Crash rate of the Java layer of Android, the PV Crash rate and / or UV Crash rate of the Native layer of Android, and the PV Crash rate and / or UV Crash rate of iOS. It can also be the combined PV Crash rate and / or UV Crash rate of the Java layer of Android, the Native layer of Android, and iOS corresponding to the same application. PV: Page View, which refers to the sum of the respective display counts of each page in the cumulative application, regardless of users. If a user opens a page 100 times, PV = 100. UV: Unique View, which refers to the sum of the respective display counts of each page in the cumulative application after de-duplication for the same user. If a user opens a page 100 times, UV = 1.

[0070] The PV Crash rate of the Java layer of Android takes the number of crashes in the Java layer of Android as the numerator. This number refers to the total number of readable crash messages stored in the crash information library due to the crash of this Java layer within the time interval from the last response to the crash report event. And, taking the PV within this period as the denominator, the ratio obtained by dividing the numerator by the denominator.

[0071] The UV Crash rate of the Java layer of Android takes the number of crashes in the Java layer of Android as the numerator. This number refers to the total number of readable crash messages stored in the crash information library due to the crash of this Java layer within the time interval from the last response to the crash report event. And, taking the UV within this period as the denominator, the ratio obtained by dividing the numerator by the denominator. Those skilled in the art can flexibly obtain the above-mentioned PV Crash rates and UV Crash rates according to the above disclosure.

[0072] Furthermore, on this basis, the determined PV Crash rates and / or UV Crash rates can be compared with corresponding preset thresholds, and corresponding textual explanations can be made for the comparison results. For example, if the PV Crash rate of the Java layer of Android is less than 2%, the explanation is: The operation and maintenance status of the application is qualified; if the PV Crash rate is less than 1%, the explanation is: The operation and maintenance status of the application is excellent. Then, the PV Crash rates and / or UV Crash rates, their corresponding comparison results, and textual explanations are compiled into a report format to obtain a crash report. The report format can be set by those skilled in the art as needed.

[0073] It is not difficult to understand from the above embodiments that compared with the prior art, the present application has many advantages, including at least:

[0074] This application automatically responds to crash events during program maintenance when the monitoring program crashes, captures crash stack data and pushes it to the queue to be parsed, and captures symbol mapping data and stores it in the symbol database. When the cause of the crash needs to be interpreted, the crash stack data is pulled from the queue to be parsed, and the symbol mapping data in the symbol database is called for parsing to obtain readable crash information. Then, these readable crash information are classified, the number of information in each category is counted, and the repair priority is marked according to the number. Finally, this information is stored in the crash information library, and according to the requirements of the crash report event, a crash report is generated and pushed to the crash platform for display for reference and processing by maintenance personnel. It can be seen that by storing the crash stack data and the symbol mapping data separately (queue to be parsed and symbol database), and realizing asynchronous parsing and dynamic resource scheduling, the traditional serial processing mode is avoided, so that the symbol parsing module can call the mapping data on demand, effectively reducing the probability of I / O blocking and improving the processing throughput of high-concurrency crash events. Moreover, adaptive priority labeling based on the total amount of information is realized, and the volume of various types of crashes is quantitatively analyzed and matched with the corresponding repair priority to ensure that important and urgent crashes are handled first. Moreover, by matching the report requirement details and summarizing the crash report in time and displaying it, users on the platform can clearly understand the overall crash situation and take appropriate program maintenance measures in time.

[0075] In a further embodiment, step S1300, classifying the readable crash information, marking the repair priority of each category according to the total number of information in each category, associating each readable crash information with the category to which it belongs and the repair priority of the category, and storing it in the crash information library for use in visual display in the crash platform, includes the following steps:

[0076] Step S2310: Respond to the crash repair preparation event, extract the crash key information in the readable crash information corresponding to the event, and obtain a repair experience solution matching the crash key information in the repair experience library;

[0077] After a crash occurs, the crash platform can prepare a crash repair plan for its users, helping them better understand the crash and more efficiently repair it. Furthermore, the crash platform can automatically trigger the preparation of a plan for each crash, or it can be triggered on demand by the user, allowing the crash platform to prepare a plan for the crash they selected. This triggers a crash repair preparation event.

[0078] The core of the response process for crash repair preparation events lies in quickly locating historical repair experiences through an intelligent information extraction and matching mechanism. Specifically, first, keyword fields representing the essential features of the crash need to be extracted from the readable crash information to form the critical crash information, including but not limited to: exception type (such as java.lang.NullPointerException), error signal code (such as SIGSEGV), class name and method name associated with the crash code location (such as MainActivity.onCreate), system components involved (such as android.widget.TextView), etc., and any one or more of the shared library file names (libnative-lib.so), etc.

[0079] One implementation of extracting critical crash information uses a prompt template in collaboration with a large language model. Specifically, construct a prompt template containing the task description: "Please extract clear critical information from the following crash content and output it. The critical information can be the exception type and / or the critical class name / method name / error code. Example input: 'java.lang.NullPointerException

[0080] at com.example.MainActivity.onCreate(Unknown Source:42)'; Example output: 'java.lang.NullPointerException,MainActivity.onCreate'. Crash content: [readable crash information to be embedded]". By embedding the actual readable crash information into this template, a structured prompt text is formed and input into the large language model, which parses and outputs standardized critical crash information. This method utilizes the semantic understanding ability of the pre-trained language model and can adapt to readable crash information in different formats.

[0081] Another implementation, a named entity recognition model based on supervised training, whose construction process includes three stages: the training data preparation stage, in which at least multiple labeled training samples need to be collected, and each training sample consists of a readable crash information and a labeled entity, and the entity types include any one or any combination of abnormal types, error codes, critical code positions, etc.; the model architecture selection stage, a sequence labeling model based on BiLSTM-CRF can be adopted; the model training stage, using the cross-entropy loss function for fine-tuning, setting the learning rate, for example: 3e-5, the batch size, for example: 32, and the number of training rounds, for example: 10. In the inference stage, the readable crash information is input into the model trained to the convergence state, and the text segments marked with labels such as B-ERROR and I-ERROR in the output sequence are the critical crash information. Those skilled in the art can flexibly change the entity types of the labeled training samples and the training of the above model according to the disclosure here.

[0082] The repair experience library includes multiple indexes and their repair experience solutions. For the convenience of quick retrieval, each index is vectorized by a pre-trained Bert or other text representation model and represented as corresponding index vectors. Accordingly, after obtaining the critical crash information, retrieval is performed in the repair experience library through a feature vector matching algorithm. In specific implementation, the critical crash information is also vectorized and represented as a vector, and the cosine similarity between this vector and each index vector in the library is calculated, and the repair experience solutions with the obtained cosine similarity exceeding the preset threshold are screened out. The preset threshold can be set by those skilled in the art as needed.

[0083] Step S2320, when obtaining the repair experience solution, visually display the repair experience solution in the crash platform;

[0084] For the visual presentation of the repair experience solution, intuitive communication of technical guidance can be achieved through multi-dimensional interactive components in the crash platform. When the crash platform retrieves a repair experience solution that matches the critical crash information, a hierarchical display strategy will be adopted: First, the readable crash stack information in the repair experience solution is displayed in the code view at the top of the interface. Subsequently, with a graphic display component or a plain text display component, the specific text content or graphic content in the troubleshooting solution, the result analysis information of the troubleshooting solution, and the crash reason are displayed in the interface. Furthermore, the difference between the problem code and the repaired code is presented in the code comparison view. Finally, the repair details text is displayed in text.

[0085] The repair experience solutions can be sorted in descending order of their cosine similarity, and this sorting is used as the display order of these repair experience solutions.

[0086] Step S2330: When the repair experience solution is not obtained, use a large language model to generate a repair suggestion solution based on the critical crash information, and visually display the repair suggestion solution on the crash platform.

[0087] When there is no matching repair experience solution in the repair experience library, the crash platform starts an intelligent diagnosis process based on a large language model. By pre-building a structured prompt template, which includes three core modules: The task instruction module requires the model to analyze the readable crash information as an Android / iOS development expert; the context injection module is prepared to insert the readable crash information as the analysis object; the example guidance module provides standardized diagnostic process examples for Android Java layer crashes, Android Native layer crashes, and iOS crashes respectively. For example, the prompt template for Native layer crashes will include a Breakpad parsing example, and requires the model to output in a multi-stage structure of "troubleshooting plan → troubleshooting result analysis → problem location → root cause analysis → repair steps → verification method". Thus, embed the readable crash information into the structured prompt template, obtain the structured prompt text and input it into the large language model, use the output result of the model as the repair suggestion solution, and intuitively convey technical guidance through multi-dimensional interactive components on the crash platform, which can be flexibly implemented by those skilled in the art.

[0088] In this embodiment, when preparing to repair a crash, the crash platform searches for historical repair experiences in the repair experience library based on the readable crash information shown by the crash. When a matching repair experience solution can be found, it can be used for users to refer to; on the contrary, when historical repair experiences cannot be referred to, a large language model is used to generate repair suggestions for users to reference. It can be seen that it can assist users in efficiently repairing crashes and improve the user experience.

[0089] In a further embodiment, before step S2310: Respond to the crash repair preparation event, extract the critical crash information from the readable crash information corresponding to the event, and obtain the repair experience solution in the repair experience library that matches the critical crash information, the following steps are included:

[0090] Step S2300: Respond to the crash repair completion event, obtain the readable crash information, troubleshooting plan and its result analysis information, crash cause, and program code information before and after repair corresponding to the event, and form a repair process record.

[0091] When the user completes the crash repair on their terminal, they can actively trigger the crash platform to respond to the crash repair completion event. At this time, first, the crash platform obtains the set of the complete repair processes related to the current repair. This set contains the following elements: the readable crash information after symbolization (e.g., the de-obfuscated stack trace), the specific troubleshooting solutions adopted by the user during the troubleshooting phase (e.g., the usage records of memory leak detection tools), the technical analysis of the troubleshooting results (e.g., confirming that the crash is caused by a null pointer exception), the finally determined crash cause (e.g., incorrect handling of asynchronous task callbacks), and the file comparing the code differences before and after the repair (stored in the Git Diff format or other version control difference formats). These information edited by the developer, i.e., the user, in the crash platform are automatically captured through the interface, or these information externally edited by the user are manually submitted to form a complete repair process record. During the process of the user editing these information, the user can retrieve the corresponding information in the repair experience library through keywords, and further edit or directly use the retrieved information on the basis of selecting it as needed. Those skilled in the art can flexibly implement the keyword retrieval here.

[0092] Step S2301: Use a large language model to infer the repair details text based on the program code information and the crash cause corresponding to before and after the repair.

[0093] To generate a standardized repair details text, a large language model that has been pre-finetuned and trained to a convergent state can be called to process the code changes before and after the repair and the crash cause, and infer the repair details text. This model uses a deep learning model based on the Transformer architecture. During its training process, it learns the knowledge of fixing crashes from the defect repair records in the open-source code library and the troubleshooting cases in the technical documents, and expresses in natural language how to make repairs at the code level.

[0094] The input data of the large language model includes the problem code snippet before the repair, the correct code snippet after the repair, and the crash cause described in natural language. The model can analyze the code differences before and after the repair due to the crash cause and output a structured repair details text. For example, when the repair involves a null pointer exception, the model may generate text containing the following elements: the crash cause (calling an object method directly without null check), the repair method (adding a null value check conditional branch), and the code modification operation path (showing the line number and the code change). This text contains both technical detail descriptions and natural language readability. Those skilled in the art can flexibly implement the fine-tuning training of the large language model according to the above disclosure.

[0095] Step S2302: Use the crash key information in the readable crash information as an index, form a repair experience solution by combining the repair process record and the repair details text, and store the repair experience solution associated with the index in the repair experience library.

[0096] Extract keyword fields with technical features from the readable crash information as indexes, including but not limited to: exception type (such as java.lang.NullPointerException), error signal code (such as SIGSEGV), class name and method name associated with the crash code location (such as MainActivity.onCreate), system components involved (such as android.widget.TextView), etc., shared library file name (libnative-lib.so), etc. Any one or more of them are combined to form the critical crash information as an index. Concatenate the recorded repair process with the repair details text to obtain the repair experience solution. After mapping and associating this solution with the index, store it in the repair experience library.

[0097] In this embodiment, when the crash repair is completed, obtain the information recording the entire repair process, then construct the corresponding index, and organize the repair experience solution associated with its mapping, and store it in the repair experience library. It can be seen that historical repair experience can be stored to be reused for future crash repairs, significantly reducing the time consumed by users to review or search for technical documents for repairing crashes by themselves, and significantly improving the repair efficiency.

[0098] In a further embodiment, after step S2310, visualizing the repair experience solution on the crash platform, the following steps are included:

[0099] Step S2311: Respond to the experience adoption event, and obtain the program code information before repair corresponding to this event, and the repair details text in the repair experience solution;

[0100] When the user selects the provided repair experience solution, it triggers the crash platform to respond to the experience adoption event. The program code information before repair corresponding to the crash to be repaired is obtained by the user actively uploading it, or by parsing the code snippet corresponding to the crash to be repaired from the project code of the application based on the readable crash information through a pre-configured interface as the program code information before repair. In addition, the platform can also extract the repair details text in this repair experience solution for subsequent use.

[0101] Step S2312: Use a large language model to infer the program code information after repair based on the repair details text and the program code information, and push it to be displayed on the crash platform.

[0102] Format and splice the program code information before repair, the repair details text, and the natural language instructions to form the prompt text input to the large language model. The natural language instructions are usually task descriptions, requirements, and / or guides for the model to repair the program code information based on the repair details text and output the repaired code information. The specific text content described can be flexibly set by those skilled in the art. In specific implementation, a multimodal input structure can be adopted: embed the code before repair in the prompt text in the form of a code block, and add natural language instructions above it, such as "Please modify the code according to the following repair suggestions: {repair details text}".

[0103] The large language model needs to be specially fine-tuned and trained for the code repair task. Its training data includes defect repair commit records in public code repositories, manually annotated code patch samples, etc. The architecture of the model is preferably a sequence-to-sequence model based on Transformer, such as CodeT5, etc. These models have the ability to understand the collaborative operation of code semantics and natural language instructions. In the inference stage, the model can analyze the relevance between the code context and the repair instructions through the self-attention mechanism and generate the repaired program code token by token. For example, for the code "textView.setText(content);" before repair, the model combines the repair details of "add null value check" and can output the repaired code containing a conditional judgment statement "if(textView!= null){textView.setText(content);}". The generated repaired code will be standardized by a code formatting tool (such as the code formatting function of Android Studio) to ensure compliance with the syntax specifications and coding styles of the target programming language. Those skilled in the art can flexibly implement the fine-tuning training of the large language model according to the above disclosure.

[0104] Furthermore, the crash platform visualizes the code differences before and after repair in the form of highlighted annotations through the application code comparison view component, such as using a green background to identify newly added code lines, a red background to identify deleted code lines, etc. Users can perform manual review on this basis or directly synchronize the repaired code to the code repository through the integrated development environment interface.

[0105] In this embodiment, when the user adopts the experience of historical crash repair, the repair details text in the experience-based solution is used to perform corresponding repair editing on the program code information before repair, and the repaired program code information is given to the user for review. It can be seen that by combining historical repair experience with code automation editing, the efficiency of crash repair can be significantly improved.

[0106] In a further embodiment, after step S1400, in response to a crash report event, analyzing the corresponding readable crash information in the crash information library according to the detailed rules of the report requirements corresponding to the event to obtain a crash report, and pushing it to the crash platform for display, the following steps are included:

[0107] Step S1500, in response to a crash monitoring event, obtaining the proportion of crashing users and the crash rate in the crash report;

[0108] The crash platform can be responsible for real-time collecting and analyzing the readable crash information in the crash information library through a pre-configured monitoring service. Specifically, the monitoring service will count two core indicators based on a preset time window (for example: the past 24 hours or the most recent 10,000 application launches, which can also be flexibly set by those skilled in the art): the proportion of crashing users and the crash rate. Among them, the proportion of crashing users refers to the ratio of the total number of independent program users who have crashed to the total number of active program users within the time window, and active program users refer to program users who have completed at least one effective interaction with the application; the crash rate refers to the ratio of the number of application crashes to the total number of application launches within the time window.

[0109] The total number of independent program users who have crashed within the time window can be obtained by determining the total number of readable crash information stored in the crash information library within the time window and including different device IDs. The number of application crashes refers to the total number of readable crash information stored in the crash information library within the time window.

[0110] Step S1510, when the proportion of crashing users meets the first preset condition or the crash rate meets the second preset condition, generating an alarm message according to the proportion of crashing users or the crash rate, and sending it to the target user of the crash platform.

[0111] Multiple different first preset thresholds can be preset for the proportion of crashing users, such as 10%, 20%, 50%, which can be flexibly set by those skilled in the art. In addition, an alarm information template corresponding to each first preset threshold is set. When the proportion of crashing users exceeds any one of the first preset thresholds, it is considered to meet the first preset condition, and the proportion of crashing users is embedded into the alarm information template corresponding to the first preset threshold to obtain the alarm information. The alarm information template describes the corresponding crash impact range and the urgency of crash handling under the situation where the proportion of crashing users exceeds the corresponding first preset threshold. Those skilled in the art can pre-edit the template as needed according to the disclosure here.

[0112] Multiple different second preset thresholds can be preset for the crash rate, such as 30%, 50%, 80%, which can be flexibly set by those skilled in the art. In addition, an alarm information template corresponding to each second preset threshold is set. When the crash rate exceeds any one of the second preset thresholds, it is considered to meet the second preset condition, and the crash rate is embedded into the alarm information template corresponding to the second preset threshold to obtain the alarm information. The alarm information template describes the corresponding crash impact range and the urgency of crash handling under the situation where the crash rate exceeds the corresponding second preset threshold. Those skilled in the art can pre-edit the template as needed according to the disclosure here.

[0113] The alarm information is pushed to a preset information sending interface, which parses and separates the user information from the alarm information, and sends the separated alarm information to the user corresponding to the user information, that is, the target user. The user information is used to uniquely identify the user, and can be the user's mobile phone number or email address, etc. Those skilled in the art can flexibly build the interface in advance.

[0114] In this embodiment, by monitoring the proportion of crash users corresponding to the crash and the crash rate, when the corresponding preset conditions are respectively met, the corresponding target user is alarmed. It can be seen that relevant users can be notified to handle it in time when the corresponding situation occurs.

[0115] In a further embodiment, after step S2302, storing the associated index of the repair experience solution in the repair experience library, the following steps are included:

[0116] Step S2303, when the solution capacity of the repair experience library each time meets the preset condition, obtain the repair detail text in each repair experience solution corresponding to the increment compared with the previous time;

[0117] Multiple increasing preset thresholds can be preset for the solution capacity. Specifically, when implementing, an initial preset threshold can be set first, and then, each time it increases, the previous preset threshold is multiplied by an increasing coefficient to obtain the corresponding preset threshold. The increasing coefficient is a percentage value greater than 100%. The specific values corresponding to the initial preset threshold and the increasing coefficient can be set by those skilled in the art as needed.

[0118] The total number of solutions in the repair experience library can be counted in real time through a counter, and the specific value read from the counter is the solution capacity of the library. When the solution capacity each time exceeds any preset threshold, it is considered to meet the preset condition, and the crash platform is triggered to obtain the repair detail text in each repair experience solution newly added and stored in the repair experience library compared with the previous time.

[0119] Step S2304: Use a large language model to infer a crash avoidance solution based on each of the repair detail texts, and push it to the crash platform for display.

[0120] Each repair detail text is embedded in a preset prompt template, the prompt text is obtained and input into the large language model, and the crash avoidance solution inferred by the model is pushed to the crash platform for display so that users on the platform can review or further edit it. The prompt template includes a task description and the repair detail text to be embedded. The task description is used to require and / or guide the model to summarize how to write code to avoid program crashes based on the given multiple repair detail texts. The specific implementation can be flexibly adapted by those skilled in the art based on the disclosure herein. For example: Please act as a senior professional programmer, and based on the following multiple repair detail texts, you are required to summarize the matters that need to be paid attention to when writing code to avoid causing program crashes. Specifically, you need to extract general code writing specifications and preventive measures for potential problems from these repair details to form a crash avoidance solution output.

[0121] In this embodiment, by accumulating a certain amount of repair experience each time, the large language model is used to automatically infer the corresponding crash avoidance plan and display it. It can be seen that it can play a certain warning role for users and help users better avoid program crashes.

[0122] See also Figure 2 , a program maintenance device provided to meet one of the purposes of the present application is a functional embodiment of the program maintenance method of the present application, the device includes a program crash module 1100, a crash interpretation module 1200, a crash annotation module 1300 and a report display module 1400, wherein the program crash module 1100 is used to respond to a program crash event, capture the crash stack data corresponding to the event and push it to a queue to be parsed, and capture the symbol mapping data corresponding to the event and store it in a symbol database; the crash interpretation module 1200 is used to respond to a crash interpretation event, pull the crash stack data in the queue to be parsed, and call the symbol data The crash information library contains the symbol mapping data required to parse the crash stack data, and parses the corresponding readable crash information; the crash annotation module 1300 is used to classify the readable crash information, mark the repair priority of the category according to the total number of information in each category, and associate each readable crash information with the category to which it belongs and the repair priority of the category to be stored in the crash information library for visual display in the crash platform; the report display module 1400 is used to respond to the crash report event, analyze the corresponding readable crash information in the crash information library according to the report requirement details corresponding to the event, and obtain the crash report, and push it to the crash platform for display.

[0123] In a further embodiment, the crash annotation module 1300 includes: a text similarity sub-module for abstractly representing the specific address elements in each of the readable crash information to determine the text similarity between the processed readable crash information; a category determination sub-module for classifying the readable crash information with text similarity meeting a preset condition into the same category to determine the corresponding categories; and a priority annotation sub-module for sorting all categories according to the total number of information in each category and annotating the corresponding repair priorities according to the rankings of each category.

[0124] In a further embodiment, after the crash annotation module 1300, there is included: a first event response sub-module for responding to a crash repair preparation event, extracting the crash key information in the readable crash information corresponding to the event, and obtaining a repair experience solution matching the crash key information in the repair experience library; a solution display sub-module for visually displaying the repair experience solution in the crash platform when the repair experience solution is obtained; and a solution generation sub-module for using a large language model to generate a repair suggestion solution according to the crash key information and visually displaying the repair suggestion solution in the crash platform when the repair experience solution is not obtained.

[0125] In a further embodiment, before the first event response sub-module, there is included: a second event response sub-module for responding to a crash repair completion event, obtaining the readable crash information, the troubleshooting solution and its result analysis information, the crash cause, and the program code information before and after repair corresponding to the event to form a repair process record; a first text inference sub-module for using a large language model to infer a repair details text according to the program code information before and after repair and the crash cause; and a solution construction sub-module for using the crash key information in the readable crash information as an index, combining the repair process record and the repair details text into a repair experience solution, and associating and storing the repair experience solution with the index in the repair experience library.

[0126] In a further embodiment, after the solution display sub-module, there is included: an event response unit for responding to an experience adoption event, obtaining the program code information before repair corresponding to the event, and the repair details text in the repair experience solution; and a repair display unit for using a large language model to infer the program code information after repair according to the repair details text and the program code information and pushing it to the crash platform for display.

[0127] In a further embodiment, after the solution formation sub-module, the following are included: a third event response sub-module, configured to respond to a crash monitoring event and obtain the proportion of crashed users and the crash rate in the crash report; a user alert sub-module, configured to generate an alert message based on the proportion of crashed users or the crash rate and send it to the target users of the crash platform when the proportion of crashed users meets a first preset condition or the crash rate meets a second preset condition.

[0128] In a further embodiment, after the solution storage sub-module, the following are included: when the solution capacity of the repair experience library meets a preset condition each time, obtain the repair detail texts in each repair experience solution corresponding to the incremental amount compared to the previous time; use a large language model to infer a crash avoidance solution based on each of the repair detail texts and push it to be displayed on the crash platform.

[0129] To solve the above technical problems, an embodiment of the present application also provides a computer device. As Figure 3 shown, it is a schematic internal structure diagram of the computer device. The computer device includes a processor, a computer-readable storage medium, a memory, and a network interface connected through a system bus. Among them, the computer-readable storage medium of the computer device stores an operating system, a database, and computer-readable instructions. The database can store a control information sequence. When the computer-readable instructions are executed by the processor, the processor can implement a program maintenance method. The processor of the computer device is used to provide computing and control capabilities to support the operation of the entire computer device. The memory of the computer device can store computer-readable instructions. When the computer-readable instructions are executed by the processor, the processor can execute the program maintenance method of the present application. The network interface of the computer device is used to connect and communicate with a terminal. Those skilled in the art can understand that Figure 3 the structure shown in

[0130] is only a block diagram of a part of the structure related to the solution of the present application and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than those shown in the figure, or combine certain components, or have different component arrangements.

[0130] In this embodiment, the processor is used to execute Figure 2 the specific functions of each module and its sub-modules in

[0131] The present application also provides a storage medium storing computer-readable instructions, which when executed by one or more processors, cause the one or more processors to execute the steps of the program maintenance method according to any embodiment of the present application.

[0132] Those of ordinary skill in the art can understand that all or part of the processes of implementing the methods in the above embodiments of the present application can be completed by instructing relevant hardware through a computer program. The computer program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes of the embodiments of the above methods. Among them, the aforementioned storage medium can be a computer-readable storage medium such as a magnetic disk, an optical disk, a read-only memory (ROM), or a random access memory (RAM), etc.

[0133] In summary, the present application can systematically assist users in timely maintaining crashed programs.

[0134] Those skilled in the art of the present technology can understand that the steps, measures, and solutions in the various operations, methods, and processes discussed in the present application can be alternated, changed, combined, or deleted. Further, the other steps, measures, and solutions in the various operations, methods, and processes discussed in the present application can also be alternated, changed, rearranged, decomposed, combined, or deleted. Further, the steps, measures, and solutions in the prior art that are the same as those disclosed in the various operations, methods, and processes in the present application can also be alternated, changed, rearranged, decomposed, combined, or deleted.

[0135] The above are only some embodiments of the present application. It should be noted that for those of ordinary skill in the art of the present technology, without departing from the principle of the present application, several improvements and refinements can be made, and these improvements and refinements should also be regarded as the protection scope of the present application.

Claims

1. A program maintenance method, characterized in that, The steps include: Respond to a program crash event, capture the crash stack data corresponding to the event and push it to the queue to be parsed, and capture the symbol mapping data corresponding to the event and store it in the symbol database; In response to a crash interpretation event, the crash stack data in the to-be-parsed queue is pulled, and the symbol mapping data required to parse the crash stack data in the symbol database is called to parse the corresponding readable crash information; Classifying the readable crash information, marking the repair priority of each category according to the total number of information in each category, and associating each readable crash information with the category to which it belongs and the repair priority of the category in the crash information library for visualization in the crash platform; In response to a crash report event, according to the corresponding reporting requirements of the event, the corresponding readable crash information in the crash information library is analyzed to obtain a crash report, and the crash report is pushed to the crash platform for display.

2. The program maintenance method according to claim 1, characterized in that The readable crash information is classified and the repair priority of each category is marked according to the total number of information in each category, including the following steps: performing abstract representation processing on specific address elements in each of the readable crash information, and determining text similarity between the processed readable crash information; Classify the readable crash information whose text similarity meets the preset conditions into the same category, and determine the corresponding categories; All categories are sorted according to the total number of information in the categories, and the corresponding repair priority is marked according to the ranking of each category.

3. The program maintenance method according to claim 1, characterized in that, The readable crash information is classified, the repair priority of each category is marked according to the total number of information in each category, and each readable crash information is associated with its category and the repair priority of the category and stored in the crash information library for use in visual display in the crash platform, including the following steps: In response to a crash repair preparation event, extract the key crash information from the readable crash information corresponding to the event, and obtain a repair experience solution that matches the key crash information from a repair experience library; When the repair experience solution is obtained, the repair experience solution is visually displayed on the crash platform; When the repair experience solution is not obtained, a large language model is used to generate a repair suggestion solution based on the crash key information, and the repair suggestion solution is visually displayed in the crash platform.

4. The program maintenance method according to claim 3, characterized in that, Responding to a crash repair preparation event, extracting the key crash information from the readable crash information corresponding to the event, and obtaining a repair experience solution matching the key crash information from a repair experience library, includes the following steps: In response to the crash repair completion event, obtain the corresponding readable crash information, troubleshooting plan and result analysis information, crash cause, and corresponding program code information before and after the repair, forming a repair process record; Using a large language model to infer repair details based on the program code information and crash cause corresponding to the repair sequence; The crash key information in the readable crash information is used as an index, the repair process record and the repair detail text are combined into a repair experience plan, and the repair experience plan is associated with the index and stored in a repair experience library.

5. The program maintenance method according to claim 3, characterized in that, After visualizing the repair experience in the crash platform, the following steps are included: Respond to the experience adoption event, obtain the program code information before the repair corresponding to the event, and the repair details text in the repair experience plan; A large language model is used to infer the repaired program code information based on the repair detail text and program code information, and the repaired program code information is pushed to the crash platform for display.

6. The program maintenance method according to claim 1, characterized in that, Responding to a crash report event, analyzing the corresponding readable crash information in the crash information library according to the reporting requirements corresponding to the event, generating a crash report, and pushing it to the crash platform for display, includes the following steps: Respond to crash monitoring events and obtain the crash user percentage and crash rate in the crash report; When the crash user ratio meets the first preset condition or the crash rate meets the second preset condition, an alarm message is generated according to the crash user ratio or the crash rate and sent to target users of the crash platform.

7. The program maintenance method according to claim 4, wherein After the restoration experience solution is associated with the index and stored in the restoration experience database, the following steps are included: When the solution capacity of the repair experience library meets the preset conditions each time, the repair details text in each repair experience solution corresponding to the previous increment is obtained; A large language model is used to infer crash avoidance solutions based on the repair details text, and the solutions are pushed to the crash platform for display.

8. A program maintenance device, characterized in that, include: The program crash module is used to respond to program crash events, capture the crash stack data corresponding to the event and push it to the queue to be parsed, and capture the symbol mapping data corresponding to the event and store it in the symbol database; A crash interpretation module, configured to respond to a crash interpretation event, pull the crash stack data in the to-be-parsed queue, and call the symbol mapping data required to parse the crash stack data in the symbol database to parse the corresponding readable crash information; A crash annotation module is used to classify the readable crash information, annotate the repair priority of each category based on the total number of information in each category, and associate each readable crash information with its category and the repair priority of the category and store it in a crash information library for visual display in the crash platform; The report display module is used to respond to crash report events, analyze the corresponding readable crash information in the crash information library according to the report requirement details corresponding to the event, and obtain the crash report, which is pushed to the crash platform for display.

9. A computer device, comprising a central processing unit and a memory, characterized in that, The central processing unit is configured to call and run a computer program stored in the memory to execute the steps of the method according to any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, It stores a computer program implemented according to the method described in any one of claims 1 to 7 in the form of computer-readable instructions, and when the computer program is called and executed by a computer, the steps included in the corresponding method are executed.

Images