Software crash error repair scheme recommendation method based on position and knowledge similarity

Abstract

The invention discloses a position and knowledge similarity-based software crash error repair scheme recommendation method, which outputs a repair method for error codes according to generated crash stack tracking information and corresponding codes when software crashes, and can help developers to quickly and efficiently solve the problem of software crash. When the method works, firstly, a context knowledge base is constructed, problem posts containing crash stacks on Stack Overflow are preprocessed, a knowledge base and an abnormal dictionary are constructed, and a language model is trained; thirdly, a related question set is preliminarily obtained through stack tracking, the comprehensive similarity of the question and an input stack is calculated through the position related similarity and the additional knowledge similarity, and the most related question and answer set is returned; and finally, performing relevancy calculation on the answer paragraphs based on multiple features, selecting paragraphs related to the crash reason by applying an MMR algorithm, and outputting root cause analysis and repair code snippets related to the crash error.

Description

Technical Field

[0001] The present invention relates to the field of automatic recommendation of solutions to software crash problems, and in particular to a method for recommending software crash error repair solutions based on location and knowledge similarity. Background Art

[0002] Software crashes are a serious software defect problem that developers often prioritize. However, as the complexity of software systems increases, the causes of software crashes become increasingly complex. Fortunately, many vulnerabilities are recurring, occurring across different projects but sharing similarities. Previous research reports (e.g., S. Kim, K. Pan, and E. J. Whitehead Jr., “Memories of bug fixes,” in Proceedings of the 14th ACM SIGSOFT international symposium on Foundations of software engineering, 2006, pp. 35–45. and TTNguyen, HANguyen, NHPham, J. Al-Kofahi, and TNNguyen, “Recurring bug fixes in object-oriented programs,” in Proceedings of the 32nd ACM / IEEE International Conference on Software Engineering - Volume 1, 2010, pp. 315–324.) have reported that approximately 17–45% of vulnerabilities can be considered recurring. Therefore, reproducible bugs that have been discussed on Q&A sites (such as StackOverflow) have the potential to help developers solve their own software crashes. Typically, developers will organize their questions about crashes into queries and enter them into search engines. However, for large crash traces thrown by programs, developers often have difficulty summarizing them into a single query. Search engines like Google and Stack Overflow cannot process the entire crash trace due to input length limitations. Generally, developers will try to directly use the crash cause (such as Figure 1 As shown in the example, developers use a search engine as input and then read the returned posts to find solutions to software crashes. However, this approach misses a lot of important information in the stack frame, and the results may be inaccurate. Even worse, the returned posts contain a lot of noisy and redundant information, requiring developers to spend a lot of time sifting through them to find the correct solution.

[0003] Recently, two approaches for automatically generating solutions to programming problems have been proposed: AnswerBot and CROKAGE:

[0004] AnswerBot is a three-stage framework for generating answer summaries for non-factual technical questions. While the generated answers are relevant, useful, and diverse, it requires natural language descriptions of programming questions as input. Developers struggle to accurately describe complex crash problems in natural language, so it is not very effective when dealing with crash traces. For more information, see B.Xu, Z.Xing, X.Xia, and D.Lo, “Answerbot: Automated generation of answer summaries to developers’ technical questions,” in 2017 32nd IEEE / ACM International Conference on Automated Software Engineering (ASE). IEEE, 2017, pp. 706–716.

[0005] CROKAGE is a tool that provides comprehensive solutions based on natural language descriptions of programming tasks. However, due to its reliance on natural language input, developers struggle to provide appropriate input when faced with crash traces, and a large amount of information in the crash trace is lost, making it ineffective in resolving crash issues. For more information, see Reference 2 (R. Silva, C. Roy, M. Rahman, K. Schneider, K. Paixao, and M. Maia, “Recommending comprehensive solutions for programming tasks by mining crowd knowledge,” in 2019 IEEE / ACM 27th International Conference on Program Comprehension (ICPC). IEEE, 2019, pp. 358–368.)

[0006] Although previous research has explored the use of crash tracking for error location, automatic program repair, and duplicate error report detection, there is still a gap in the key area of automatically recommending software crash error repair solutions. These problems seriously hinder developers from efficiently resolving software crash problems. Summary of the Invention

[0007] The present invention proposes a method for recommending software crash error repair solutions based on location and knowledge similarity, aiming to provide developers with solutions to crash problems, which can effectively improve development efficiency and software quality.

[0008] This invention addresses the difficulty for developers to efficiently obtain solutions to software crash problems. It proposes a method for recommending software crash error repair solutions based on location and knowledge similarity, including the following steps:

[0009] S1: Obtain crash stack index, exception dictionary and trained FastText model through context knowledge base construction;

[0010] The S2 context information parsing phase specifically includes:

[0011] S2.1: When a Java software crash occurs and a crash stack is given, the crash cause and stack frame are first extracted. If the crash cause matches the exception name in the exception dictionary, the corresponding description is added as additional knowledge;

[0012] S2.2: Using the crash stack index and the BM25 algorithm to measure vocabulary similarity, we initially retrieve the top 10-100 similar issues and filter out those without shared exception names.

[0013] S2.3: Calculate the position-related similarity given the crash stack;

[0014] Calculate the additional knowledge similarity between the additional knowledge in the JAVA official document and the trained FastText model;

[0015] S2.4: Normalize the position-related similarity and the additional knowledge similarity, calculate the final relevance, and return the top 3 to 10 context information based on the final relevance;

[0016] The S3 crash repair solution output phase specifically includes:

[0017] S3.1: First, using the paragraphs in the context information obtained in step S2.4 as the granularity, the comprehensive relevance of the answer paragraphs in the first 3 to 10 context information is calculated based on the four features of final relevance, semantic similarity with the crash stack description, number of answer votes, and whether the answer is accepted to obtain the comprehensive relevance. Then, based on the comprehensive relevance, the maximum marginal relevance algorithm is used to select 1 to 10 relevant paragraphs. The most relevant root cause statements are selected from the 1 to 10 relevant paragraphs through grammatical dependency analysis. At the same time, the code snippets in the 1 to 10 relevant paragraphs are output as repair patches. Finally, a complete repair solution is output.

[0018] In step S1, the crash stack index, exception dictionary, and trained FastText model are obtained through the context knowledge base construction, including:

[0019] S1.1: Extract question posts containing crash stack traces from the Stack Overflow website data as a corpus;

[0020] S1.2: Segment the crash stacks collected in the corpus and construct a crash stack index;

[0021] S1.3: Crawl exception information from the official JAVA documentation and build an exception dictionary;

[0022] S1.4: Collect Stack Overflow post text from the Stack Overflow website data, train the FastText model after processing and calculate the inverse document frequency to obtain the trained FastText model.

[0023] The present invention outputs a repair method for the error code based on the crash stack trace information and corresponding code generated when the software crashes, which can help developers solve software crash problems quickly and efficiently. When the present invention works, it first builds a context knowledge base, pre-processes the question posts containing crash stacks on Stack Overflow, builds a knowledge base, an exception dictionary and trains a language model. Then, the present invention uses stack traces to preliminarily obtain a set of related questions, and proposes to calculate the comprehensive similarity between the question and the input stack through position-related similarity and additional knowledge similarity, and returns the most relevant questions and answer sets. Finally, the relevance of the answer paragraphs is calculated based on multiple features, and the MMR algorithm is used to select paragraphs related to the cause of the crash, and output the root cause analysis and repair code snippets about the crash error. After experiments, the present invention is significantly better than other baseline methods in performance, and can help developers more effectively analyze the causes of software crashes and solve software crash problems.

[0024] In step S2.3, the location-related similarity is calculated using the given crash stack, specifically including:

[0025] For a given crash stack, extract all its call stacks and corresponding stack frames, denote the position of the call stack in the entire crash stack as s, and denote the distance from each function marker to the top of the call stack to which it belongs as d. Then, for each function marker ω in the crash stack i Location information Recorded as a collection:

[0026]

[0027] Where k is ω iThe total number of times this function appears in the crash trace; i represents the position index where this function marker appears; Label the function ω i The location information set, s i,1 Mark the position of the first call stack of this function in the entire crash stack, s i,k Mark the location of the kth occurrence of the call stack for this function in the entire crash stack, d i,1 Label the function ω i The distance from the top of the call stack to which the first stack frame belongs, d i,k Represents the function notation ω i The distance between the kth occurrence of the stack frame and the top of the call stack to which it belongs;

[0028] Let W be the set of all matching function tokens between a given crash stack CT1 and a crash stack CT2 in the related problem set, and each function token ω i Position-dependent weight The calculation is as follows:

[0029]

[0030] Among them, ω i is the function mark in W, dis is The average value of d in dis1 is the value corresponding to CT1. min(dis1, dis2) means taking the smaller value of the average value of d in CT1 and CT2;

[0031] The position-related similarity between CT1 and CT2 is calculated according to the BM25 algorithm as follows:

[0032]

[0033] Among them, score i is ω calculated using the bm25 algorithm i The vocabulary similarity with the crash stack CT2 in the related problem set, n is the number of words, Calculated by formula (2), PDSim(CT1, CT2) is the position-related similarity.

[0034] In step S2.3, the additional knowledge similarity is calculated using the additional knowledge in the JAVA official document and the trained FastText model, specifically including:

[0035] The corresponding description in the JAVA official document of the crash stack and the title of the related question are converted into two word bags, denoted as D and T respectively, and the additional knowledge similarity is calculated using the inverse document frequency weighted word embedding vector. The calculation formula is:

[0036]

[0037] Among them, t i is a word in the document, FastText(t i ) is the function token t represented by the trained FastText model i The corresponding embedding vector, IDF(t i ) is the inverse document frequency of the word, n represents the number of corresponding document words, and EKSim(D,T) is the additional knowledge similarity.

[0038] In step S2.4, the position-related similarity and the additional knowledge similarity are normalized to calculate the final relevance, which specifically includes:

[0039] The final similarity between a given crash stack trace CT and each question Q in the related question set is calculated as follows:

[0040] Rel(Q,CT)=(1-μ)PDSim+μEKSim (6)

[0041] Among them, μ is a hyperparameter, PDSim is the position-dependent similarity, EKSim is the additional knowledge similarity, and Rel(Q,CT) is the final similarity.

[0042] In step S3.1, the semantic similarity with the crash stack description is calculated as follows: First, the trained FastText model converts the paragraph and crash stack description into vectors, and then performs a weighted average using the inverse document frequency to obtain the two processed vectors. Then, the vector inner product is calculated between the two vectors to obtain the semantic similarity.

[0043] Furthermore, a method for recommending software crash error repair solutions based on location and knowledge similarity includes the following steps:

[0044] S1 Contextual Knowledge Base Construction: Based on specific HTML tags and strings, we extract question posts containing crash stack traces from the Stack Overflow website data. We then segment the collected crash stack traces and construct a crash stack index. We crawl exception information from official documentation and build an exception dictionary. We collect and process the text of Stack Overflow posts, train a FastText model, and calculate IDF (Inverse Document Frequency) to measure semantic similarity and support subsequent stages.

[0045] S2 context information parsing stage: Given a crash stack, first extract the crash cause and stack frame. If the crash cause matches the exception name in the exception dictionary, add the corresponding description as additional knowledge. Using the crash stack index, measure the vocabulary similarity with BM25, preliminarily retrieve the top 50 similar questions and filter out questions without shared exception names. Next, measure the structural similarity between the given stack and the question stack through position-related similarity, taking into account the tag location information; use additional knowledge similarity to measure the semantic similarity between the official document description of the crash cause and the question title. Finally, normalize the two similarity scores, calculate the final relevance, and return the top 10 context-related information;

[0046] S3 Crash Repair Solution Output Stage: In the crash repair solution output stage, the present invention first uses the answer paragraph in the context as the granularity and calculates the comprehensive relevance of the answer paragraphs of the top 10 relevant questions based on four characteristics: question similarity, semantic similarity with the crash stack description, number of answer votes, and whether the answer is accepted. Then, using the Maximum Margin Relevance (MMR) algorithm, three relevant paragraphs are selected based on a comprehensive consideration of relevance and diversity. The most relevant root cause statements are selected through grammatical dependency analysis, while the code snippets in the natural language paragraphs are retained and output as repair patches. Finally, a complete repair solution is output.

[0047] The S1 context knowledge base construction phase includes the following steps:

[0048] S1.1 Extract issues containing crash stacks: Most crash stacks are marked with HTML tags. <code>or <blockquote>Highlighted and containing the characters "Caused by" or "Exception in". Based on these features, all question posts containing crash stack traces are extracted offline from Stack Overflow question posts.

[0049] S1.2 Build a crash stack knowledge base: Perform word segmentation on all crash stacks extracted from Stack Overflow questions. Collect the correspondence between all question IDs and crash stacks to build a document knowledge base. This knowledge base plays an important role in the subsequent related question retrieval stage, helping the present invention quickly and preliminarily screen out potentially relevant contexts, extract useful contextual knowledge, and output the final solution;

[0050] S1.3 Establish an exception dictionary: In order to allow this method to better understand the concepts involved in the crash stack, the present invention crawls all exception names and their corresponding description information from the official documentation website to supplement relevant additional knowledge. The present invention organizes and stores this information into a dictionary to form an exception dictionary. In the subsequent processing process, if the mark in the crash cause matches the exception name in the exception dictionary, the corresponding description can be introduced as additional knowledge to assist in the retrieval and analysis of related issues, thereby enhancing the understanding and handling capabilities of crash issues;

[0051] S1.4 Training language model: Collect the titles and body texts of Stack Overflow posts, use spaces and punctuation marks to segment these contents, and remove stop words. These stop words usually contribute little to semantic expression, and removing them can reduce noise interference. Afterwards, each word is restored to its root form to further simplify the text. The processed text is used to train the FastText word embedding model, converting each word in the corpus into a vector of fixed length to better represent the semantic information of the word. At the same time, the inverse document frequency (IDF) of each word in the vocabulary is calculated. The IDF value can reflect the possibility that a word carries important semantic information. The calculation formula of IDF is as follows:

[0052] IDF(ω i )=log(N / df(ω i )) (1)

[0053] Where N is the total number of documents in the document collection, df(ω i )(document frequency) is the frequency of the document containing the word ω i The number of documents, log uses the natural logarithm (base e); finally, the IDF-weighted word embedding vector is used to represent the words in the corpus.

[0054] The S2 context information parsing phase includes the following steps:

[0055] S2.1 Input Processing and Additional Knowledge Acquisition: Given a crash stack trace P, the present invention first parses it using regular expressions to extract the crash cause CR and stack frame. Next, the present invention checks each tag in the crash cause. If a tag exactly matches an exception name in a pre-built exception dictionary, the corresponding description and exception name are added to the crash stack trace as additional knowledge.

[0056] S2.2 Preliminary Context Screening: To quickly narrow the search scope, this paper uses the crash stack knowledge base constructed in the preprocessing phase to perform a preliminary search. Specifically, the extracted crash cause CR is first segmented, then the crash stack index is loaded, and the BM25 algorithm is used to measure the similarity between each crash stack P in the index and the vocabulary in the crash cause CR. The similarity Sim(P,CR) is calculated as follows:

[0057]

[0058] Among them, f(ω i ,P) is the word ω i The frequency of terms in the crash stack trace P, |P| is the length of the crash trace, and IDF(ω i ) is the word ω i The inverse document frequency (calculated in the above formula (1)), k and b are two free parameters, which are set to 1.2 and 0.75 respectively by default. i is the word ω calculated by the bm25 algorithm i The similarity between the crash stack trace P and the crash cause CR is calculated using this formula, and the top 50 similar questions are selected. Subsequently, the present invention further filters out questions containing crash stack traces where the crash stack in the post body does not share the same exception name as the query crash stack.

[0059] S2.3 Precise analysis: The present invention proposes position-related similarity and additional knowledge similarity.

[0060] Position-related similarity: For a given crash stack, extract all its call stacks and corresponding stack frames, denote the position of the call stack in the entire crash stack as s, and denote the distance from each function marker to the top of the call stack to which it belongs as d. Then, for each marker ω in the crash stack, i Location information Can be recorded as a collection:

[0061]

[0062] Where k is ω i The total number of times this function appears in the crash trace; i represents the position index where this function marker appears; Label the function ω i The location information set, s i,1 Mark the position of the first call stack of this function in the entire crash stack, s i,k Mark the location of the kth occurrence of the call stack for this function in the entire crash stack, d i,1 Label the function ω i The distance from the top of the call stack to which the first stack frame belongs, d i,k Represents the function notation ω i The distance between the kth occurrence of the stack frame and the top of the call stack to which it belongs;

[0063] Let W be the set of all matching function tokens between a given crash stack CT1 and a crash stack CT2 in the related problem set, and each word ω i Position-dependent weight The calculation is as follows:

[0064]

[0065] Among them, dis is The average value of d in dis1 is the value corresponding to CT1. min(dis1, dis2) means taking the smaller value of the average value of d in CT1 and CT2;

[0066] The position-related similarity between CT1 and CT2 is calculated according to the BM25 algorithm as follows:

[0067]

[0068] Among them, score i is the vocabulary similarity calculated using the bm25 algorithm, n is the number of words, Calculated by Formula (2), PDSim(CT1, CT2) is the position-dependent similarity. Even if two crash stack traces have many identical tags, if the location distribution of these tags is very different (meaning the two vulnerabilities are not similar), the present invention can distinguish them and give a lower score;

[0069] Additional knowledge similarity: To understand the content of a crash stack trace, we propose to introduce additional knowledge from official documentation. Given a crash stack trace and a set of related questions, we convert the corresponding description in the official documentation of the crash stack trace and the title of the related question into two bags of words, denoted as D and T, and calculate the additional knowledge similarity using IDF-weighted word embedding vectors. The calculation formula is:

[0070]

[0071] Among them, t i is a word in the document, FastText(t i ) is the function token t represented by the trained FastText model i The corresponding embedding vector, IDF(t i ) is the inverse document frequency of the word, n is the number of corresponding document words, and EKSim(D,T) is the additional knowledge similarity.

[0072] S2.4 Final relevant context information determination: After obtaining the additional knowledge similarity and position-related similarity between a given crash stack trace CT and all questions in the related question set, these two similarities are normalized to make them comparable. The final similarity between a given crash stack trace CT and each question Q in the related question set is calculated as follows:

[0073] Rel(Q,CT)=(1-μ)PDSim+μEKSim (9)

[0074] Here, μ is a hyperparameter set to 0.25 by default, PDSim is the position-dependent similarity, EKSim is the additional knowledge similarity, and Rel(Q, CT) is the final similarity. We assign higher weight to position-dependent similarity because knowledge from official documents is needed to assist in retrieving relevant questions, rather than to dominate the search. Based on the calculated final relevance score, we return the top 10 relevant questions and their answers for a given crash stack.

[0075] The S3 crash recovery solution output phase includes the following steps:

[0076] S3.1 Calculation of answer paragraph relevance: Taking the answer paragraph as the basic granularity, the relevance of each answer paragraph A is calculated from four aspects:

[0077] (1) Question relevance: the final similarity of the question to which the paragraph belongs calculated during the related question retrieval phase;

[0078] (2) Semantic similarity: the semantic similarity with the crash stack trace description, calculated by formula (7);

[0079] (3) Number of votes: the number of votes in the answer post where the paragraph is located;

[0080] (4) Acceptance: If the answer to the paragraph is accepted, the relevance is set to 2, otherwise it is set to 1.

[0081] Multiply the above four scores and normalize them to get the final relevance Score(A,CT) of the answer paragraph A, where CT represents the given crash trace;

[0082] S3.2 Use the MMR algorithm to select solution output: In order to increase the diversity of solutions while ensuring relevance, the maximum marginal relevance (MMR) algorithm is used to select paragraphs. The formula is as follows:

[0083]

[0084] Where CT is the given crash stack trace, S is the set of selected paragraphs, R\S is the set of unselected paragraphs, and sim is the vector representation of the two answer paragraphs. The cosine similarity between i ,A j is the vector representation of the two answer paragraphs i and j, λ is a parameter used to adjust the relevance and diversity of the results, and is set to 0.75 by default. Score(A i ,CT) indicates the answer paragraph A i The final correlation with a given crash trace;

[0085] S3.3 Extracting code snippets and filtering sentences: In this work, 3 relevant paragraphs are selected to prevent the output from being too long. <code>Short code snippets enclosed in parentheses are kept in paragraphs; long code snippets not exceeding 20 lines are extracted and appended to the end of the solution, outputting the final solution.

[0086] Compared with the prior art, the present invention has the following advantages:

[0087] This invention provides a method for recommending software crash error repair solutions based on location and knowledge similarity. By taking into account both the structural information of crash tracking and additional knowledge related to the crash during processing, and utilizing unique contextual parsing and multi-factor calculation mechanisms, the invention can automatically recommend more targeted and useful software crash repair solutions to developers, improving the efficiency and accuracy of developers in resolving crash problems. Furthermore, by introducing a location- and knowledge-based similarity retrieval module, the invention can fully utilize relevant information about similar crash problems when recommending repair solutions, thereby improving the ability to respond to complex crash scenarios. BRIEF DESCRIPTION OF THE DRAWINGS

[0088] Figure 1 For crash tracking example;

[0089] Figure 2 It is the overall framework of the present invention;

[0090] Figure 3 It is a schematic diagram of stack location information;

[0091] Figure 4 This is the comparison result between the proposed method and the baseline method in different languages. Relevance refers to the relevance of the solution to crash tracking, usefulness refers to the usefulness of the solution in solving crash errors, and diversity refers to whether the generated solution contains multiple relevant methods for crash tracking. DETAILED DESCRIPTION

[0092] In order to make the objectives, technical solutions and advantages of the embodiments of the present invention more clear, the embodiments of the present invention will be further described below with reference to the accompanying drawings.

[0093] like Figure 2 As shown, a method for recommending software crash error repair solutions based on location and knowledge similarity includes the following steps:

[0094] S1.1 Extracting questions containing crash stacks: We downloaded the official StackOverflow data dump released in March 2020. Considering that this invention is designed for crash tracking based on the Java language, we extracted questions tagged as "java" or "android" on StackOverflow. In order to create our knowledge base of exception-related questions, we selected questions that met the following criteria: (i) the question had at least one answer; (ii) there was a crash trace in the question body (most crash stacks are marked with HTML tags <code>or <blockquote>The input is highlighted and contains the characters "Caused by" or "Exception in". (See S1.1 Input Processing and Additional Knowledge Acquisition for details).

[0095] S1.2 Build a crash stack knowledge base: All crash stacks extracted from Stack Overflow questions are segmented and split into independent tags. The correspondence between all question IDs and crash stacks is collected to build a document knowledge base. This knowledge base plays an important role in the subsequent related question retrieval stage, helping the present invention quickly and preliminarily screen out potentially relevant contexts, extract useful contextual knowledge, and output the final solution;

[0096] The specific operation of the word segmentation processing in the step S1.2 of building the crash stack index is as follows: collect all the titles and body texts of StackOverflow posts, which will serve as the original data source for word segmentation processing. Use spaces and punctuation marks to perform preliminary tokenization processing on the extracted text content, and divide the continuous text into individual words or symbols. Then remove the stop words in the text. Stop words are usually words that have no actual semantics or contribute little to the expression of key information in the text, such as common prepositions and conjunctions. Removing them can reduce noise and improve the efficiency and accuracy of subsequent processing. Then extract each word stem into its root form. For example, "running" may become "run" after stem extraction. This can unify words with the same semantic root but different word forms, enhancing the consistency of text processing and semantic understanding.

[0097] S1.3 Building an Exception Dictionary: We downloaded the Java SE 8 API documentation to incorporate additional crash resolution knowledge. We parsed these HTML files and extracted all class names and their descriptions. We then collected all classes without distinguishing whether they were exception classes. In total, we built a dictionary containing 4,216 class name-description pairs. Based on this data, we constructed a textual knowledge base using the title and body of each post.

[0098] S1.4 Training language model: Collect the titles and body texts of Stack Overflow posts, and use spaces and punctuation marks to segment these contents. Also remove stop words, which usually contribute little to semantic expression. Removing them can reduce noise interference. Afterwards, restore each word to its root form to further simplify the text. Use the processed text to train the FastText word embedding model, converting each word in the corpus into a fixed-length vector to better represent the semantic information of the word. At the same time, calculate the inverse document frequency (IDF) of each word in the vocabulary. The IDF value can reflect the possibility that a word carries important semantic information. Based on the above repository, we built a text corpus using the title and body of each post. The model represents each word in the corpus as a fixed-length vector.

[0099] S2.1 Input processing and additional knowledge acquisition: When a crash stack P is given, the present invention first uses regular expressions to parse it and extract the crash cause CR and stack frame respectively. The crash cause usually contains the core exception information that caused the program to crash, while the stack frame records the call stack of the program at the time of the crash. Then, the system will check each tag in the crash cause. If a tag completely matches the exception name in the pre-built exception dictionary, the description information and exception name corresponding to the exception will be added to the crash stack as additional knowledge. This additional knowledge can provide richer semantic information for subsequent question retrieval;

[0100] S2.2 Preliminary Context Screening: To quickly narrow the search scope, this paper uses the crash stack index constructed in the preprocessing phase for preliminary retrieval. Specifically, the extracted crash cause CR is first segmented, then the crash stack index is loaded, and the BM25 algorithm is used to measure the lexical similarity between each crash stack P in the index and the crash cause CR. The similarity calculation formula is as follows:

[0101]

[0102] Among them, f(ω i ,P) is the word ω i The frequency of terms in the crash trace P, |P| is the length of the crash trace, and IDF(ω i ) is the word ω i The inverse document frequency (calculated in the above formula (1)), k and b are two free parameters, which are set to 1.2 and 0.75 by default respectively. The similarity between each crash stack P and the crash cause CR is calculated by this formula, and the top 50 similar questions are selected. Subsequently, the present invention further filters out those questions containing crash stacks whose crash stacks in the post body do not share the same exception name with the query crash stack;

[0103] S2.3 Accurate retrieval: The present invention proposes position-related similarity and additional knowledge similarity.

[0104] Position-related similarity: For a given crash stack, extract all its call stacks and corresponding stack frames, denote the position of the call stack in the entire crash stack as s, and denote the distance from each function marker to the top of the call stack to which it belongs as d. Then, for each marker ω in the crash stack, i The location information can be recorded as a collection:

[0105]

[0106] Where k is ω i The total number of times it appears in crash traces;

[0107] For example, Figure 3 The position information of the black-marked words can be expressed as

[0108] Let W be the set of all matching function tokens between a given crash stack CT1 and a crash stack CT2 in the related problem set, and each word ω i The position-dependent weights are calculated as follows:

[0109]

[0110] Among them, dis is The average values of d in are from their respective crash stack traces;

[0111] Based on BM25, the position-related similarity between CT1 and CT2 is calculated as follows:

[0112]

[0113] Among them, score i Calculated by Formula 3. Even if two crash stack traces have many identical tags, if the location distribution of these tags is very different (meaning the two vulnerabilities are not similar), this algorithm can distinguish them and give a lower score;

[0114] Additional Knowledge Similarity: To understand the content of crash stack traces, we propose to introduce additional knowledge from official documentation. Given a crash stack trace and a set of related questions, we convert the corresponding description in the official documentation of the crash stack trace and the title of the related question into two bags of words, denoted as D and T respectively, and calculate the additional knowledge similarity using IDF-weighted word embedding vectors. The calculation formula is:

[0115]

[0116] Among them, t i is a word in the document, FastText(t i ) is the function token t represented by the trained FastText model (see S1.4 Training language model for details) i The corresponding embedding vector, IDF(t i ) is the inverse document frequency of the word, n represents the number of corresponding document words, and EKSim(D,T) is the additional knowledge similarity.

[0117] S2.4 Final context information determination: After obtaining the additional knowledge similarity and position-related similarity between a given crash stack trace CT and all questions in the related question set, the two similarity scores are normalized to make them comparable. The final similarity between a given crash stack trace CT and each question Q in the related question set is calculated as follows:

[0118] Rel(Q,CT)=(1-μ)PDSim+μEKSim (9)

[0119] Here, μ is a hyperparameter set to 0.25 by default. We assign higher weight to position-related similarity because we need knowledge of official documents to assist in retrieving relevant questions, rather than to dominate the search. Based on the calculated final relevance score, we return the top 10 relevant questions and their answers for a given crash stack.

[0120] S3.1 Answer paragraph scoring: Then, using the answer paragraph as the basic granularity, the relevance of each answer paragraph A is calculated from four aspects:

[0121] (1) Question relevance: the final similarity of the question to which the paragraph belongs calculated during the related question retrieval phase;

[0122] (2) Semantic similarity: the semantic similarity with the crash stack trace description, calculated by formula (7);

[0123] (3) Number of votes: the number of votes in the answer post where the paragraph is located;

[0124] (4) Acceptance: If the answer to the paragraph is accepted, the acceptance is set to 2, otherwise it is set to 1.

[0125] Multiply the above four scores and normalize them to get the final relevance Score(A,CT) of the answer paragraph A, where CT represents the given crash trace;

[0126] S3.2 Use the MMR algorithm to select solution output: In order to increase the diversity of solutions while ensuring relevance, the maximum marginal relevance (MMR) algorithm is used to select paragraphs. The formula is as follows:

[0127]

[0128] Where CT is the given crash stack trace, S is the set of selected paragraphs, R\S is the set of unselected paragraphs, and sim is the vector representation of the two answer paragraphs. The cosine similarity between them, λ is a parameter used to adjust the relevance and diversity of the results, and the default setting is 0.75;

[0129] S3.3 Extracting code snippets and filtering sentences: In this work, 3 relevant paragraphs are selected to prevent the output from being too long. <code>Short code snippets enclosed in parentheses are kept in paragraphs; long code snippets not exceeding 20 lines are extracted and appended to the end of the solution, outputting the final solution.

[0130] Comparative experiments between the present invention and the baseline method

[0131] The present invention selects two methods for automatically generating solutions to programming problems and two solution search methods commonly used by developers as baselines.

[0132] · AnswerBot: AnswerBot is a three-stage framework designed to generate answer summaries for non-factual technical questions. Evaluations of AnswerBot show that the answer summaries it generates are relevant, useful, and diverse. In our experiments, we use crash traces as input.

[0133] · CROKAGE: CROKAGE is a tool that takes a description of a programming task as a query and provides a comprehensive solution to the task. Due to the limitation of input length, we experimented by using its online website and took the crash cause part of the crash trace as input.

[0134] For the search engine-based baseline, if there is no accepted answer in the first Stack Overflow question returned by the search engine, the present invention uses the accepted answer or the answer with the highest vote. Due to their different search engine implementations, even if the present invention inputs the same content to Google and Stack Overflow, the order of Stack Overflow pages returned by the two search engines is often different.

[0135] We compared our approach with the two baseline methods described above. We invited 12 computer science students to participate in our study. All participants had 4 to 8 years of Java programming experience, while those evaluating Android crash tracking had at least 3 years of Android development experience. Participants first read a given crash trace and then read five solutions from our approach and two baseline methods. Participants were unaware of which method each solution came from, and the order of the solutions was randomized. Participants were asked to rate the five solutions based on relevance, usefulness, and diversity. Relevance refers to how relevant the solution is to the crash trace. Usefulness refers to how useful the solution is for resolving the crash error. If a solution includes multiple solutions to the crash error, we assign it a high usefulness score as long as one of the solutions solves the problem well. Diversity refers to whether the generated solution includes multiple solutions related to the crash trace. Note that if some content is irrelevant to the crash, this irrelevant content in the generated solution will not increase the diversity score. Scores range from 1 to 5, with 1 indicating "irrelevant / useless / identical" and 5 indicating "highly relevant / useful / diverse."

[0136] To evaluate our invention, we randomly selected 50 Java issues and 50 Android issues with crash traces, ensuring that there were no duplicates. We extracted all crash traces from these issues to construct the experimental query. Note that these 100 issues and their duplicates have been removed from our exception-related issue database. We refer to the 50 crash traces extracted from Java issues as Java test crashes, and the 50 crash traces extracted from Android issues as Android test crashes. The 12 participants in the experiment were divided into four groups, each receiving 25 crash traces.

[0137] The experimental results are as follows Figure 4 As shown, this shows that the crash tracking solution generated by the present invention outperforms other baselines in terms of relevance, usefulness, and especially diversity. In summary, for both Java and Android crash tracking, the performance of the present invention is significantly better than other methods.< / code> < / blockquote> < / code> < / code> < / blockquote> < / code>

Claims

1. A method for recommending software crash error repair solutions based on location and knowledge similarity, characterized in that: The following steps are involved: S1 is constructed through the context knowledge base to obtain the crash stack index, exception dictionary and trained FastText model; The S2 context information parsing phase specifically includes: S2.1: When a Java software crash occurs and a crash stack is given, the crash cause and stack frame are first extracted. If the crash cause matches the exception name in the exception dictionary, the corresponding description is added as additional knowledge; S2.2: Using the crash stack index and the BM25 algorithm to measure vocabulary similarity, we initially retrieve the top 10-100 similar issues and filter out those without shared exception names. S2.3: Calculate the position-related similarity given the crash stack; Calculate the additional knowledge similarity between the additional knowledge in the JAVA official document and the trained FastText model; S2.4: Normalize the position-related similarity and the additional knowledge similarity, calculate the final relevance, and return the top 3 to 10 context information based on the final relevance; The S3 crash repair solution output phase specifically includes: S3.1: First, using the paragraphs in the context information obtained in step S2.4 as the granularity, the comprehensive relevance of the answer paragraphs in the first 3 to 10 context information is calculated based on the four features of final relevance, semantic similarity with the crash stack description, number of answer votes, and whether the answer is accepted to obtain the comprehensive relevance. Then, based on the comprehensive relevance, the maximum marginal relevance algorithm is used to select 1 to 10 relevant paragraphs. The most relevant root cause statements are selected from the 1 to 10 relevant paragraphs through grammatical dependency analysis. At the same time, the code snippets in the 1 to 10 relevant paragraphs are output as repair patches. Finally, a complete repair solution is output.

2. The method for recommending software crash error repair solutions based on location and knowledge similarity according to claim 1, characterized in that: In step S1, the crash stack index, exception dictionary, and trained FastText model are obtained through the context knowledge base construction, including: S1.1: Extract question posts containing crash stack traces from the Stack Overflow website data as a corpus; S1.2: Segment the crash stacks collected in the corpus and construct a crash stack index; S1.3: Crawl exception information from the official JAVA documentation and build an exception dictionary; S1.4: Collect Stack Overflow post text from the Stack Overflow website data, train the FastText model after processing and calculate the inverse document frequency to obtain the trained FastText model.

3. The method for recommending software crash error repair solutions based on location and knowledge similarity according to claim 1, characterized in that: In step S2.3, the location-related similarity is calculated using the given crash stack, specifically including: For a given crash stack, extract all its call stacks and corresponding stack frames, denote the position of the call stack in the entire crash stack as s, and denote the distance from each function marker to the top of the call stack to which it belongs as d. Then, for each function marker ω in the crash stack i The location information is recorded as: Where k is ω i The total number of times this function appears in the crash trace; i represents the position index where this function marker appears; Label the function ω i The location information set, s i,1 Mark the position of the first call stack of this function in the entire crash stack, s i,k Mark the location of the kth occurrence of the call stack for this function in the entire crash stack, d i,1 Label the function ω i The distance between the first stack frame and the top of the call stack to which it belongs, d i,k Represents the function notation ω i The distance between the kth occurrence of the stack frame and the top of the call stack to which it belongs; Let W be the set of all matching function tokens between a given crash stack CT1 and a crash stack CT2 in the related problem set, and each function token ω i Position-dependent weight The calculation is as follows: Among them, ω i is the function mark in W, dis is The average value of d in dis1 is the value corresponding to CT1. min(dis1, dis2) means taking the smaller value of the average value of d in CT1 and CT2; The position-related similarity between CT1 and CT2 is calculated according to the BM25 algorithm as follows: Among them, score i The matching function mark ω is calculated using the bm25 algorithm i The vocabulary similarity with the crash stack CT2 in the related problem set, n is the number of tokens, Calculated by formula (2), PDSim(CT1, CT2) is the position-related similarity.

4. The method for recommending software crash error repair solutions based on location and knowledge similarity according to claim 1, characterized in that: In step S2.3, the additional knowledge similarity is calculated using the additional knowledge in the JAVA official document and the trained FastText model, specifically including: The corresponding description in the JAVA official document of the crash stack and the title of the related question are converted into two word bags, denoted as D and T respectively, and the additional knowledge similarity is calculated using the inverse document frequency weighted word embedding vector. The calculation formula is: Among them, t i is a word in the document, FastText(t i ) is the function token t represented by the trained FastText model i The corresponding embedding vector, IDF(t i ) is the inverse document frequency of the word, n represents the number of words in the corresponding document D or T, and EKSim(D,T) is the additional knowledge similarity.

5. The method for recommending software crash error repair solutions based on location and knowledge similarity according to claim 1, characterized in that: In step S2.4, the position-related similarity and the additional knowledge similarity are normalized to calculate the final relevance, which specifically includes: The final similarity between a given crash stack trace CT and each question Q in the related question set is calculated as follows: Rel(Q,CT)=(1-μ)PDSim+μEKSim (6) Among them, μ is a hyperparameter, PDSim is the position-dependent similarity, EKSim is the additional knowledge similarity, and Rel(Q,CT) is the final similarity.

6. The method for recommending software crash error repair solutions based on location and knowledge similarity according to claim 1, characterized in that: In step S3.1, the calculation of semantic similarity with the crash stack description includes: First, the trained FastText model converts the paragraph and crash stack description into vectors respectively, and uses the inverse document frequency to perform weighted averaging to obtain the processed two vectors. Then, the vector inner product of these two vectors is calculated to obtain the semantic similarity.

Images