CN115934157B

CN115934157B - Automatic software dependency range deducing method, device, computer equipment and memory

Info

Publication number: CN115934157B
Application number: CN202211694947.8A
Authority: CN
Inventors: 贾周阳; 李姗姗; 姜志杰; 王腾; 张元良; 余跃; 马俊; 李小玲; 黄响兵; 何浩辰
Original assignee: National University of Defense Technology
Current assignee: National University of Defense Technology
Priority date: 2022-12-28
Filing date: 2022-12-28
Publication date: 2024-04-16
Anticipated expiration: 2042-12-28
Also published as: CN115934157A

Abstract

The application relates to a software dependency range automatic deducing method, a device, computer equipment and a memory, belonging to the technical field of software dependency defect detection. The method comprises the following steps: acquiring a plurality of backward incompatible changes of a third party library, analyzing source codes or binary files of software to be detected, and preprocessing a backward incompatible change set according to analysis results; detecting the preprocessed backward incompatible change set according to the source code or binary file of the software to be detected to obtain a backward incompatible library version, and reporting the dependent defects; performing global detection on all library versions of the third-party library according to the backward incompatibility change to obtain all incompatible library versions; and automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions. The method for detecting the incompatible library version is more accurate and efficient, and the false alarm rate is lower, so that the inferred dependency range is more accurate, and the method can help the terminal user to avoid the occurrence of compatibility errors.

Description

Automatic software dependency range deducing method, device, computer equipment and memory

Technical Field

The present application relates to the field of software-dependent defect detection technology, and in particular, to a method, an apparatus, a computer device, and a memory for automatically deducing a software-dependent range.

Background

With the advancement and development of society, the application of computer software technology is more and more extensive, and software has become an infrastructure of an information society, and meanwhile, the scale of the software is also increasing. Although the traditional software system development mode can meet different functional requirements, the software development mode inevitably requires software developers to repeatedly develop the same software functions, the efficiency is low, and meanwhile, the code redundancy is the problem of repeatedly manufacturing wheels, which is commonly known in the field of software engineering. Therefore, in order to avoid repeated development, relying on third-party open source libraries and components in the software development process is a common practice to improve development efficiency. However, incompatible changes (e.g., adding or deleting interfaces) may occur in the evolution of the third party library, which in turn results in runtime errors due to compatibility when the software relies on the third party library.

Software compatibility errors typically involve third party library developers, software developers, end user three-party software participants. When an incompatible change occurs in a library, there are typically three ways to avoid software compatibility errors: 1) Third party library developers revoke incompatible changes in developing the latest library version; 2) Software developers upgrade software to accommodate changes in third party libraries; 3) End users may avoid using incompatible third party library versions. Currently, there is much research effort focused on detecting changes to third party libraries and reporting to library developers advice to not make incompatible changes, represented by "EFFICIENT STATIC CHECKING of Library Updates (efficient static check of library updates)" published by Darius Foo et al at FSE2018, capable of automatically and effectively checking whether library upgrades introduce application programming interface (Application Program Interface, API) incompatibilities. Still other efforts may assist software developers in updating software to achieve co-evolution of software and libraries, mainly including both types. The first type of work is represented by "CiD: automating the Detection of API-Related Compatibility Issues in Android Apps" published by Li et al at ISSTA2018 (CiD: automatic detection of API related compatibility problems in android applications), mainly focusing on detecting the use of incompatible apis by software, and the second type of work is represented by "API-Evolution Support with Diff-CatchUp (supporting API evolution using diff-CatchUp)" published by Zhenchang Xing et al at TSE2007, mainly focusing on how to help software adapt to library changes so that the latest version of software can work better.

However, both of the above methods are considered as a post-process, helping the latest software version and the latest library version to perform well, but at this time, the terminal user has suffered from a software compatibility error, and needs to wait for the software or the third party library to issue a new version. In contrast, the third method is more efficient and reliable: end users can avoid using incompatible library versions from the beginning, thereby avoiding software compatibility errors. Existing research efforts fail to automatically assist users in selecting compatible library versions. Darius Foo et al, "EFFICIENT STATIC CHECKING of library updates (efficient static check of library updates)" published in FSE2018 and STEVEN RAEMAEKERS et al "Semantic Versioning versus Breaking Changes: A Study of the Maven Repository (semantic version control and major changes: maven repository study)" published in SCAM2014 found, through investigation, that on average 26% to 1/3 of library versions violated semantic version control, which undermine backward compatibility in the case of non-major version updates. Backward compatibility is an ideal feature for users of libraries or APIs. Without compatibility, library users would be at greater risk and cost in upgrading their dependent items. In the evolution history of the library, software compatibility errors may be caused by changes breaking forward compatibility or backward compatibility, but the problem of software compatibility errors caused by backward incompatibility changes is particularly serious.

With the enhancement of the dependency of software developers on third-party libraries, the manual maintenance of the software dependencies is time-consuming, laborious and error-prone. One common approach is therefore to use dependency management tools to manage dependencies of items of software. Dependency management tools for operating systems, such as yum for centOS, apt for Debian, dnf for Fedora, packman for Arch, homebrew for macOS; dependency management tools for programming languages, such as Maven, nuget, nodeis, npm, golang, goget, python, ruby, gem for Java. The solution idea of the dependency management platform is to put the dependencies in a common warehouse, manually appoint the needed libraries and corresponding versions by developers, and then obtain corresponding library packages by the management tool through the dependency description file to a central warehouse. When using third party libraries, trade-off issues with version updates are often faced: in order to keep the software item stable, the third party library version is limited (a fixed version is used, the software cannot have any incompatibility problem, the reliability is ensured, but the flexibility is lost, for example, the library has repaired a major defect in a new version, but the software cannot automatically use the new library version); or continuously iteratively updating the version of the third party library to use the new characteristics (automatically obtaining a new library version meeting the version range, but the new library version may break the backward compatibility to cause software compatibility errors, thereby improving flexibility but being unreliable). The reasons for the software developer to update or not update the third party library version are not the same.

In summary, how to detect and repair the dependency defects in the dependency management system is a hotspot problem under discussion by those skilled in the art.

Disclosure of Invention

In view of the foregoing, it is desirable to provide a method, an apparatus, a computer device, and a memory for automatically estimating a software dependency range. The method can automatically detect whether each version of the software and the library is compatible or not to help a user select the correct version so as to prevent software compatibility errors, thereby helping developers to improve reliability while ensuring flexibility of the software.

A method of software dependent range automatic inference, the method comprising:

And acquiring a plurality of backward incompatible changes of the third party library to obtain a backward incompatible change set.

Analyzing the source code or binary file of the software to be detected, and preprocessing the backward incompatible change set according to the analysis result.

Detecting the preprocessed backward incompatible change set according to the source code or binary file of the software to be detected, determining the use condition of elements changed in the backward incompatible change in the software to be detected and the backward incompatible library version, and reporting the dependency defect;

And carrying out global detection on all library versions of the third-party library according to the backward incompatibility change to obtain all incompatible library versions incompatible with the software to be detected.

And automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions.

A software dependent range automatic inference apparatus, the apparatus comprising:

The backward incompatible change acquisition module is used for acquiring a plurality of backward incompatible changes of the third party library to obtain a backward incompatible change set.

The backward incompatible version detection module is used for analyzing the source code or binary file of the software to be detected and preprocessing a backward incompatible change set according to an analysis result; detecting the preprocessed backward incompatible change set according to the source code or binary file of the software to be detected, determining the use condition of elements changed in the backward incompatible change in the software to be detected and the backward incompatible library version, and reporting the dependency defect;

