FLOBBI three-party library incompatibility fault localization

Abstract

The application discloses a three-party library incompatibility fault positioning method based on a FLOBBI framework, relates to the technical field of software engineering, and comprises program preprocessing, a dump fault positioning method and a restore reset method, wherein the dump fault positioning method comprises method level coarse-grained fault positioning, statement level fine-grained fault positioning, runtime object serialization, dump file generation and dump file difference comparison, and the restore reset method comprises reset statement instrumenting and object resetting by reverse serializing a compatible version dump file. The application has the advantages that the differences between compatible versions and incompatible versions are utilized; a two-stage method is adopted to compress the fault positioning space, improve the effectiveness and efficiency of fault positioning; correct context information generated by the compatible version is utilized to reset error information in the incompatible version, the suspected fault points obtained by fault positioning are further determined, and the accuracy of fault positioning is improved.

Description

Technical Field

[0001] This invention relates to the field of software engineering technology, specifically to fault location of incompatibility between the FLOBBI third-party library. Background Technology

[0002] The asynchronous development of third-party libraries and client software has brought challenges to the software ecosystem, namely backward incompatibility issues [1]. Based on whether the function signature has changed, backward incompatibility issues are divided into signature-level backward incompatibility issues and behavioral backward incompatibility issues. Signature-level backward incompatibility issues cannot pass the compilation stage and are easy to analyze and locate; while behavioral backward incompatibility issues can often pass the compilation stage, but affect the program results and are difficult to locate.

[0003] Fault location [2] is the behavior of identifying the location of faults in a program. The fault location method based on program spectrum obtains the spectrum information of each statement by executing test cases in the program under test, calculates and generates a ranking of suspicious values, and effectively obtains the location highly related to the fault. However, there are two problems with the method based on program spectrum for locating backward incompatible faults: 1) Missing test cases. The fault location method based on program spectrum requires test cases that have been successfully run and test cases that have failed to run. However, the backward incompatibility problem will not cause the program to fail to run under the test cases, but will only cause the program to run differently; 2) The fault is unrelated to the third-party library. The program studied in this invention has not changed, but the version of the third-party library has changed. The error is caused by the incompatibility of the third-party library. Therefore, only the API methods related to the third-party library in the program are considered. However, the fault location method based on program spectrum takes all the methods and functions in the program as the analysis object, which expands the analysis scope and affects the analysis efficiency.

[0004] DeBBI[3] uses information retrieval technology to sort software projects in large-scale client software testing according to priority and obtain incompatible APIs that may have faults. However, there are still problems with using information retrieval technology to locate backward incompatibility faults: the time cost is high. The first fault can be found in a few seconds, but subsequent faults are difficult to find. On average, it takes several hours to find a fault.

[0005] The asynchronous development of third-party libraries and client software has led to backward incompatibility issues. The same code, depending on different versions of the same third-party library, can produce drastically different results. These backward incompatibility issues cannot be detected during the compilation phase; the errors are subtle but can have a significant impact on the outcome. Therefore, to address these problems, the inventors proposed the FLOBBI third-party library incompatibility fault localization method. Summary of the Invention

[0006] (a) Technical problems to be solved To address the problem of locating faults due to backward incompatibility in behavior, the present invention aims to provide fault location for incompatibility with the FLOBBI third-party library.

[0007] (II) Technical Solution To address the aforementioned technical issues, this paper proposes a method for locating third-party library incompatibility faults based on the FLOBBI framework. This solution overcomes the shortcomings of existing fault location methods, such as the lack of sufficient test cases to drive the accuracy of fault location, the lack of utilization of incompatible and compatible versions of third-party libraries, large fault location search space, long time consumption, and inability to quickly obtain the root cause of incompatibility errors.