and the incompatible library version determining module is used for carrying out global detection on all library versions of the third-party library according to the backward incompatible change to obtain all incompatible library versions incompatible with the software to be detected.

And the correct dependency range determining module is used for automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions.

In one embodiment, the backward incompatible change acquisition module is further configured to collect, with all versions of the third party library as input, a set of backward incompatible changes using the ABI compliance detector, the set of backward incompatible changes being: BICS (v _pre,v_next); all versions of the third party library are source code or binary files; when the third party library includes N versions, all backward incompatible changes collected are aggregated as: expressing each backward incompatible change instance in the backward incompatible change set by using triples to obtain a backward incompatible change triplet set of each library; the triplet of backward incompatible change instances bics is: < library name, version before and after change, change content >; the triples of each set of backward incompatible change triples are { < library name, version 1 before and after change, content 1>, < library name, version 2 before and after change, content 2>, … … < library name, version M before and after change, content M > }, where M is the number of backward incompatible changes per library, and M is an integer greater than 0.

A computer device comprising a memory storing a computer program and a processor implementing the steps of any of the methods described above when the processor executes the computer program.

A computer readable memory having stored thereon a computer program which when executed by a processor performs the steps of any of the methods described above.

The software dependency range automatic inference method, apparatus, computer device and memory. The method comprises the following steps: acquiring a plurality of backward incompatible changes of a third party library, analyzing source codes or binary files of software to be detected, and preprocessing a backward incompatible change set according to analysis results; detecting the preprocessed backward incompatible change set according to the source code or binary file of the software to be detected, determining the use condition of elements changed in the backward incompatible change in the software to be detected and the backward incompatible library version, and reporting the dependency defect; global detection is carried out on all library versions of the third-party library according to the backward incompatibility change, and all incompatible library versions incompatible with the software to be detected are obtained; and automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions. Based on source codes and binary analysis, the method has the advantages that the method is more accurate and efficient in detecting the incompatible library version, and lower in false alarm rate, so that the inferred dependence range is more accurate, and the method can help an end user to avoid using the incompatible library version from the beginning, so that the occurrence of compatibility errors is avoided.

Drawings

FIG. 1 is a flow diagram of a method for automatically inferring software dependent ranges in one embodiment;

FIG. 2 is a flow chart of a software dependent range auto-inference method according to another embodiment;

FIG. 3 is a block diagram of an embodiment of a software dependent range auto-inference apparatus;

Fig. 4 is an internal structural diagram of a computer device in one embodiment.

Detailed Description

The present application will be described in further detail with reference to the drawings and examples, in order to make the objects, technical solutions and advantages of the present application more apparent. It should be understood that the specific embodiments described herein are for purposes of illustration only and are not intended to limit the scope of the application.

The present invention is primarily concerned with bin dependent defect detection at the source code and binary level that undermines backward compatibility. Backward compatibility includes: 1) The backward binary compatibility (i.e., application binary interface (Application Binary Interface, ABI) compatibility) allows old programs compiled using the old version library to run using the new version without recompilation, which allows a user to easily upgrade to the new version of the software library; 2) Backward source code compatibility (i.e., API compatibility) allows old programs to be successfully recompiled using newer versions of libraries.

In one embodiment, as shown in FIG. 1, a software dependent range automatic inference method is provided, comprising the steps of:

step 100: and acquiring a plurality of backward incompatible changes of the third party library to obtain a backward incompatible change set.

Specifically, all versions of each third party library comp are taken as input, and an incompatible change set BICS for breaking backward compatibility of two adjacent versions in the evolution history is collected. Each version of the third party library may be in source code form or binary form with debug symbols.

Binary incompatibilities may result in applications built using the old version library crashing or behaving incorrectly when running on the new version. Source incompatibilities may result in recompilation errors using new library versions.

The method only pays attention to backward incompatibility (whether forward incompatibility or combination of the forward incompatibility and the backward incompatibility), and can avoid the occurrence of software compatibility errors.

Step 102: analyzing the source code or binary file of the software to be detected, and preprocessing the backward incompatible change set according to the analysis result. Preprocessing is used to exclude backward incompatible changes in the set of backward incompatible changes that have no relationship to the source code or binary file of the software to be detected.

Specifically, the pretreatment is mainly to exclude two cases: the first is to exclude the case where the dependency version range does not include library versions where backward incompatibilities occur, e.g., software specifies dependency library glib > = 2.37.6, but the backward incompatibilities change from version glib-2.37.0 to version glib-2.37.3; the second exclusion is the case where the software does not use elements that change in the backward incompatibility change, even though the dependency version range contains backward incompatible library versions, e.g., the backward incompatibility change deletes a parameter for a symbol in the library, but the symbol is not used by the software. So the 2 parts are first removed, which is equivalent to first doing a preliminary screening, since backward incompatibility changes of the library do not necessarily lead to compatibility problems for the software.

When a backward incompatibility change occurs to an old library version (e.g., the interface is deleted), a software developer develops software based on the old library version, and an end user links the software to a new library version at run-time, at which point the new version of the library is incompatible with the software. The backward incompatible changes of the library do not necessarily cause a compatibility error in the software, and the use condition of the changed element in each backward incompatible change instance bics in the software sw to be detected is first analyzed, and whether v _next is incompatible with the software sw to be detected is detected. If so, it is further determined whether the incompatible version is included in the version range specified by the sw. If so, a software dependent defect is reported. A common application scenario is to detect dependency defects in a software code repository, such as taking the entire software repository of apt as input, and to detect if each piece of software in the repository has a dependency defect due to bics. Since a software warehouse may include thousands of software packages, analyzing each software package one by one is time and labor consuming. Thus, preprocessing is performed prior to detecting the backward incompatible library version.

First, the case where the dependency version range does not include bics occurring library versions is excluded. For example, sw specifies dependency glib > = 2.37.6, but bics is the change that occurs from version glib-2.37.0 to version glib-2.37.3.

Step 104: detecting the preprocessed backward incompatible change set according to the source code or binary file of the software to be detected, determining the use condition of elements changed in the backward incompatible change in the software to be detected and the backward incompatible library version, and reporting the dependency defect;

Specifically, the use of the element changed in bics in sw is analyzed and it is detected whether v _next is incompatible with sw. If bics breaks backward compatibility and the use of the corresponding element in sw meets the definition in v _pre, then v _next is considered an incompatible version.

For each backward incompatibility change, comparing the use of the API in the software to be detected with the definition of the API in the new and old library versions, and detecting the library version incompatible with the software to be detected. When the library breaks backward compatibility and the software's API uses an API definition that matches the old version, then the new version of the library is not compatible with the software to be tested, reporting a dependency defect.

The invention works at binary and source code levels, detects compatibility between software and third party libraries, unlike the use of APIs by compilers from source code level analysis software. Because the end user usually installs the binary file directly (for example, installs the binary software by using the command aptinstall or yuminstall) instead of selecting the source code compiling and installing software when installing the software, the user pays more attention to the compatibility of the two-level system, but the compatibility of the source code level cannot guarantee the compatibility of the binary level, and the detection of the incompatible library version is more accurate and efficient based on the source code and the binary analysis, the false alarm rate is lower, and the inference of the dependency range is more accurate.

Step 106: and carrying out global detection on all library versions of the third-party library according to the backward incompatibility change to obtain all incompatible library versions incompatible with the software to be detected.

In particular, comparing the old library version with all other library versions, any other version that is backward incompatible with this old library version will likewise be marked as an incompatible version, i.e., all incompatible versions are available.

Step 108: and automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions.

Specifically, the correct dependency range of the software is automatically deduced, so that the user can be helped to select the correct library version, and compatibility errors are prevented.

The invention can avoid the occurrence of software compatibility errors at the beginning. Compared to the "EFFICIENT STATIC CHECKING of Library Updates (efficient static check of library updates)" work published by Darius Foo et al at FSE2018, which focuses mainly on detecting changes in third party libraries, the "CiD: automating the Detection of API-Related Compatibility Issues in Android Apps (CiD: auto-detection of API related compatibility problems in android applications)" work published by Li et al at ISSTA2018, which focuses mainly on detecting the use of incompatible apis by software, the "API-Evolution Support with Diff-CatchUp (supporting API evolution using diff-CatchUp)" work published by Zhenchang Xing et al at TSE2007, which focuses mainly on how to assist software in adapting to library changes, the present invention can help end users avoid using incompatible library versions from the beginning, thereby avoiding occurrence of compatibility errors, whereas the above-mentioned existing research works are unable to automatically assist users in selecting compatible library versions, deducing dependency ranges.

In the above-mentioned software dependency range automatic inference method, the method includes: acquiring a plurality of backward incompatible changes of a third party library, analyzing source codes or binary files of software to be detected, and preprocessing a backward incompatible change set according to analysis results; detecting the preprocessed backward incompatible change set according to the source code or binary file of the software to be detected, determining the use condition of elements changed in the backward incompatible change in the software to be detected and the backward incompatible library version, and reporting the dependency defect; global detection is carried out on all library versions of the third-party library according to the backward incompatibility change, and all incompatible library versions incompatible with the software to be detected are obtained; and automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions. Based on source codes and binary analysis, the method has the advantages that the method is more accurate and efficient in detecting the incompatible library version, and lower in false alarm rate, so that the inferred dependence range is more accurate, and the method can help an end user to avoid using the incompatible library version from the beginning, so that the occurrence of compatibility errors is avoided.

In one embodiment, step 100 comprises: taking all versions of the third party library as input, collecting a set of backward incompatible changes with an ABI compliance detector, the set of backward incompatible changes being: BICS (v _pre,v_next); all versions of the third party library are source code or binary files; when the third party library includes N versions, all backward incompatible changes collected are aggregated as: expressing each backward incompatible change instance in the backward incompatible change set by using triples to obtain a backward incompatible change triplet set of each library; the triplet for backward incompatible change instance bics is: < library name, version before and after change, change content > (e.g., < glib (library name), <2.39.1,2.39.2> (version before and after change), g_hash_table_play delete gboolean type return value (change content) >); the triples of each set of backward incompatible change triples are { < library name, version 1 before and after change, content 1>, < library name, version 2 before and after change, content 2>, … … < library name, version M before and after change, content M > }, where M is the number of backward incompatible changes per library, and M is an integer greater than 0. The backward incompatible change triplet set is obtained by representing each element in the backward incompatible change triplet set by a triplet. The backward incompatible change triplet set includes a plurality of triples such as: { < glib, <2.39.1,2.39.2>, g_hash_table_replace delete gboolean type return value >, < glib, <2.39.7,2.39.9>, g_hash_table_insert delete gboolean type return value >, < glib, <2.40.1,2.42.1>, g_hash_table_delete delete gboolean type return value > }.

Specifically, the ABI compliance detector (ABI Compliance Checker, abbreviated as ABICC) is a tool for checking backward binary and source code level compatibility of C/c++ software libraries, which can detect changes in libraries that break backward compatibility, for checking backward binary and source code level compatibility between C/c++ software libraries and libraries, and analyzing changes in API/ABI (abi=api+compiler ABI) that may break binary and source compatibility: changes to the call stack, changes to the virtual function table (v-table), deleted symbols, renamed fields, etc., create and compare ABI dumps for header files and shared objects of the library. The ABI compliance detector is suitable for use by software library developers and Linux maintenance personnel interested in ensuring backward compatibility, i.e. allowing old applications to run or recompile with newer library versions.

Assuming that a given third party library is from version v _pre to version v _next, the set of backward incompatible changes is BICS (v _pre,v_next),BICS(v_pre,v_next) representing the set of backward incompatible changes from version v _pre to version v _next (Backward Incompatible CHANGE SET, abbreviated: BICS).

When the user cannot provide the binary file with the debugging symbol, the source code can be used as input, and the provided built-in compiling script can be used for self-compiling the binary file with the debugging symbol. At self-compiling, only default compiling options are used, while custom compiling options provided by a user are received. Collecting BICS (v _pre,v_next) using ABICC tools, when the input library contains N versions, collecting all backward incompatible change instances of the current library each backward incompatible change instance BICS is a triplet: < library name, version before and after change, change content >. The final result is a set of backward incompatible change triples for each library { < library name, version before and after change, change content > … … }.

In one embodiment, step 102 specifically includes the steps of:

Step 200: all dependencies of the software to be detected are analyzed, and libraries of the software to be detected and version ranges of each library are extracted.

Specifically, all dependencies of the software sw to be detected (dependency description files defined in the software package, such as control files in the DEB package, or spec files in the RPM package) are analyzed, and libraries on which the software sw to be detected depends and version ranges of each library are extracted.

Step 202: reporting that there is no dependency defect and exiting when the library with the backward incompatible change is not dependent on the software to be detected and/or when the version with the backward incompatible change is not included in the version range on which the software to be detected depends;

Specifically, it is detected whether the library in which bics occurs is dependent on the software sw to be detected, and whether the version v _next in which bics occurs is included in the version range in which the sw depends; when either of the above two conditions is not satisfied, bics cannot have any effect on sw, so reporting is not dependent on the defect and exiting.

Step 204: when the sign of the change in the backward incompatible change is not used in the software to be detected, or when the data type of the change in the backward incompatible change is not used in the software to be detected, no dependency defect is reported and exited.

Specifically, this step is used to exclude the case where no element changed in bics is used in the software sw to be detected. For example, bics deletes a parameter for a symbol in the library, but this symbol is not used by sw. The elements that vary in bics can generally be divided into two cases: change symbols (e.g., from bar (node a) to bar ()) and change data types (e.g., from struct node { long l; } to struct node { int i; }). The binary file contained in sw is analyzed. The method specifically comprises the following steps:

(1) When bics changes by one symbol, readelf tool is used to detect if one binary file in sw uses the changed symbol in bics.

(2) When bics changes a data type, all symbols in the collection library using the data type are detected, and whether any binary file in the software package uses any symbol is detected.

(3) If so, this means bics may affect sw and cause compatibility errors in sw. Otherwise, the analysis is stopped and no dependent defects are reported.

In one embodiment, step 104 includes: making corresponding detection rules for each type of binary backward incompatible change and source code backward incompatible change in the C/C++ library; binary backward incompatible changes include: data type change, sign change, and constant change; the source code backward incompatibility change includes: data type changes and sign changes; taking a binary file or source code which is input as software to be detected as input, adopting a corresponding detection rule according to the type of change in the backward incompatible change, and determining the use condition of elements changed in the backward incompatible change in the software to be detected; if the backward incompatibility changes break the backward compatibility and the use of the corresponding element changed in the backward incompatibility changes in the software to be tested complies with the definition in version v _pre, version v _nest is a backward incompatibility library version and the dependency defect is reported.

Specifically, the detection stage of the backward incompatible library version specifically includes:

(1) And using a binary file with debugging information of the software sw to be detected as an input. When bics changes by a symbol, extracting the corresponding symbol signature from the binary file; when bics changes a data type, the corresponding data type definition is extracted from the binary file. Reference https:// lvc. Github. Io/abi-complex-checker/enumerate possible binary backward incompatible changes in the C/c++ library and formulate corresponding incompatible version detection rules for each change, as shown in table 1.