[0008] To achieve the above objectives, the technical solution adopted by the present invention is as follows: Preprocessing of the program under test: Construct a comparative test environment so that the same program P depends on different versions of the same third-party library, resulting in programs P1 and P2. The program runs inconsistently under different versions of the third-party library, which is manifested in inconsistent output. Cases with compilation errors and runtime exceptions are discarded. Dump-based fault localization: First, coarse-grained instrumentation is performed on the two versions of the program at the method level to obtain runtime information. By comparison, suspicious methods F with faults are obtained. Then, fine-grained instrumentation is performed on the two versions of the program at the statement level to obtain runtime information. By comparison, suspicious statements with faults are obtained, and a set of suspicious statements S is generated. Fault determination based on restore: For each of the generated suspicious statements S, operate on it one by one, construct a new program to reset the context of the statement, run it, until the program that depends on the incompatible version no longer causes errors; Preferably, the dump-based fault location includes the following steps: Coarse-grained fault localization: Each method in the client program is used as a research module to locate methods that include calls to third-party libraries, obtain runtime context dump information, and identify suspicious methods through comparison; Fine-grained fault localization: Each statement in a suspicious method is used as a research module to locate statements containing third-party library calls, obtain runtime context information, and identify suspicious statements through comparison; Preferably, the coarse-grained fault location includes the following steps: Instrumentation method selection: In programs P1 and P2, each method is traversed, and it is checked whether it contains calls to third-party libraries. Methods containing calls to third-party libraries are selected as instrumentation methods, while other methods are discarded. Return statement determination: Iterate through each statement in the instrumentation method, check its statement type, and select the return statement (returnStatement). Dump statement instrumentation: For each instrumented method containing third-party library calls, for each return statement in the method, insert a dump statement save(v) before the execution of the return statement to obtain the new program P1. ’ and P2 ’ ; Generate dump files: Run the new program P1 respectively. ’ and P2 ’ The save(v) statement serializes the variable v, converts it into a JSON file and stores it locally, resulting in dump files D1 and D2. Dump file comparison: Compare dump file D1 obtained from a compatible version with dump file D2 obtained from an incompatible version, and record the files that differ. The comparison of the two dump files can result in four scenarios: identical, different, added, and deleted. Obtain the set of suspicious methods: Based on the files with differences, obtain the specific methods where the differences exist. The methods with differences are the suspicious methods where incompatibility failures occur, resulting in the set of suspicious methods F. Preferably, the fine-grained fault localization includes the following steps: Suspicious method selection: In programs P1 and P2, each method f in the suspicious method set F is traversed respectively; Call statement judgment: For each statement in the suspicious method f, check whether it contains a call to a third-party library, check its statement type, and select the call statement invokeStatement that contains a call to a third-party library; Dump statement instrumentation: For each statement containing a third-party library call, insert a dump statement save(v) after the call statement is executed to obtain a new program P1. ’’ and P2 ’’ ; Generate dump files: Run the new program P1 respectively. ’’ and P2 ’’ The save(v) statement serializes the variable v, converts it into a JSON file, and stores it locally, resulting in the dump file D1. ’’ and D2 ’’； Dump file comparison: Compare the dump file D1 obtained based on the compatible version. ’’ and the dump file D2 obtained by relying on incompatible versions ’’ Compare the files and record any differences. Comparing two dump files can result in four scenarios: identical, different, added, and deleted. Obtaining a set of suspicious statements: Based on the files with discrepancies, obtain the specific statements containing the differing variables. Statements with differing variables are the suspicious statements where incompatibility issues occur, resulting in a set S of suspicious statements. Preferably, the dump file comparison involves four scenarios: The consistency scenario is as follows: if two JSON files are converted into syntax trees and the two trees are completely identical, then the variables represented by the two JSON files are the same. The difference is as follows: if two JSON files are converted into syntax trees and the two tree structures are completely identical, but the values ​​of the nodes change, it means that the variables represented by the two JSON files have different fields, and therefore the variables represented by the two JSON files are different. The new scenario is as follows: when two JSON files are converted into syntax trees, the tree converted from the incompatible version of JSON contains new nodes, which means that the variables in the incompatible version have new fields. The backward incompatibility fault only considers existing consistency and does not consider new additions. Therefore, the variables represented by the two JSON files are the same. The deletion scenario is as follows: when two JSON files are converted into syntax trees, the tree converted from the incompatible version of JSON is missing nodes, which means that the variables in the incompatible version have lost their original fields. Since they are incompatible, the variables represented by the two JSON files are different. Preferably, the fault determination based on restore includes the following steps: Suspicious statement selection: In program P2, which depends on incompatible third-party libraries, traverse each statement s in the suspicious statement set S.