Table 1 detects binary compatibility problems

The library changes are classified into 21 different types, including data type changes, sign changes, constant changes. The specific detection method comprises the following steps:

1) For data type changes (classes 1-13), it is necessary to confirm that the changed element is used by the software sw to be detected;

2) For sign changes (classes 14-20), the elements that have been confirmed to change in the preprocessing stage are used by the software sw to be detected;

3) For constant changes (class 21), it is also necessary to confirm that the changed element is used by the software sw to be detected;

(2) If the user cannot provide the binary file with the debugging information, the service condition of the relevant element can be extracted from the source codes of the software sw to be detected. For example, when analyzing a software warehouse, most software does not issue a binary file with debug information, and the source code of the software sw to be detected can be downloaded and analyzed. When the software sw source code to be detected is used as input, it is difficult to extract the relevant symbol signature or data type definition because the header file of the relevant library cannot be obtained. Different rules need to be adopted for different bics types to detect incompatible versions. For example, when bics deletes a domain in a structure, it is necessary to detect whether the deleted domain is used in sw; when bics changes a function return value from non-void to void, it is necessary to detect whether the return value is used in the sw source code. To address this problem, possible source backward incompatible changes in the C/C++ software library are also enumerated, and corresponding incompatible version detection rules are formulated for each change. The software source code is analyzed using srcML tools. Because the source code of sw lacks the header file of the library and therefore cannot be compiled, srcML can perform lexical analysis and syntax analysis on the uncompiled code segments. The enumerated results and corresponding incompatible version detection rules are shown in table 2.

Table 2 detects source code compatibility issues

The library changes are divided into 12 different types, including data type changes, sign changes. The specific method comprises the following steps:

1) For data type changes (classes 1-6), it is necessary to confirm that the changed element is used by sw;

2) For sign changes (classes 7-12), the elements that have been confirmed to change in the preprocessing stage are used by sw;

(3) Finally returning to a two-tuple: < v _pre,v_next >. bics is incompatible with the sw and is contained by the specified version range of the sw, vnext returns the version number of the new version, otherwise v _next returns-1.

In one embodiment, a binary file or source code input as software to be detected is used as input, corresponding detection rules are adopted according to the type of change in the backward incompatible change, the use condition of elements changed in the backward incompatible change in the software to be detected is determined, and in the step, if the input is the source code of the software to be detected, a srcML tool is used for lexical analysis and grammar analysis of the source code of the software to be detected.

In one embodiment, step 106 includes: detecting the compatibility of the changed elements in the backward incompatibility change in all versions of the third party library to obtain all incompatible versions of the detected software; the judging principle of the incompatible version is as follows: according to whether the definition of the element changed in the backward incompatibility change in any version is backward incompatible with the definition of the element changed in the backward incompatibility change in the original version where the change occurs, if so, the version is an incompatible version of the software to be detected; based on all versions of the third party library and all incompatible versions of the software being tested, boolean variables isIV (v _i) are set, and the expression of Boolean variables isIV (v _i) is:

Wherein isIV (v _i) represents whether version v _i is an incompatible version, v _i is an ith version of the third party library, i is an integer greater than 0 and less than or equal to N, N is the number of versions included in the third party library, bbc (v _pre,v_i, obj) is boolean type in the sense that whether the element changed in the backward incompatibility change breaks backward compatibility from v _pre to v _i, if yes, 1 is returned, otherwise 0 is returned;

All versions of the Boolean variable isIV (v _i) of the third party library are formed into a Boolean list ISIV; the boolean list ISIV is:

ISIV＝[isIV(v₁),isIV(v₂),…,isIV(v_N) ] (2)

Wherein isIV (v _i) represents whether version v _i is a boolean variable of an incompatible version, if isIV (v _i) is 1 and version v _i is included in the version range specified by the software to be tested, version v _i is an incompatible version;

Reporting an incompatible library version set for each backward incompatible change according to the Boolean value list ISIV, the software to be detected and the third party library to obtain an incompatible version between the software to be detected and the third party library.

It should be understood that, although the steps in the flowchart of fig. 1 are shown in sequence as indicated by the arrows, the steps are not necessarily performed in sequence as indicated by the arrows. The steps are not strictly limited to the order of execution unless explicitly recited herein, and the steps may be executed in other orders. Moreover, at least some of the steps in fig. 1 may include multiple sub-steps or stages that are not necessarily performed at the same time, but may be performed at different times, nor do the order in which the sub-steps or stages are performed necessarily performed in sequence, but may be performed alternately or alternately with at least a portion of other steps or sub-steps of other steps.

In a specific embodiment, as shown in FIG. 2, a software warehouse of Ubuntu-19.10 is provided for evaluating the effectiveness of the present invention in preventing compatibility errors. In existing dependency management systems, the apt can automatically resolve the software dependencies, while most other systems require manual input by a developer. Thus, the apt was used as an existing tool, and Ubuntu-19.10 (using apt management software) software warehouse was used to evaluate the effectiveness of preventing compatibility errors.

In a first step, backward incompatible changes for a third party library are collected. For example, taking the target library zlib, qtbase, alsa as input, the set of backward incompatible changes BICS in its evolution history is collected. Existing tools ABI Compliance Checker (ABICC) can detect changes in libraries that break backward compatibility, examine backward binary and source code level compatibility between C/c++ software libraries and libraries, analyze changes in API/ABI (abi=api+compiler ABI) that may break binary and source compatibility: changes to the call stack, changes to the virtual function table (v-table), deleted symbols, renamed fields, etc., create and compare ABI dumps for header files and shared objects of the library. Binary incompatibilities may result in applications built using the old version library crashing or behaving incorrectly when running on the new version. Source incompatibilities may result in recompilation errors using new library versions. The tool is suitable for software library developers and Linux maintainers interested in ensuring backward compatibility, i.e. allowing old applications to run or recompile with newer library versions. Assuming that a given library is from version v _pre to version v _next, a set of backward incompatible changes is BISC (v _pre,v_next),BICS(v_pre,v_next) representing a set of backward incompatible changes from version v _pre to version v _next (BICS: backward Incompatible CHANGE SET). For each library version, all versions of the library are required as inputs. Each version may be in source code form or binary form with debug symbols. When the user cannot provide the binary file with the debugging symbol, the source code can be used as input, and the provided built-in compiling script can be used for self-compiling the binary file with the debugging symbol. At self-compiling, only default compiling options are used, while custom compiling options provided by a user are received. We compile zlib, qtbase, alsa library binary files with debug symbols using default compilation options, collect library zlib, qtbase, alsa library BICS using ABICC tool (v _pre,v_next). When the input library contains N versions, collecting all backward incompatible change sets for the current library each backward incompatible change instance bics is a triplet: < library name, version before and after change, change content >. The final backward incompatible change set of the zlib library is { < zlib,1.2.5.1,1.2.5.2, gzflag >, < zlib,1.2.6.1,1.2.7, get_crc_table > … … }; the set of backward incompatible changes for qtbase libraries is the set of backward incompatible changes for {<qtbase,5.10.0,5.10.1,_ZN13QEglFSContext11runGLChecksEv>,<qtbase,5.13.2,5.14.0,_Z32qt_register_signal_spy_callbacksRK21QSignalSpyCallbackSet@@Qt_5>……};alsa libraries {<alsa,1.1.5,1.1.6,alsa_lisp_result_free@@ALSA_0.9.7>,<alsa,1.1.9,1.2.1,snd_tplg_new@@ALSA_0.9>……};