[0009] Reset statement instrumentation: For each suspicious statement obtained, a reset statement restore(v) is inserted after the execution of the suspicious statement to obtain a new program P1. ’’’ and P2 ’’’ ; Reset file reading: restore(v) will read the local dump file D1 that depends on the compatible version. ’’ The corresponding JSON file is deserialized into runtime variables.

[0010] Reset program execution: Run P2 ’’’ If the context information generated by the incompatible version is overwritten by the reset file, and if the error no longer occurs due to the incompatible third-party library, then the suspicious statement s in the current restore is the confirmed fault statement.

[0011] (III) Beneficial Effects Compared with the prior art, the beneficial effects of the present invention are as follows: To address the issue of locating behavioral incompatibility faults, this method utilizes the FLOBBI program analysis framework based on crawled information comparison to construct an automated fault location tool. Its main contributions are twofold: 1) Two-stage fault location: a coarse-grained method-level fault location stage identifies suspicious methods and functions related to third-party libraries; and a fine-grained statement-level fault location stage identifies faulty statements among the methods obtained in the first stage. 2) Incompatibility fault repair: Correct information generated by the compatible version replaces the error information generated by the incompatible version, ensuring that test cases yield expected results even in the incompatible version, verifying the correctness of whether suspicious points are indeed fault points, and eliminating the impact of incompatible third-party libraries. Using 60 faults from 7 real-world third-party libraries as experimental subjects, the proposed FLOBBI method and the fault location method based on program spectrum were executed respectively. The experimental results are shown in Table 1 (Top-1: the fault is in the most suspicious API given by the location method; Top-3: the fault is in the three most suspicious APIs given, and the percentage represents the proportion of the given correct location to the actual fault). The experimental results show that the proposed method is more accurate than spectrum analysis in various third-party libraries and at various metric levels.

[0012] Attached Figure Description

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

[0014] Figure 1 Figure 1 shows the FLOBBI framework flowchart of this invention.

[0015] Figure 2 Figure 2 shows the coarse-grained fault location results of this invention.

[0016] Figure 3 Figure 3 shows the results of fine-grained fault location according to the present invention. Detailed Implementation

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