And secondly, detecting backward incompatible library versions based on source codes and binary analysis, and reporting dependent defects. When a backward incompatibility change (e.g., a delete interface) occurs to an old library, a software developer develops software based on the old library version, and an end user links the software to a new library version at run-time, at which point the new version of the library is incompatible with the software. Backward incompatible changes to the library do not necessarily result in software compatibility errors, analyze the usage of the changed elements in each backward incompatible change instance bics in the software sw, and detect if v _next is incompatible with sw. If so, it is further determined whether the incompatible version is included in the version range specified by the sw. If so, a software dependent defect is reported. A common application scenario is to detect dependency defects in a software code repository, such as taking the entire software repository of apt as input, and to detect if each piece of software in the repository has a dependency defect due to bics. Since a software warehouse may include thousands of software packages, analyzing each software package one by one is time and labor consuming. The detection process is thus divided into two phases: a pretreatment stage and a detection stage. Each backward incompatible change instance of library zlib is specifically analyzed for its use in software unalz _0.65-7 (library dependent range zlib1g > =1.1.4). Use of each backward incompatible change instance of library qtbase in software gammaray _2.9.0 (library dependency range libqt5core5a > = 5.12.2); use of each backward incompatible change instance of library alsa in software alsa-utils _1.1.9 (library dependency range libasound2> = 1.1.1). The method comprises the following steps:

2.1 pretreatment stage. First, the case where the dependency version range does not include bics occurring library versions is excluded. For example, sw specifies dependency glib > = 2.37.6, but bics is the change that occurs from version glib-2.37.0 to version glib-2.37.3. The specific method comprises the following steps:

2.1.1 analyzing all dependencies of unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 (dependency description files defined in the software package, such as control files in the DEB package, or. Spec files in the RPM package), extracting unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 dependent libraries and version ranges for each library;

2.1.2 checking if the pool in which bics occurred is dependent on unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9, while version vnext in which bics occurred is contained in the version range in which unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 depends;

2.1.3 when either of the above two conditions is not met bics cannot have any effect on unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9, thus reporting no dependent defects and exiting;

2.1.4 excludes cases where no element of the change in bics is used in software unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9. For example, bics deletes a parameter for a symbol in the library, but this symbol is not used by sw. The elements that vary in bics can generally be divided into two cases: change symbols (e.g., from bar (node a) to bar ()) and change data types (e.g., from struct node { long l; } to struct node { int i; }). The binary files contained in unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 are analyzed. The specific method comprises the following steps:

2.1.4.1 when bics changes by one symbol, readelf tools are used to detect if one binary file in unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 uses the changed symbol in bics;

2.1.4.2 when bics changes a data type, all symbols in the collection library using the data type are detected, and whether any binary file in the software packages unalz _0.65-7, gammaray _2.9.0 and alsa-utils _1.1.9 uses any symbol;

2.1.4.3 if so, it means that bics may affect unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 and thus cause compatibility errors. Otherwise, stopping analysis and reporting that there is no dependency defect;

2.2 detection phase. The use of the elements varied in bics in unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 was analyzed and it was checked whether vnext was incompatible with unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9. Vnext is considered an incompatible version if bics breaks backward compatibility and the use of the corresponding element in unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 meets the definition in vpre.

2.2.1 Binary files with debug information unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 are used as input. When bics changes by a symbol, extracting the corresponding symbol signature from the binary file; when bics changes a data type, the corresponding data type definition is extracted from the binary file. Reference https:// lvc. Github. Io/abi-complex-checker/enumerate possible binary incompatible changes in the C/c++ library and formulate corresponding incompatible version detection rules for each change, as shown in table 1. The library changes are classified into 21 different types, including data type changes, sign changes, constant changes. The specific detection method comprises the following steps:

2.2.1.1 for data type changes (class 1-13), the elements that need to confirm the change are used by unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9;

2.2.1.2 for sign changes (classes 14-20), elements that have been confirmed to change in the preprocessing stage are used by unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9;

2.2.1.3 for constant changes (class 21), the elements that also need to confirm the change are used by unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9;