[0018] First, let's explain the relevant terms used in this method: SA1. Third-party libraries: Third-party libraries are software code libraries created, maintained, and provided by other developers or organizations that can be used by other developers in their applications. Third-party libraries usually provide specific functions, classes, methods, or tools, such as data processing, network communication, user interface, etc. In software development, third-party libraries are very common tools because they can significantly speed up the development and deployment of applications and improve code quality and maintainability. SA2. Incompatibility issues: There are issues such as version incompatibility and interface incompatibility between third-party libraries, which can cause code to fail to compile, run, or encounter exceptions. SA3, Signature-level incompatibility issues: Inconsistencies arise between different versions of third-party libraries, function interfaces change, interface names or interface parameters change, causing code to fail to compile; SA4, Behavioral incompatibility issues: Inconsistencies arise between different versions of third-party libraries. The function interfaces remain unchanged, but the internal behavior of the functions changes. The code can be compiled, but the final behavioral results are inconsistent. SA5. Fault Location: The process of determining the specific causes and locations of errors and defects in software through testing and analysis. Software test fault location is usually one of the important steps in the software development process to ensure the quality and stability of the software. SA6. Instrumentation: Program instrumentation refers to manually or automatically adding special code snippets to the program source code in order to collect information about program execution or perform specific operations during program runtime. These special code snippets are usually called instrumentation code or monitors, which can record information such as variable values, function calls, and program control flow during program runtime for program performance analysis, debugging, and testing. SA7, dump: Instruments at the bytecode level of a program to obtain the real-time content of variables during program execution and serializes Java objects into JSON information; SA8, restore: Instruments at the bytecode level of the program, deserializes JSON information into JAVA objects, and replaces the incompatible fault context during program execution, so that the repaired program avoids the influence of third-party libraries and executes correctly; SA9 and FLOBBI frameworks: These are program analysis frameworks consisting of dump and restore operations. They obtain and process runtime information through bytecode instrumentation to discover backward incompatibility issues in third-party libraries. like Figure 1-3 As shown, this invention proposes a method for locating third-party library incompatibility faults based on the FLOBBI framework, comprising the following steps: Preprocessing of the program under test: Construct a comparative test environment so that the same program P depends on different versions of the same third-party library, resulting in programs P1 and P2. The program runs inconsistently under different versions of the third-party library, which is manifested in inconsistent output. Cases with compilation errors and runtime exceptions are discarded. Dump-based fault localization: First, coarse-grained instrumentation is performed on the two versions of the program at the method level to obtain runtime information. By comparison, suspicious methods F with faults are obtained. Then, fine-grained instrumentation is performed on the two versions of the program at the statement level to obtain runtime information. By comparison, suspicious statements with faults are obtained, and a set of suspicious statements S is generated. Fault determination based on restore: For each of the generated suspicious statements S, operate on it one by one, construct a new program to reset the context of the statement, run it, until the program that depends on the incompatible version no longer causes errors; The dump-based fault location process specifically includes the following steps: Coarse-grained fault localization: Each method in the client program is used as a research module to locate methods that include calls to third-party libraries, obtain runtime context dump information, and identify suspicious methods through comparison; Fine-grained fault localization: Each statement in a suspicious method is used as a research module to locate statements that contain calls to third-party libraries, obtain runtime context information, and identify suspicious statements through comparison.

[0019] Coarse-grained fault location specifically includes the following steps: Instrumentation method selection: In programs P1 and P2, each method is traversed, and it is checked whether it contains calls to third-party libraries. Methods containing calls to third-party libraries are selected as instrumentation methods, while other methods are discarded. Return statement determination: Iterate through each statement in the instrumentation method, check its statement type, and select the return statement (returnStatement). Dump statement instrumentation: For each instrumented method containing third-party library calls, for each return statement in the method, insert a dump statement save(v) before the execution of the return statement to obtain the new program P1. ’ and P2 ’ ; Generate dump files: Run the new program P1 respectively. ’ and P2 ’ The save(v) statement serializes the variable v, converts it into a JSON file and stores it locally, resulting in dump files D1 and D2. Comparison of dump files: Compare dump file D1 obtained by relying on the compatible version with dump file D2 obtained by relying on the incompatible version, and record the files that are different. The comparison of the two dump files can be divided into four cases: consistent, different, added, and deleted. Obtain the set of suspicious methods: Based on the files with differences, obtain the specific methods where the differences exist. The methods with differences are the suspicious methods that have caused incompatibility failures, and obtain the set of suspicious methods F.

[0020] Fine-grained fault localization specifically includes the following steps: Suspicious method selection: In programs P1 and P2, each method f in the suspicious method set F is traversed respectively; Call statement judgment: For each statement in the suspicious method f, check whether it contains a call to a third-party library, check its statement type, and select the call statement invokeStatement that contains a call to a third-party library; Dump statement instrumentation: For each statement containing a third-party library call, insert a dump statement save(v) after the call statement is executed to obtain a new program P1. ’’ and P2 ’’ ; Generate dump files: Run the new program P1 respectively. ’’ and P2 ’’ The save(v) statement serializes the variable v, converts it into a JSON file, and stores it locally, resulting in the dump file D1. ’’ and D2 ’’； Dump file comparison: Compare the dump file D1 obtained based on the compatible version. ’’ and the dump file D2 obtained by relying on incompatible versions ’’ Compare the two dump files and record the files that differ from each other. There are four possible scenarios when comparing the two dump files: consistent, different, added, and deleted. Obtain the set of suspicious statements: Based on the files with differences, obtain the specific statements where the differences exist. The statements with differences are the suspicious statements where incompatibility failures occur, resulting in a set of suspicious statements S.