2.2.2 if the user cannot provide the binary file with the debug information, the use cases of the relevant elements can be extracted from unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 source codes. For example, when analyzing a software warehouse, most software does not issue binary files with debug information, so the source code of unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 is automatically downloaded and analyzed. When unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 source codes are used as input, it is difficult to extract the relevant symbol signature or data type definition because the header file of the relevant library is not available. Different rules need to be adopted for different bics types to detect incompatible versions. For example, when bics deletes a domain in one structure, it is necessary to detect whether the deleted domain is used in se; when bics changes a function return value from non-void to void, it is necessary to detect whether the return value is used in the sw source code. To address this problem, possible source incompatible changes in the C/C++ software library are also enumerated, and corresponding incompatible version detection rules are formulated for each change. The software source code is analyzed using srcML (http:// www.srcml.org /) tools. The header files of the source missing libraries unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9 cannot be compiled, while srcML enables lexical and grammatical analysis of non-compilable code segments. The enumerated results and corresponding incompatible version detection rules are shown in table 2. The library changes are divided into 12 different types, including data type changes, sign changes. The specific method comprises the following steps:

2.2.2.1 for data type changes (class 1-6), the elements that need to confirm the change are used by unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9;

2.2.2.2 for sign changes (classes 7-12), elements that have been confirmed to change in the preprocessing stage are used by unalz _0.65-7, gammaray _2.9.0, alsa-utils _1.1.9;

2.2.3 eventually returns a binary group: < vpre, vnext >. bics, when the new version and the sw are incompatible and the version range specified by the sw is included, vnext returns the version number of the new version, otherwise vnext returns-1;

The following table lists some examples of dependency defects. Software unalz _0.65-7 depends on library zlib1g > = 1.1.4. The returned value of zlib1g from version 1.2.6.1 to version 1.2.7get_crc_table function is changed from long to int, and the software uses the returned value of long type, so that 1.2.7 is an incompatible version and reports a dependent defect. Software gammaray _2.9.0 relies on library libqt5core5a > =5.12.2. qtbase changes the parameter type of one symbol qt_register_signal_spy_callbacks () from version 5.13.2 to version 5.14.0, the above software uses the symbols of the previous parameter type, so 5.14.0 reports a dependency defect as an incompatible version. Software alsa-utils _1.1.9 depends on library libasound2> = 1.1.1.ALSA the symbols snd_ tplg _new@alsa_0.9 are deleted from version 1.1.9 to version 1.2.1, which is used by the above software, so that 1.2.1 is an incompatible version reporting a dependency defect. An example of the detection of the dependency defect is shown in table 3.

Table 3 detect dependency defect example

Thirdly, all incompatible library versions are obtained in a global detection-oriented mode, and the software dependency range is automatically deduced. The same element may undergo multiple changes, requiring global detection for all library versions to infer the incompatible version range caused by the backward incompatible changes of the current library to obtain the correct dependency range of the software. Assuming that the last incompatible version is v _incomp, the backward incompatibility change bics may result in multiple versions and sw incompatibilities outside v _incomp. All backward incompatible library versions of the sw that result from bice need to be detected. To achieve this goal, we cannot simply consider versions greater or less than v _incomp as incompatible versions, because the elements changed in bics may undergo multiple modifications. The incompatible library version of software unalz _0.65-7 is zlib1g-1.2.7, the incompatible library version of software gammaray _2.9.0 is libqt5core5a-5.14.0, and the incompatible library version of software alsa-utils _1.1.9 is libasound2-1.2.1. Versions larger or smaller than these libraries in the software dependencies described above cannot simply be made incompatible. The specific method comprises the following steps:

3.1 the element changed in bics is denoted obj. Detecting the compatibility of obj in all versions of comp: for either version v, if the definition for obj in v is backward incompatible with the definition for obj in v _pre, then v is also considered an incompatible version of the software sw to be detected. Assuming comp has N versions, for the boolean type variable isIV (v _i) is calculated, indicating whether v _i is an incompatible version: of/> where bbc (v _pre,v_i, obj) is also of boolean type, meaning whether obj breaks backward compatibility from v _pre to v _i (break backward compatibility). If yes, returning to 1, otherwise, returning to 0;

3.2 outputting a boolean list ISIV, wherein each element represents whether the corresponding version is a backward incompatible version of the software sw to be detected: ISIV = [ isIV (v ₁),isIV(v₂),…,isIV(v_N) ], for each element isIV (v _i) in ISIV, if isIV (v _i) is 1 and v _i is included in the version range specified by the software sw to be detected, vi is marked as an incompatible version. Furthermore, for software that is not managed in the software repository, since the software does not specify a version range, the software may not contain a dependency description file, assuming it accepts all versions of the library;

3.3 for the software to be tested sw and library comp, one incompatible library version set IV _{<comp,sw,bics＞} is reported for each bics, assuming there are a total of M incompatible changes in library comp. Finally, incompatible library versions between the software sw and comp to be detected are output: Wherein bics _i represents the ith backward incompatible change of the library;

And fourthly, obtaining all incompatible library versions, automatically deducing the correct dependency range of the software, avoiding the problem of compatibility errors of the software, and ending the deduction process.

The final inferred software unalz _0.65-7 incompatible library version range is [1.2.7, v _last ], the dependency range is [1.1.4,1.2.6.1]; software gammaray _2.9.0 incompatible library version range [5.14.0, v _last ], dependency range [5.12.2,5.13.2]; software alsa-utils _1.1.9 incompatible library version range [1.2.1, v _last ], dependency range [1.1.1,1.1.9]. v _last denotes the largest library version that owns the same soname. An example of the inferred dependency range is shown in Table 4.

Table 4 infer dependency range example

Software for providing a plurality of applications	Library (dependency range)	Library variant versions	Incompatible versions	Correct dependency range
					unalz_0.65-7	zlib1g>＝1.1.4	<1.2.6.1,1.2.7>	[1.2.7,v_last]	[1.1.4，1.2.6.1]
gammaray_2.9.0	libqt5core5a>＝5.12.2	<5.13.2,5.14.0>	[5.14.0,v_last]	[5.12.2，5.13.2]
					alsa-utils_1.1.9	libasound2>＝1.1.1	<1.1.9,1.2.1>	[1.2.1,v_last]	[1.1.1，1.1.9]

In one embodiment, as shown in FIG. 3, there is provided a software dependent range automatic inference apparatus comprising: a backward incompatible change acquisition module, a backward incompatible version detection module, an incompatible library version determination module, and a software correct dependency range determination module, wherein:

The backward incompatible change acquisition module is used for acquiring a plurality of backward incompatible changes of the third party library to obtain a backward incompatible change set;

The incompatible library version determining module is used for carrying out global detection on all library versions of the third-party library according to backward incompatible changes to obtain all incompatible library versions incompatible with the software to be detected;

In one embodiment, the backward incompatible change acquisition module is further configured to collect, with all versions of the third party library as input, a set of backward incompatible changes using the ABI compliance detector, the set of backward incompatible changes being: BICS (v _pre,v_next); all versions of the third party library are source code or binary files; when the third party library includes N versions, all backward incompatible changes collected are aggregated as: expressing each backward incompatible change instance in the backward incompatible change set by using triples to obtain a backward incompatible change triplet set of each library; the triplet for backward incompatible change instance bics is: < library name, version before and after change, change content >; the triples of each set of backward incompatible change triples are { < library name, version 1 before and after change, content 1>, < library name, version 2 before and after change, content 2>, … … < library name, version M before and after change, content M > }, where M is the number of backward incompatible changes per library, and M is an integer greater than 0.

In one embodiment, the backward incompatible version detection module is further configured to analyze all dependencies of the software to be detected, and extract libraries of the software to be detected and version ranges of each library; reporting that there is no dependency defect and exiting when the library with the backward incompatible change is not dependent on the software to be detected and/or when the version with the backward incompatible change is not included in the version range on which the software to be detected depends; when the sign of the change in the backward incompatible change is not used in the software to be detected, or when the data type of the change in the backward incompatible change is not used in the software to be detected, no dependency defect is reported and exited.

In one embodiment, the backward incompatible version detection module is further configured to formulate a corresponding detection rule for each type of binary backward incompatible change and source code backward incompatible change in the C/c++ library; binary backward incompatible changes include: data type change, sign change, and constant change; the source code backward incompatibility change includes: data type changes and sign changes; taking a binary file or source code which is input as software to be detected as input, adopting a corresponding detection rule according to the type of change in the backward incompatible change, and determining the use condition of elements changed in the backward incompatible change in the software to be detected; if the backward incompatibility changes break the backward compatibility and the use of the corresponding element changed in the backward incompatibility changes in the software to be tested complies with the definition in version v _pre, version v _next is a backward incompatibility library version and the dependency defect is reported.

In one embodiment, in the backward incompatible version detection module, if the input is the source code of the software to be detected, a srcML tool is used to perform lexical analysis and syntax analysis on the source code of the software to be detected.

In one embodiment, the incompatible library version determining module is further configured to detect compatibility of elements changed in the backward incompatible change in all versions of the third party library, to obtain all incompatible versions of the detected software; the judging principle of the incompatible version is as follows: according to whether the definition of the element changed in the backward incompatibility change in any version is backward incompatible with the definition of the element changed in the backward incompatibility change in the original version where the change occurs, if so, the version is an incompatible version of the software to be detected; based on all versions of the third party library and all incompatible versions of the software tested, boolean variables isIV (v _i) are set, boolean variables isIV (v _i has the expression:

ISIV＝[isIV(v₁),isIV(v₂),…,isIV(v_N)]

Wherein isIV (v _i) represents whether version v _i is a boolean variable of an incompatible version, and if isIV (v _i) is 1 and version v _i is included in the version range specified by the software to be tested, version vi is an incompatible version;

Specific limitations regarding the software dependency range automatic inference apparatus may be found in the above limitations regarding the software dependency range automatic inference method, and will not be described in detail herein. The respective modules in the above-described software dependency range automatic inference apparatus may be implemented in whole or in part by software, hardware, or a combination thereof. The above modules may be embedded in hardware or may be independent of a processor in the computer device, or may be stored in software in a memory in the computer device, so that the processor may call and execute operations corresponding to the above modules.

In one embodiment, a computer device is provided, which may be a terminal, and the internal structure of which may be as shown in fig. 4. The computer device includes a processor, a memory, a network interface, a display screen, and an input device connected by a system bus. Wherein the processor of the computer device is configured to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system and a computer program. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface of the computer device is used for communicating with an external terminal through a network connection. The computer program is executed by a processor to implement a software dependent range automatic inference method. The display screen of the computer equipment can be a liquid crystal display screen or an electronic ink display screen, and the input device of the computer equipment can be a touch layer covered on the display screen, can also be keys, a track ball or a touch pad arranged on the shell of the computer equipment, and can also be an external keyboard, a touch pad or a mouse and the like.

It will be appreciated by persons skilled in the art that the architecture shown in fig. 4 is merely a block diagram of some of the architecture relevant to the present inventive arrangements and is not limiting as to the computer device to which the present inventive arrangements are applicable, and that a particular computer device may include more or fewer components than shown, or may combine some of the components, or have a different arrangement of components.

In an embodiment a computer device is provided comprising a memory storing a computer program and a processor implementing the steps of the method embodiments described above when the computer program is executed.

In one embodiment, a computer readable memory is provided, on which a computer program is stored which, when executed by a processor, implements the steps of the method embodiments described above.

Those skilled in the art will appreciate that implementing all or part of the above described methods may be accomplished by way of a computer program stored in a non-volatile computer readable memory, which when executed, may comprise the steps of the embodiments of the methods described above. Any reference to memory, storage, database, or other medium used in embodiments provided herein may include non-volatile and/or volatile memory. The nonvolatile memory can include Read Only Memory (ROM), programmable ROM (PROM), electrically Programmable ROM (EPROM), electrically Erasable Programmable ROM (EEPROM), or flash memory. Volatile memory can include Random Access Memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in a variety of forms such as Static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), double Data Rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link (SYNCHLINK) DRAM (SLDRAM), memory bus (rambus) direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), among others.