[0021] There are four scenarios involved in comparing dump files: The consistency scenario is as follows: if two JSON files are converted into syntax trees and the two trees are completely identical, then the variables represented by the two JSON files are the same. The difference is as follows: if two JSON files are converted into syntax trees and the two tree structures are completely identical, but the values ​​of the nodes change, it means that the variables represented by the two JSON files have different fields, and therefore the variables represented by the two JSON files are different. The new scenario is as follows: when two JSON files are converted into syntax trees, the tree converted from the incompatible version of JSON contains new nodes, which means that the variables in the incompatible version have new fields. The backward incompatibility fault only considers existing consistency and does not consider new additions. Therefore, the variables represented by the two JSON files are the same. The deletion scenario is as follows: when two JSON files are converted into syntax trees, the tree converted from the incompatible version of JSON is missing nodes, which means that the variables in the incompatible version have lost their original fields. Since they are incompatible, the variables represented by the two JSON files are different. The fault determination based on restore includes the following steps: Suspicious statement selection: In program P2, which depends on incompatible third-party libraries, traverse each statement s in the suspicious statement set S; Reset statement instrumentation: For each suspicious statement obtained, a reset statement restore(v) is inserted after the execution of the suspicious statement to obtain a new program P1. ’’’ and P2 ’’’ ; Reset file reading: restore(v) will read the local dump file D1 that depends on the compatible version. ’’ The corresponding JSON file is deserialized into runtime variables.

[0022] Reset program execution: Run P2 ’’’ If the context information generated by the incompatible version is overwritten by the reset file, and if the error no longer occurs due to the incompatible third-party library, then the suspicious statement s in the current restore is the confirmed fault statement.

[0023] Implementation steps: 1. Program preprocessing stage Using the Jsoup 1.6.0 test program as the test program for the entire project, and constructing the base project / jsoup-jsoup-1.6.0 with the test program as a dependency of Jsoup 1.6.0, the project was executed, and all 278 test cases ran successfully. The dependency file was then modified to make the test program depend on Jsoup 1.6.3, constructing the compare project / jsoup-1.6.3-use-jsoup-1.6.0, and the project was executed. Compilation was successful, but a failure occurred during the execution phase.

[0024] 2. Dump location stage A) Coarse-grained positioning At the bytecode level, each function and statement in both the base and Compare projects was traversed, and methods containing APIs from the third-party library Jsoup were marked, resulting in a total of 270 methods. These 270 functions in both projects were then instrumented, generating folders ` / dumpMethod / jsoup-1.6.0 / dumpData` and ` / dumpMethod / jsoup-1.6.3-use-jsoup-1.6.0 / dumpData` respectively. Each folder contains the dump result for each function, such as ` / org.jsoup.parser.ParserTest.handlesBaseTags / r16.json`, which represents the serialized JSON file after `ParserTest` executed the `handlesBaseTags` method.

[0025] Comparing all files in the folders / dumpMethod / jsoup-1.6.0 / dumpData and / dumpMethod / jsoup-1.6.3-use-jsoup-1.6.0 / dumpData revealed that one function out of 270 had inconsistent results in the two projects. The handlesBaseTags function in ParserTest was reported as a suspicious faulty function.

[0026] B) Fine-grained positioning At the bytecode level, the suspicious method handlesBaseTags obtained from coarse-grained localization was used as the analysis object for fine-grained localization. Each line of the handlesBaseTags method was traversed in both the base and Compare projects, and the statement lines containing API calls from the third-party library Jsoup were marked, resulting in a total of 10 statements. Instrumentation was performed on the 10 statements in the two projects, and the initialized and live variables contained in each statement were serialized and dumped, and stored in the folders / dumpLine / jsoup-1.6.0 / dumpData and / dumpLine / jsoup-1.6.3-use-jsoup-1.6.0 / dumpData, respectively.

[0027] Comparing all files in the folders / dumpLine / jsoup-1.6.0 / dumpData and / dumpLine / jsoup-1.6.3-use-jsoup-1.6.0 / dumpData revealed differences in variables across all 10 statement lines. Line 246, specifically `Document doc = Jsoup.parse(h, "http: / / foo / ")`, was identified as the most likely source of the failure. Here, `Jsoup.parse` is an API function from the Jsoup library. Line 246 in `ParserTest` was reported as the failure point.

[0028] 3. Fault Repair Phase Instrumentation was performed on the Compare project, which relies on incompatible versions of third-party libraries. An additional `restore` statement was inserted after line 246 of the `ParserTest` file. This statement loads the dump information from line 246 of the `handlesBaseTags` method in the base version of the `ParserTest` file, specifically ` / dumpLine / jsoup-1.6.0 / dumpData / handlesBaseTags / 246 / r1--r1 =staticinvoke <.json`, and deserializes the JSON file into a Java object to restore the context information of line 246. The Compare project was then run again, and all test cases passed. This indicates that line 246 in the `ParserTest` file of the second-stage fault location report is the actual fault point. `Jsoup.parse()` is an incompatible API introduced after Jsoup was upgraded from version 1.6.0 to 1.6.3. Fault location was successful, and the Top-1 suspicious point in the second-stage fault location report is the actual fault point.

[0029] References: [1] S. Raemaekers, A. Van Deursen, and J. Visser, "Semanticversioning versus breaking changes: A study of the maven repository," in 2014IEEE 14th International Working Conference on Source Code Analysis andManipulation. IEEE, 2014, pp. 215-224. [2] WE Wong, R. Gao, Y. Li, R. Abreu and F. Wotawa, "A Survey onSoftware Fault Localization," in IEEE Transactions on Software Engineering, vol. 42, no. 8, pp. 707-740, 1 Aug. 2016, doi: 10.1109 / TSE.2016.2521368. [3] L. Chen, F. Hassan, X. Wang, and L. Zhang, “Taming behavioral backward incompatibilities via cross-project testing and analysis,” inProceedings of the ACM / IEEE 42nd International Conference on SoftwareEngineering, 2020, pp. 112-124. Obviously, those skilled in the art can make various modifications and variations to this invention without departing from its spirit and scope. Therefore, if these modifications and variations fall within the scope of the claims of this invention and their equivalents, this invention also intends to include these modifications and variations.

Claims