The technical features of the above embodiments may be arbitrarily combined, and all possible combinations of the technical features in the above embodiments are not described for brevity of description, however, as long as there is no contradiction between the combinations of the technical features, they should be considered as the scope of the description.

The above examples illustrate only a few embodiments of the application, which are described in detail and are not to be construed as limiting the scope of the application. It should be noted that it will be apparent to those skilled in the art that several variations and modifications can be made without departing from the spirit of the application, which are all within the scope of the application. Accordingly, the scope of protection of the present application is to be determined by the appended claims.

Claims

1. A method for automatically inferring a software dependent range, the method comprising:

Acquiring a plurality of backward incompatible changes of a third party library to obtain a backward incompatible change set;

analyzing a source code or a binary file of the software to be detected, and preprocessing a backward incompatible change set according to an analysis result; the preprocessing is used for eliminating backward incompatible changes which have no relation with the source codes or binary files of the software to be detected in the backward incompatible change set;

Global detection is carried out on all library versions of the third-party library according to the backward incompatibility change, and all incompatible library versions incompatible with the software to be detected are obtained;

Automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions;

Detecting the preprocessed backward incompatible change set according to the source code or binary file of the software to be detected, determining the use condition of elements changed in the backward incompatible change in the software to be detected and the backward incompatible library version, and reporting the dependency defect, wherein the method comprises the following steps:

Making corresponding detection rules for each type of binary backward incompatible change and source code backward incompatible change in the C/C++ library; binary backward incompatible changes include: for data type changes, sign changes, and constant changes; wherein the detection rules of the structure and the class of the data type change in the binary backward incompatibility change comprise: the method comprises the steps of using a field detection rule for the type of incompatible change of an added/deleted field of a structure body and a class, using a field detection rule for the type of incompatible change of a size change, using a field comparison sequence detection rule for the type of incompatible change of a field sequence change, and using a field and a detection rule for the type of matching field for the type of incompatible change of the field type; the detection rules for the class incompatibility change type of the data type change in the binary backward incompatibility change include: the method comprises the steps of using a virtual function detection rule for an incompatibility change type of adding/deleting a virtual function, using a detection rule for comparing the position of the virtual function for the incompatibility change type of changing the position of the virtual function, using a virtual function detection rule for an incompatibility change type of rewriting the virtual function, and using a base class detection rule for an incompatibility change type of adding/deleting a base class; the detection rules for the complex incompatible change types for data type changes in the binary backward incompatible changes include: a detection rule using a field for an incompatible change type of an add/delete field, a field detection rule for an incompatible change type of a change in size, a field for an incompatible change type of a change in field type, and a detection rule matching a field type; the detection rules for enumerating incompatible change types for data type changes in binary backward incompatible changes include: a member detection rule is used for both member value changes and incompatible change types of deleted/renamed members; the incompatible change detection rules for sign changes in binary backward incompatible changes include: a symbol detection rule is used for incompatible change types of deleted symbols, incorrect version changes of symbol changes, and attribute changes, a parameter detection rule is used for incompatible change types of default add/delete parameters, parameter value changes, and rename parameters, and a matching parameter/return value type detection rule is used for incompatible change types of parameter/return value type changes; the incompatibility change detection rule for constant changes in binary backward incompatibility changes includes: constant value detection rules are used for incompatible changes to value changes; the source code backward incompatibility change includes: data type changes and sign changes; the detection rule of the data type change in the backward incompatible change of the source code comprises the following steps: the detection rule for incompatible change types of deletion/renaming fields of structures, classes and complexes is to detect using fields; the detection rule of the incompatible change type for the field type change of the structure, class and association is to detect using the field and matching field types; for the incompatible change type of adding/deleting the base class of the class data type, using the detection rule of the base class; for incompatible change types of access levels of class data type change fields or methods, detecting rules using fields or methods; adding an incompatible change type of a pure virtual method to the class data type, and detecting rules by using the pure virtual method; for incompatible change types that enumerate data types to delete/rename members, member detection rules are used; the symbol changes in the source code backward incompatibility change include: using a detection rule of the symbol for an incompatible change type of the deleted symbol; detection rules for incompatible change model usage parameters for add/delete parameters; adopting a detection rule matching the parameter type for the incompatible change type of the change parameter type; using a parameter detection rule for incompatible change types that delete default parameter values, a matching return value type detection rule for incompatible change types that return value type changes, and a sign detection rule for incompatible change types that attribute changes;

taking a binary file or source code of the software to be detected as input, adopting a corresponding detection rule according to the type of the change in the backward incompatible change, and determining the use condition of the element changed in the backward incompatible change in the software to be detected; the method for determining the use condition of the element changed in the backward incompatibility change in the software to be detected comprises the following specific steps of: for a data type change of a binary backward incompatible change, confirming whether the changed element is used by software to be detected; for a sign change of a binary backward incompatible change, confirming that the element for which the change has been confirmed in the preprocessing stage is used by the software to be detected; for constant changes of binary backward incompatible changes, confirming that the changed elements are used by the software to be detected; the specific steps for determining the use condition of the changed element in the backward incompatibility change in the software to be detected comprise the following steps: for the change of the type of the data of the backward incompatible change of the source code, confirming that the changed element is used by the software to be detected; for the sign change of the backward incompatible change of the source code, confirming that the element which has confirmed the change in the preprocessing stage is used by the software to be detected;

If the backward incompatibility changes break the backward compatibility and the use of the corresponding element changed in the backward incompatibility changes in the software to be detected accords with the definition in the v _pre version, the v _next version is a backward incompatibility library version and the dependency defect is reported; where v _pre is the former version and v _next is the latter version.

2. The method of claim 1, wherein obtaining a number of backward incompatible changes for the third party library to obtain a set of backward incompatible changes comprises:

With all versions of the third party library as input, collecting a set of backward incompatible changes with an ABI compliance detector, the set of backward incompatible changes consisting of a plurality of backward incompatible changes, the backward incompatible changes being: BICS (v _pre,v_next), wherein all versions of the third party library are source code or binary files;

When the third party library includes N versions, all backward incompatible changes collected are aggregated as: wherein i is an integer of greater than 0 and less than or equal to N;

Each backward incompatible change instance in the backward incompatible change set is represented by a triplet, and a backward incompatible change triplet set of each library is obtained; the triplets for the backward incompatible change instance are: < library name, version before and after change, change content >; the triples of each set of backward incompatible change triples are { < library name, version 1 before and after change, content 1>, < library name, version 2 before and after change, content 2>, … … < library name, version M before and after change, content M > }, where M is the number of backward incompatible changes per library, and M is an integer greater than 0.