1. A method for locating incompatibility issues between third-party libraries based on the FLOBBI framework, characterized in that, Includes the following steps: Preprocessing of the program under test: Construct a comparative test environment so that the same program P depends on different versions of the same third-party library, resulting in programs P1 and P2. The program runs inconsistently under different versions of the third-party library, which is manifested in inconsistent output. Cases with compilation errors and runtime exceptions are discarded. Dump-based fault localization: First, coarse-grained instrumentation is performed on the two versions of the program at the method level to obtain runtime information. By comparison, suspicious methods F with faults are obtained. Then, fine-grained instrumentation is performed on the two versions of the program at the statement level to obtain runtime information. By comparison, suspicious statements with faults are obtained, and a set of suspicious statements S is generated. Fault determination based on restore: For each of the generated suspicious statements S, operate on it one by one, construct a new program to reset the context of the statement, run it, until the program that depends on the incompatible version no longer causes errors; The dump-based fault location includes the following steps: Coarse-grained fault localization: Each method in the client program is used as a research module to locate methods that include calls to third-party libraries, obtain runtime context dump information, and identify suspicious methods through comparison; Fine-grained fault localization: Each statement in a suspicious method is used as a research module to locate statements containing third-party library calls, obtain runtime context information, and identify suspicious statements through comparison; The coarse-grained fault location includes the following steps: Instrumentation method selection: In programs P1 and P2, each method is traversed and checked for whether it contains calls to third-party libraries. Methods containing calls to third-party libraries are selected as instrumentation methods, while other methods are discarded. Return statement determination: Iterate through each statement in the instrumentation method, check its statement type, and select the return statement (returnStatement). Dump statement instrumentation: For each instrumented method containing third-party library calls, for each return statement in the method, insert a dump statement save(v) before the execution of the return statement to obtain the new program P1. ’ and P2 ’ ; Generate dump files: Run the new program P1 respectively. ’ and P2 ’ The save(v) statement serializes the variable v, converts it into a JSON file and stores it locally, resulting in dump files D1 and D2. Comparison of dump files: Compare dump file D1 obtained from the compatible version with dump file D2 obtained from the incompatible version, and record the files that are different; the comparison of the two dump files can be divided into four cases: consistent, different, added, and deleted. Obtain the set of suspicious methods: Based on the files with differences, obtain the specific methods where the differences exist. The methods with differences are the suspicious methods where incompatibility failures occur, resulting in the set of suspicious methods F. The fine-grained fault localization includes the following steps: Suspicious method selection: In programs P1 and P2, each method f in the suspicious method set F is traversed respectively; Call statement judgment: For each statement in the suspicious method f, check whether it contains a call to a third-party library, check its statement type, and select the call statement invokeStatement that contains a call to a third-party library; Dump statement instrumentation: For each statement containing a third-party library call, insert a dump statement save(v) after the call statement is executed to obtain a new program P1. ’’ and P2 ’’ ; Generate dump files: Run the new program P1 respectively. ’’ and P2 ’’ The save(v) statement serializes the variable v, converts it into a JSON file, and stores it locally, resulting in the dump file D1. ’’ and D2 ’’ ; Dump file comparison: Compare the dump file D1 obtained based on the compatible version. ’’ and the dump file D2 obtained by relying on incompatible versions ’’ Compare and record the files that differ; when comparing two dump files, there are four possibilities: consistent, differing, added, and deleted. Obtain the set of suspicious statements: Based on the files with differences, obtain the specific statements where the differences exist. The statements with differences are the suspicious statements where incompatibility failures occur, resulting in a set of suspicious statements S. The fault determination based on restore includes the following steps: Suspicious statement selection: In program P2, which depends on incompatible third-party libraries, traverse each statement s in the suspicious statement set S; Reset statement instrumentation: For each suspicious statement obtained, a reset statement restore(v) is inserted after the execution of the suspicious statement to obtain a new program P1. ’’’ and P2 ’’’ ; Reset file reading: restore(v) will read the local dump file D1 that depends on the compatible version. ’’ The corresponding JSON file is deserialized into runtime variables; Reset program execution: Run P2 ’’’ If the context information generated by the incompatible version is overwritten by the reset file, and if the error no longer occurs due to the incompatible third-party library, then the suspicious statement s in the current restore is the confirmed fault statement.

2. The method for locating third-party library incompatibility based on the FLOBBI framework according to claim 1, characterized in that, There are four scenarios for the comparison of the dump files: The consistent case is: if the two JSON files are converted into syntax trees and the two trees are completely identical, then the variables represented by the two JSON files are the same; The difference is as follows: if two JSON files are converted into syntax trees and the two tree structures are completely identical, but the values ​​of the nodes change, it means that the variables represented by the two JSON files have different fields, and therefore the variables represented by the two JSON files are different. The new scenario is: when two JSON files are converted into syntax trees, the tree converted from the incompatible version of JSON contains new nodes, which means that the variables in the incompatible version have newly added fields. Backward incompatibility faults only consider existing consistency and do not consider new additions. Therefore, the variables represented by the two JSON files are the same. The deletion occurs when two JSON files are converted into syntax trees. The tree generated from the incompatible version of the JSON is missing nodes, which means that the variables in the incompatible version have lost their original fields. This backward incompatibility means that the variables represented by the two JSON files are different.

Images