3. The method of claim 1, wherein analyzing the software to be detected and preprocessing the set of backward incompatible changes based on the analysis results comprises:

analyzing all dependencies of the software to be detected, and extracting libraries of the software to be detected and version ranges of each library;

Reporting that there is no dependency defect and exiting when the library with the backward incompatibility change is not relied on by the software to be detected or when the version with the backward incompatibility change is not included in the version range on which the software to be detected depends;

when the sign of the change in the backward incompatible change is not used in the software to be detected, or when the data type of the change in the backward incompatible change is not used in the software to be detected, no dependency defect is reported and exited.

4. The method according to claim 1, wherein binary files or source codes of the software to be detected are taken as input, corresponding detection rules are adopted according to the types of changes in the backward incompatible changes, and the use condition of elements changed in the backward incompatible changes in the software to be detected is determined, and in the step, if the input is the source codes of the software to be detected, a srcML tool is used for lexical analysis and grammatical analysis of the source codes of the software to be detected.

5. The method of claim 1, wherein globally detecting all library versions of the third party library based on the backward incompatibility change results in all incompatible library versions that are incompatible with the software to be detected, comprising:

Detecting the compatibility of the changed elements in the backward incompatibility change in all versions of the third party library to obtain all incompatible versions of the detected software; the judging principle of the incompatible version is as follows: according to whether the definition of the element changed in the backward incompatibility change in any version is backward incompatible with the definition of the element changed in the backward incompatibility change in the original version where the change occurs, if so, the version is an incompatible version of the software to be detected;

Based on all versions of the third party library and all incompatible versions of the software being tested, boolean variables isIV (v _i) are set, and the expression of Boolean variables isIV (v _i) is:

wherein isIV (v _i) represents whether version v _i is an incompatible version, v _i is an ith version of the third party library, i is an integer greater than 0 and less than or equal to N, N is the number of versions included in the third party library, bbc (v _pre,v_i, obj) is boolean type in the sense that whether the element changed in the backward incompatibility change breaks backward compatibility from v _pre to v _i, if yes, 1 is returned, otherwise 0 is returned; obj is the element changed in the backward incompatible changes;

ISIV＝[isIV(v₁),isIV(v₂),…,isIV(v_N)]

6. A software-dependent range automatic inference apparatus, the apparatus comprising:

The correct dependency range determining module is used for automatically deducing the correct dependency range of the software to be detected according to all incompatible library versions;

The backward incompatible version detection module is also used for making corresponding detection rules for each type of binary backward incompatible change and source code backward incompatible change in the C/C++ library; binary backward incompatible changes include: for data type changes, sign changes, and constant changes; wherein the detection rules of the structure and the class of the data type change in the binary backward incompatibility change comprise: the method comprises the steps of using a field detection rule for the type of incompatible change of an added/deleted field of a structure body and a class, using a field detection rule for the type of incompatible change of a size change, using a field comparison sequence detection rule for the type of incompatible change of a field sequence change, and using a field and a detection rule for the type of matching field for the type of incompatible change of the field type; the detection rules for the class incompatibility change type of the data type change in the binary backward incompatibility change include: the method comprises the steps of using a virtual function detection rule for an incompatibility change type of adding/deleting a virtual function, using a detection rule for comparing the position of the virtual function for the incompatibility change type of changing the position of the virtual function, using a virtual function detection rule for an incompatibility change type of rewriting the virtual function, and using a base class detection rule for an incompatibility change type of adding/deleting a base class; the detection rules for the complex incompatible change types for data type changes in the binary backward incompatible changes include: a detection rule using a field for an incompatible change type of an add/delete field, a field detection rule for an incompatible change type of a change in size, a field for an incompatible change type of a change in field type, and a detection rule matching a field type; the detection rules for enumerating incompatible change types for data type changes in binary backward incompatible changes include: a member detection rule is used for both member value changes and incompatible change types of deleted/renamed members; the incompatible change detection rules for sign changes in binary backward incompatible changes include: a symbol detection rule is used for incompatible change types of deleted symbols, incorrect version changes of symbol changes, and attribute changes, a parameter detection rule is used for incompatible change types of default add/delete parameters, parameter value changes, and rename parameters, and a matching parameter/return value type detection rule is used for incompatible change types of parameter/return value type changes; the incompatibility change detection rule for constant changes in binary backward incompatibility changes includes: constant value detection rules are used for incompatible changes to value changes; the source code backward incompatibility change includes: data type changes and sign changes; the detection rule of the data type change in the backward incompatible change of the source code comprises the following steps: the detection rule for incompatible change types of deletion/renaming fields of structures, classes and complexes is to detect using fields; the detection rule of the incompatible change type for the field type change of the structure, class and association is to detect using the field and matching field types; for the incompatible change type of adding/deleting the base class of the class data type, using the detection rule of the base class; for incompatible change types of access levels of class data type change fields or methods, detecting rules using fields or methods; adding an incompatible change type of a pure virtual method to the class data type, and detecting rules by using the pure virtual method; for incompatible change types that enumerate data types to delete/rename members, member detection rules are used; the symbol changes in the source code backward incompatibility change include: using a detection rule of the symbol for an incompatible change type of the deleted symbol; detection rules for incompatible change model usage parameters for add/delete parameters; adopting a detection rule matching the parameter type for the incompatible change type of the change parameter type; using a parameter detection rule for incompatible change types that delete default parameter values, a matching return value type detection rule for incompatible change types that return value type changes, and a sign detection rule for incompatible change types that attribute changes; taking a binary file or source code of the software to be detected as input, adopting a corresponding detection rule according to the type of the change in the backward incompatible change, and determining the use condition of the element changed in the backward incompatible change in the software to be detected; the method for determining the use condition of the element changed in the backward incompatibility change in the software to be detected comprises the following specific steps of: for a data type change of a binary backward incompatible change, confirming whether the changed element is used by software to be detected; for a sign change of a binary backward incompatible change, confirming that the element for which the change has been confirmed in the preprocessing stage is used by the software to be detected; for constant changes of binary backward incompatible changes, confirming that the changed elements are used by the software to be detected; the specific steps for determining the use condition of the changed element in the backward incompatibility change in the software to be detected comprise the following steps: for the change of the type of the data of the backward incompatible change of the source code, confirming that the changed element is used by the software to be detected; for a sign change of a source code backward incompatible change, the element whose change has been confirmed in the preprocessing stage is confirmed to be used by the software to be detected.

7. The apparatus of claim 6, wherein the backward incompatible change acquisition module is further configured to collect a set of backward incompatible changes using the ABI compliance detector with all versions of the third party library as input, the set of backward incompatible changes being: BICS (v _pre,v_next); all versions of the third party library are source code or binary files; when the third party library includes N versions, all backward incompatible changes collected are aggregated as: Each backward incompatible change instance in the backward incompatible change set is represented by a triplet, and a backward incompatible change triplet set of each library is obtained; the triplet of backward incompatible change instances bics is: < library name, version before and after change, change content >; the triples of each set of backward incompatible change triples are { < library name, version 1 before and after change, content 1>, < library name, version 2 before and after change, content 2>, … … < library name, version M before and after change, content M > }, where M is the number of backward incompatible changes per library, and M is an integer greater than 0.

8. A computer device comprising a memory and a processor, the memory storing a computer program, characterized in that the processor implements the method of any one of claims 1 to 5 when executing the computer program.

9. A computer readable memory, on which a computer program is stored, characterized in that the computer program, when being executed by a processor, implements the method of any of claims 1 to 5.