WO2021249518A1 - 热补丁文件生成、一致性检测方法、装置、设备和介质 - Google Patents

热补丁文件生成、一致性检测方法、装置、设备和介质 Download PDF

Info

Publication number
WO2021249518A1
WO2021249518A1 PCT/CN2021/099526 CN2021099526W WO2021249518A1 WO 2021249518 A1 WO2021249518 A1 WO 2021249518A1 CN 2021099526 W CN2021099526 W CN 2021099526W WO 2021249518 A1 WO2021249518 A1 WO 2021249518A1
Authority
WO
WIPO (PCT)
Prior art keywords
file
dynamic library
main program
thread
source
Prior art date
Application number
PCT/CN2021/099526
Other languages
English (en)
French (fr)
Inventor
唐玉科
Original Assignee
中兴通讯股份有限公司
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 中兴通讯股份有限公司 filed Critical 中兴通讯股份有限公司
Publication of WO2021249518A1 publication Critical patent/WO2021249518A1/zh

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/65—Updates
    • G06F8/658—Incremental updates; Differential updates
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F40/00—Handling natural language data
    • G06F40/10—Text processing
    • G06F40/194—Calculation of difference between files
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/70—Software maintenance or management
    • G06F8/72—Code refactoring

Definitions

  • the embodiments of the present disclosure relate to the technical field of hot patching of linux user mode software written in C/C++ language, and in particular to a hot patch file generation and consistency detection method, device, equipment and medium.
  • hot patching This technology replaces the patched function (faulty function) that is running with the patched function (function that repairs the fault) to achieve the purpose of repairing the fault without restarting the program.
  • the hot patch technology basically uses the instruction at the entrance of the patched function to be modified into a jump instruction that jumps to the entrance of the patch function to achieve the purpose of function replacement.
  • a general program is composed of a main program and a dependent dynamic library
  • the current common practice in the industry is to either specify the attribution information (main program or dynamic library) of the patched function when patching, or to record the attribution information of the patched function in the patch file when making a patch, but whether it is patching
  • the person who made the patch or the person who made the patch is not necessarily a developer, and may not know the attribution information of the patched function, which makes this method not easy to use and error-prone, making the reliability of the hot patch technology low.
  • the main purpose of the embodiments of the present disclosure is to propose a hot patch file generation and consistency detection method, device, equipment, and medium, aiming to solve the problem that the patched function cannot be accurately obtained in the hot patch technology, so that the hot patch technology is Problems with poor ease of use, error-prone, and low reliability.
  • embodiments of the present disclosure provide a method for generating a hot patch file, and the method for generating a hot patch file includes:
  • the second project corresponds to files with differences on the storage node
  • the attribution information of the first target file and the second target file is determined, and the attribution information is based on the first source file name, the second source file name, the first main program source file list, and the The second main program source file list, the first dynamic library source file list, and the second dynamic library source file list are determined, and the attribution information includes any one of the following: attributable to the first dynamic library, attributable to the first dynamic library 2. Dynamic library, belonging to the first main program, and belonging to the second main program;
  • the main program difference function is obtained, and a first intermediate hot patch file is generated.
  • the first intermediate hot patch file includes identification information, the identification information includes the main program identifier, and the main program difference function includes the first main program on the corresponding node. Functions that differ between the first target file of the program and the second target file belonging to the second main program;
  • the dynamic library difference function generate a second intermediate hot patch file, the second intermediate hot patch file includes identification information, the identification information includes a dynamic library identifier, the dynamic library difference function includes the corresponding node attributable to the first dynamic Functions that differ between the first object file of the library and the second object file belonging to the second dynamic library;
  • the embodiments of the present disclosure also propose a consistency detection method, and the consistency detection method includes:
  • each thread of the current process of the source program traces back the current function call chain of each thread in parallel;
  • the consistency check includes determining the thread state of the thread according to the identification information, and the thread state includes a blocked state or continues to run ;
  • the result of the consistency check is determined according to the thread state of each thread.
  • the hot patch file generating device includes:
  • the first acquisition module is configured to acquire the first target file in the first project before modification and the second target file in the second project after modification, where the first target file and the second target file are respectively Files that have differences on the storage nodes corresponding to the first project and the second project;
  • the second obtaining module is configured to obtain the first source file name for generating the first target file and the second source file name for generating the second target file;
  • the third acquisition module is configured to acquire the first main program source file list of the first main program, the first dynamic library source file list of the first dynamic library, the second main program source file list of the second main program, and the second dynamic library.
  • the second dynamic library source file list of the library, the first main program and the first dynamic library belong to the first project, and the second main program and the second dynamic library belong to the second project;
  • the first determining module is configured to determine the attribution information of the first target file and the second target file, and the attribution information is based on the first source file name, the second source file name, and the first source file name.
  • the main program source file list, the second main program source file list, the first dynamic library source file list, and the second dynamic library source file list are determined, and the attribution information includes any one of the following: A dynamic library, belonging to the second dynamic library, belonging to the first main program, and belonging to the second main program;
  • the fourth acquisition module is configured to acquire the difference function of the main program and generate a first intermediate hot patch file, the first intermediate hot patch file includes identification information, the identification information includes the main program identifier, and the main program difference function includes the corresponding The function on the node where there is a difference between the first target file attributable to the first main program and the second target file attributable to the second main program;
  • the fifth obtaining module is configured to obtain the dynamic library difference function and generate a second intermediate hot patch file, the second intermediate hot patch file includes identification information, the identification information includes a dynamic library identifier, and the dynamic library difference function includes a corresponding A function on the node where there is a difference between the first target file attributable to the first dynamic library and the second target file attributable to the second dynamic library;
  • the encapsulation module is configured to encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate a hot patch file.
  • the present disclosure provides a consistency detection device, the consistency detection device comprising:
  • the sixth obtaining module is set to obtain the full path of the hot patch file and the identification information of the patched function
  • the seventh obtaining module is set to obtain the source program call stack information of the source program
  • a parallel backtracking module configured to, according to the source program call stack information, each thread of the current process of the source program parallelly backtrack the current function call chain of each thread itself;
  • the detection module is configured to traverse the thread functions in each layer in the current function call chain to perform consistency detection.
  • the consistency detection includes determining the thread status of the thread according to the identification information, and the thread status includes Blocked state or continue to run;
  • the second determining module is configured to determine the result of the consistency detection according to the thread state of each thread.
  • the present disclosure provides a first device, the first device including a first memory, a first processor, and a device that is stored in the first memory and can run on the first processor.
  • a first program and a first data bus configured to realize the connection and communication between the first processor and the first memory.
  • the present disclosure provides a second device, the second device includes a second memory, a second processor, and a second device that is stored in the second memory and can run on the second processor.
  • a program and a second data bus configured to realize the connection and communication between the second processor and the second memory, when the second program is executed by the second processor, the implementation is as in any one of the above embodiments The steps of the consistency detection method.
  • the present disclosure provides a medium configured as a computer-readable storage, the storage medium stores one or more first programs, and the one or more first programs can be stored by one or more first programs. Executed by a processor to implement the steps of the hot patch file generating method described in any one of the foregoing embodiments;
  • the storage medium stores one or more second programs, and the one or more second programs can be executed by one or more second processors to implement the consistency detection method described in any one of the foregoing embodiments A step of.
  • the hot patch file generation, consistency detection method, device, device and medium proposed in the present disclosure wherein the hot patch file generation method obtains the first target file in the first project before modification and the first target file in the second project after modification.
  • the attribution information is based on the first source file name, the second source file name, the first main program source file list, the second main program source file list, and the first dynamic library source
  • the file list and the source file list of the second dynamic library are determined, and the attribution information includes any one of the following: attributable to the first dynamic library, attributable to the second dynamic library, attributable to the first main program, and attributable to the second main program.
  • the first intermediate hot patch file includes identification information.
  • the identification information includes the main program identifier to identify that the first intermediate hot patch file corresponds to the main program.
  • the main program difference function Including the function of the difference between the first target file belonging to the first main program and the second target file belonging to the second main program on the corresponding node; obtaining the dynamic library difference function, generating the second intermediate hot patch file, and the second intermediate
  • the hot patch file includes identification information.
  • the identification information includes a dynamic library identifier to identify that the second intermediate hot patch file corresponds to a dynamic library.
  • the dynamic library difference function includes the first target file and the attribution of the first dynamic library on the corresponding node. Functions that have differences in the second target file of the second dynamic library; encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate the hot patch file.
  • the attribution information of the first and second target files can be obtained.
  • the attribution information classifies the first and second target files, compares the attribution information as the first and second target files of the first and second main programs, obtains the difference function of the main program, and sets the attribution information as the first and second dynamic library.
  • the first and second target files are compared, the dynamic library difference function is obtained, the first intermediate hot patch file is generated according to the main program difference function, and the main program identifier is recorded in the first intermediate hot patch file, and the first intermediate hot patch file is generated according to the dynamic library difference function.
  • the second intermediate hot patch file, and the dynamic library identification is recorded in the second intermediate hot patch file.
  • the identification information of the patched function is the same as the identification information of the file in which it is located, it can be based on the patch
  • the file where the function is located can further know whether the patched function belongs to the main program or the dynamic library, that is, it is possible to clearly and accurately obtain the information of whether each patched function belongs to the main program or the dynamic library.
  • the operator only needs to specify the hot patch file. Since the identification information of the patch function in the hot patch file is known, the patched function can be accurately obtained, which reduces the main program and dynamic inventory of the source file.
  • FIG. 1 is a flowchart of a method for generating a hot patch file according to Embodiment 1 of the present disclosure
  • FIG. 2 is a flowchart of a specific application example of a method for generating a hot patch file provided by Embodiment 1 of the present disclosure
  • FIG. 3 is a flowchart of a consistency detection method provided in the second embodiment of the present disclosure.
  • FIG. 5 is a structural block diagram of a device for generating a hot patch file provided by the third embodiment of the present disclosure
  • FIG. 6 is a structural block diagram of a consistency detection device provided by the fourth embodiment of the present disclosure.
  • FIG. 7 is a structural block diagram of a first device provided by Embodiment 5 of the present disclosure.
  • FIG. 8 is a structural block diagram of a second device provided by Embodiment 6 of the present disclosure.
  • this embodiment provides a method for generating a hot patch file.
  • the method includes but is not limited to the following steps:
  • Step S10 Obtain the first target file in the first project before modification and the second target file in the second project after modification.
  • the first target file and the second target file are files with differences on the storage nodes corresponding to the first project and the second project, respectively.
  • the second project is based on the first project and is modified according to certain rules, usually, the storage node of each modified file of the second project is the same as each modification in the first project.
  • the storage nodes of the previous files all have a certain corresponding relationship. Therefore, the files with differences on the corresponding storage nodes can be understood as the modified files of the second project after the modification of the pre-modified files of the first project. There is a difference between the content of the file and the modified file. At this time, the file before the modification is the first target file, and the file after the modification is the second target file.
  • the method before obtaining the first target file in the first project before modification and the second target file in the second project after modification, the method further includes:
  • the first target file and the second target file are files with differences in the binary files with the same name in the first project and the second project, respectively.
  • the construction of project P will get a main program and several dependent dynamic libraries.
  • the compilation path in the binary file of the same name in the project directory of P'and the project directory of P is the same, so as to avoid affecting the subsequent patch production due to the different compilation path.
  • the first and second target files include files with differences in the binary files of the first project and the second project with the same name.
  • the two files named X are the first target file of the first project and the second target file of the second project, respectively.
  • obtaining the first and second target files further includes: comparing the project directory of the first project with the project directory of the second project to generate a target file list, and each node in the target file list includes the first target with the same name. The full path name of the file and the second target file.
  • the method for obtaining the first and second target files may be: use the diff tool to compare the respective project directories of the first and second projects to obtain target files of different target files with the same name in the two project directories List O, where each node in the target file list O records the full path name of the first and second target files with the same name.
  • use the diff tool to compare the project directories of projects P'and P, and find files X and X'with the same name that have different file contents under the same path, then X and X'are used as a pair of target files, and the The full path name of the target file pair is recorded in the target file list.
  • Step S11 Obtain the first source file name for generating the first target file and the second source file name for generating the second target file.
  • obtaining the first source file name for generating the first target file and the second source file name for generating the second target file includes:
  • the debugging information of the second target file is parsed to obtain the name of the second source file to be generated.
  • the first and second source file names can be generated by parsing the debugging information of the first and second target files one by one.
  • the debugging information of each first and second target file in the target file list can be parsed to obtain the first and second source files that generated the first and second target files. name.
  • Step S12 Obtain the first main program source file list of the first main program, the first dynamic library source file list of the first dynamic library, the second main program source file list of the second main program, and the second main program source file list of the second dynamic library.
  • the source file list of the dynamic library is obtained by: Obtain the first main program source file list of the first main program, the first dynamic library source file list of the first dynamic library, the second main program source file list of the second main program, and the second main program source file list of the second dynamic library.
  • the first main program and the first dynamic library belong to the first project
  • the second main program and the second dynamic library belong to the second project.
  • the first main program and the first dynamic library can be obtained by obtaining the full path names of the main program and the dynamic library corresponding to the first project.
  • the second main program and the second dynamic library can be obtained by obtaining the full path names of the main program and the dynamic library corresponding to the second project.
  • the compilation path of the binary file with the same name of the first project and the second project are the same.
  • the first and second main programs and the first and second dynamic libraries can be obtained by obtaining the full path names of the main program and the dynamic library respectively corresponding to the first project and the second project from the binary file with the same name.
  • the full path names of the first main program and the first dynamic library corresponding to the first project can be obtained and recorded, and the second The full path name of the second main program and the second dynamic library corresponding to the project.
  • the specific process of obtaining the full path name can be obtained by using related technologies, and will not be repeated here.
  • the dynamic library in the embodiment of the present disclosure is a dynamic library that the main program depends on.
  • the first main program source file list of the first main program, the first dynamic library source file list of the first dynamic library, the second main program source file list of the second main program, and the second dynamic library are acquired.
  • the source file list of the second dynamic library includes:
  • Step S13 Determine the attribution information of the first target file and the second target file.
  • the attribution information is determined according to the first source file name, the second source file name, the first main program source file list, the second main program source file list, the first dynamic library source file list, and the second dynamic library source file list.
  • the attribution information includes any one of the following: attributable to the first dynamic library, attributable to the second dynamic library, attributable to the first main program, and attributable to the second main program;
  • the first and second main program source file lists By matching the first and second source file names obtained in S11, the first and second main programs and the first and second dynamic libraries obtained in S12, the first and second main program source file lists, the first and second dynamic libraries, respectively By comparing the source file list, it can be obtained whether the first target file belongs to the first main program or the first dynamic library, and whether the second target file belongs to the second main program or the second dynamic library.
  • the first source file name of the first target file X in the first project is N
  • the first main program source file list of the first main program of the first project includes a file whose source file name is N. It can be determined that the first target file X belongs to the first main program.
  • the first main program of the first project and the first main program and dynamic library source file corresponding to the first dynamic library are used.
  • the list is compared; since the second target file belongs to the second project, the second main program of the second project and the second main program and the dynamic library source file list corresponding to the second dynamic library are used for comparison.
  • Step S14 Obtain the difference function of the main program, and generate the first intermediate hot patch file
  • Step S15 Obtain the dynamic library difference function, and generate a second intermediate hot patch file.
  • the first intermediate hot patch file includes identification information
  • the identification information includes the main program identifier
  • the main program difference function includes the first target file attributable to the first main program on the corresponding node and the first target file attributable to the second main program on the corresponding node.
  • the second intermediate hot patch file includes identification information
  • the identification information includes the dynamic library identifier
  • the dynamic library difference function includes the first target file attributable to the first dynamic library on the corresponding node and the second target file attributable to the second
  • the dynamic library identifier indicates that the first intermediate hot patch file corresponds to a dynamic library
  • the main program identifier indicates that the second intermediate hot patch file corresponds to a main program.
  • obtaining the main program difference function, generating the first intermediate hot patch file, obtaining the dynamic library difference function, and generating the second intermediate hot patch file includes:
  • the first target files are respectively linked to generate the first main program intermediate file and the first dynamic library intermediate file
  • the second target files are respectively linked to generate the second main program intermediate file according to the attribution information
  • the intermediate files of the second dynamic library include:
  • Each node in the target file list includes the full path name of the first target file and the full path name of the second target file with the same name;
  • the second target file is linked step by step according to the path information recorded in the target file list to generate the second main program intermediate file and the second dynamic library intermediate file.
  • the link mode there may be one or more intermediate files of the first main program.
  • the intermediate file of the first main program needs to be compared with the file (binary file of the same name) on the corresponding node in the intermediate file of the second main program.
  • the comparison process is relatively cumbersome and the workload is relatively large. If the first main program intermediate file, the second main program intermediate file, the first dynamic library intermediate file, and the second dynamic library intermediate file are obtained through step-by-step connection, it can be achieved through one first main program intermediate file and one The second main program intermediate file is compared to the file on the node (binary file with the same name), and the main program difference function is obtained.
  • Step S16 encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate a hot patch file.
  • the first and second intermediate hot patch files are packaged by the objcopy tool to generate a hot patch file.
  • the first intermediate hot patch file and the second intermediate hot patch file are respectively stored as an independent section.
  • the hot patch file includes main program information. In this way, subsequent management and verification can be facilitated, and it is possible to more accurately know which main program the hot patch file is for.
  • steps S11 and S12 are not limited in this embodiment, that is, step S11 may be executed first, and then step S12 may be executed, or the two parts may be executed simultaneously, as long as step S13 is executed Before, just get the source file name and source file list.
  • the above steps are all implemented in an automatic manner. At this time, the production of the hot patch no longer depends on manually setting the attribution of the patch function, which is more convenient, and after eliminating human errors, the accuracy is higher.
  • Step S20 Add the -g parameter to construct the project before and after the modification.
  • Step S21 Obtain the full path of the main program and the dynamic library in the project directory.
  • Step S22 Obtain the source file list of the main program and the dynamic library.
  • the debugging information of the first main program and the first dynamic library of the project P is analyzed to obtain the first main program and the source file list of the dynamic library that constitute the first main program and the first dynamic library, respectively.
  • Step S23 Obtain a list of target files.
  • the diff tool is used to compare two project directories P'and P, and the addresses of the first target file and the second target file with the same name in the two project directories with the same name form the target file list O, where the target file list O is Each node contains the full path name of the first target file before modification and the second target file after modification with the same name.
  • Step S24 Parse the target file list to determine attribution information.
  • the debugging information of the first and second target files in each node in the list O is parsed one by one to obtain the first and second source file names that generated the first and second target files, and the first and second source file names and From the first and second main program source file lists and the first and second dynamic library source file lists obtained in step S22, it can be determined that the first and second object files belong to the first and second dynamic libraries or the first and second main programs Which one is the attribution information of the first and second target files.
  • Step S25 Compare the first and second target files, extract the differences, generate an intermediate hot patch file, and record the identification information.
  • the first and second target files are respectively linked into a first main program intermediate file and a second main program intermediate file, and then Compare the two intermediate files of the first main program and the intermediate file of the second main program, extract the different functions to generate the first intermediate hot patch file, and record the identification information of the first intermediate hot patch file as the main program identifier;
  • the attribution information is the first and second target files of the first and second dynamic libraries.
  • the first and second target files are respectively linked into a first dynamic library intermediate file and a second dynamic library intermediate file, and then compare the two
  • the binary files of the same name in the first dynamic library intermediate file and the second dynamic library intermediate file are extracted to generate the second intermediate hot patch file by extracting the different functions, and at the same time, the identification information of the second intermediate hot patch file is recorded as the dynamic library identifier.
  • the patch function in the first intermediate hot patch file corresponds to the main program
  • the patch function in the second intermediate hot patch file corresponds to a dynamic library.
  • Step S26 encapsulate the first and second intermediate hot patch files into a hot patch file.
  • first and second intermediate hot patch files are packaged into a hot patch file through the objcopy tool, where the first and second intermediate hot patch files can be stored as separate sections.
  • the hot patch file can also record the information of the main program to facilitate subsequent management and verification.
  • the hot patch file generation method provided in the embodiments of the present disclosure can be applied to the hot patch technical field of Linux user-mode software written in C/C++ language.
  • the method for generating a hot patch file provided by an embodiment of the present disclosure is applied to the technical field of hot patching of linux user-mode software written in the C/C++ language of the X8664 architecture.
  • the hot patch file generation method provided in this embodiment provides a linux user mode program hot patch solution.
  • a hot patch file is finally generated, which is encapsulated by the second intermediate hot patch file attributable to the dynamic library and the first intermediate hot patch file attributable to the main program , And through the first and second source file names of the first and second object files and the first and second main program source file lists corresponding to the first and second main programs or the first and second dynamic libraries, the first and second dynamic libraries
  • the source file list is compared, and the attribution information of the first and second target files can be obtained.
  • the identification information can be recorded in the first and second intermediate hot patch files to obtain the first and second intermediate hot patch files
  • Each patch function in the corresponding is the main program of the source program or the dynamic library.
  • the generated hot patch file records the identification information of each function, and you can know that the function corresponds to
  • the main program of the source program that needs to be patched is still a dynamic library, which reduces the main program and dynamic library of the source file.
  • the main program and dynamic library of the source file have the same function, because the identification information of the patch function is not known, the patched function cannot be accurately determined, resulting in patching failure. Or the risk of patching errors.
  • the reliability of hot patching technology also depends on whether the program status can be ensured, that is, the program executes the original patched function before the patching operation is completed, and the program executes the patched function after the patching operation is completed, and there can be no intermediate State, that is to say, it must not be allowed that some tasks will execute the old code in the patched function after the patching operation is completed. This may cause confusion in the program data and state, affect the correctness of the program function, or even cause the program to crash. This requires that when the hot patch is applied, it is necessary to determine whether the current tasks of the program are executing the patched function, if it exists, the function replacement is postponed, and the function replacement must be performed when all tasks have not executed the patched function. How to judge whether the current tasks of the program are executing the patched function is called the consistency detection technology.
  • Solution 1 When hot patching, only check whether the current program technology PC of each task is in the patched function. This solution is obviously imperfect. For example, if you want to replace function A in the program, and the function call chain of a thread is A->B->C when the hot patch is applied, the code of C is currently being executed, if only the current PC is detected , Then the PC is in function C and does not belong to function A. The test passes, so the original A is replaced with the new A', but after the hot patch, the thread will continue to execute the original A after returning from B The remaining code in the program, and other threads that newly call A will execute the new A', which will lead to inconsistent program status and may cause program function abnormalities.
  • Solution 2 Use the ptrace debugging technology provided by the Linux kernel to track the process, suspend all threads, obtain the function call chain of the threads one by one, and check whether there is a patched function in the function call chain.
  • This solution does not have the problem of program status inconsistency in solution 1, but on the one hand, during the inspection process, it is necessary to frequently read the data of the tested program through the ptrace system call, and it needs to switch frequently between the kernel mode and the user mode, and the performance is relatively low; On the other hand, it is necessary to perform the above inspection process inspection for each thread one by one.
  • this embodiment provides a consistency detection method, which includes but is not limited to the following steps:
  • Step S30 Obtain the full path of the hot patch file and the identification information of the patched function.
  • the full path of the hot patch file may be specified by the user, or may be set by a system preset or other means. After completing the full path setting of the hot patch file, obtain the full path of the hot patch file.
  • obtaining the identification information of the patched function includes: searching the source program for the function with the same name as the patch function in the hot patch file; if the function with the same name is found, the function with the same name is the patched function; obtaining the patched function The identification information.
  • the identification information includes the starting address and size information of the patched function.
  • the hot patch file can be loaded by the hot patch management thread, and all patch function information in the hot patch file can be obtained, and then the function with the same name can be searched in the source program. If the function with the same name is found, it is the patched function. Record the starting address and size information of the patched function. In some embodiments, there may be a department patch function whose hot patch file cannot be found in the source program, which indicates that the patch function is a newly-added function.
  • the hot patch file in the consistency detection method in the embodiment of the present disclosure may be a hot patch file generated by the hot patch file generation method given in the above embodiment, or may be a method using related technologies.
  • the hot patch file obtained is not limited here.
  • Step S31 Obtain the source program call stack information of the source program.
  • the source program call stack information is auxiliary information generated by the compiler for backtracking the function call chain.
  • the call stack information of the main program of the process to be hot-patched (the current process) and the source program of the dependent dynamic library can be loaded when the program is initialized.
  • Those skilled in the art can also reasonably set other timings for obtaining the call stack information of the main program of the source program and the source program of the dynamic library according to needs.
  • Step S32 According to the source program call stack information, each thread of the current process of the source program parallelly backtracks the current function call chain of each thread itself.
  • each thread of the current process of the source program can execute the backtracking process in parallel, so that the backtracking efficiency is higher.
  • those skilled in the art can also specify that part of the threads are backtracked in parallel and part of the threads are backtracked one by one according to needs, or each thread is backtracked one by one one by one.
  • Step S33 traverse the thread functions in each layer in the current function call chain, and perform a consistency check.
  • the consistency check includes determining the thread state of the thread according to identification information, and the thread state includes a blocked state or continues to run.
  • the thread uses the source program call stack information to backtrack the current function call chain of each thread itself, which is to backtrack each layer of functions in the current function call chain, and then determine whether each layer of functions includes the patched function, and Not only the first layer is detected, therefore, the consistency check for this thread is complete. Further, if the consistency check of each thread of the current process is successful, theoretically, it can be guaranteed that the program state after subsequent patching is consistent.
  • determining the thread state of the thread according to the identification information includes:
  • determining the thread state of the thread according to the identification information includes:
  • the thread function includes the patched function, and the thread continues to run;
  • the threads are checked for consistency again.
  • the preset time may be a time reasonably set by those skilled in the art according to needs.
  • the preset time can also refer to the time for a thread to complete the detection. For example, it takes 20 milliseconds for a thread to complete the detection.
  • the check interval can be set to 30 milliseconds.
  • the consistency check step is repeated until each thread of the current process of the source program enters the blocked state. The consistency check is successful and the process ends.
  • Step S34 Determine the result of consistency detection according to the thread status of each thread.
  • determining the result of the consistency check according to the thread state of each thread includes:
  • the thread function does not include the patched function, it indicates that the thread has passed the consistency check and the thread is currently safe to patch. If all threads in the current process of the source program have passed the consistency check, the consistency check of the source program is successful. It should be noted that the current process of the source program includes processes that need to be hot-patched.
  • the thread entering the blocked state includes, but is not limited to, the thread entering the waiting lock state.
  • judging whether each thread of the current process of the source program (process that needs hot patch) enters the blocking state includes: obtaining the thread number of the current process of the source program; when the thread enters the blocking state, a global flag Atom plus 1; when the global mark atom is equal to the number of threads, each thread of the current process of the source program enters the blocking state. In some embodiments, if the global flag atom is less than the number of threads, the number of detections of the currently completed consistency detection of any thread that has not yet entered the blocking state is obtained, and if the number of detections is greater than the preset detection number threshold, then resume Each thread in a blocked state runs normally. Among them, the initial position of the global flag atom is 0.
  • the initialization position of the global flag atom can also be other positions set by those skilled in the art as needed.
  • the current process of the source program can be determined by the relationship between the global flag atom and the current number of threads of the source program. Whether each thread of the system enters the blocking state. For example, the initialization position of the global flag atom is 5 and the number of threads in the current process is 10. Every time a thread enters the blocking state, the global flag atom is incremented by 1. When the global flag atom is 15, the current process of the source program can be obtained. The threads all enter the blocking state.
  • each thread enters a blocked state, and after the consistency check of the source program succeeds, it further includes:
  • the hot patch operation is performed on the source program, which can ensure the consistency of the program status after patching, and improve the reliability of the hot patch technology.
  • the completion of the hot patch operation includes at least one of the following: the patched functions in all threads of the current process have completed the function replacement; there is a new function, and the function addition has been completed. In some embodiments, after the hot patching operation is completed, it is prompted that the patching is successful.
  • determining the result of the consistency check according to the thread state of each thread includes:
  • the thread function in the thread still includes the patched function.
  • the consistency check can be performed again after receiving the next hot patch instruction.
  • the way of issuing the next hot patch instruction includes but is not limited to: automatically issued after a certain interval of time, and issued by the user through related equipment.
  • the preset detection times threshold may be a reasonable value set by those skilled in the art in combination with actual usage scenarios.
  • the resources that are no longer used are cleaned up, and the resources that are no longer used include call stack information.
  • the method further includes:
  • the consistency detection method further includes: cleaning up resources that are no longer used after the hot patching operation is completed, and the resources that are no longer used include source program call stack information.
  • resources that are no longer used are cleaned up, and the resources that are no longer used include source program call stack information.
  • the method further includes:
  • the signal is a non-dedicated signal
  • each thread of the current process of the source program parallelly traces the current function call chain of each thread itself.
  • the signal is a non-dedicated signal
  • the non-dedicated signal includes SIGUSR1, SIGUSR2, and real-time signals.
  • the current process includes the process of the source program that needs to be hot-patched.
  • the signal is a common signal or a real-time signal, such as common and non-dedicated signals such as SIGUSRI and SIG44.
  • determining the thread state of the thread according to the identification information includes:
  • the identification information includes the main program identification or the dynamic library identification;
  • the source program call stack information includes the main program call stack information of the source program and the dynamic library call stack information of the source program;
  • each thread of the main program of the current process of the source program backtracks the current function call chain of each thread in parallel;
  • each thread of the dynamic library of the current process of the source program backtracks the current function call chain of each thread in parallel;
  • the thread status of the thread of the dynamic library is determined according to the identification information of the patched function including the identification of the dynamic library.
  • the identification information of the patched function is used to distinguish whether the patched function corresponds to the main program of the source program or the dynamic library of the source program. It can be obtained from the identification information of the patch function corresponding to the patched function, and the identification information of the patched function is the same as the identification information of the patch function.
  • the identification information of the patch function corresponding to the patched function is the main program identifier, and the identification information of the patched function is also the main program identifier.
  • the identification information of the patch function corresponding to the patched function is the dynamic library identifier, and the identification information of the patched function is also the dynamic library identifier
  • the identification information of the patched function can classify the patched function into the patched function corresponding to the main program and the patched function corresponding to the dynamic library, the scope of comparison when determining the thread state can be reduced, and the rate of determining the thread state can be improved And accuracy.
  • Step S40 Obtain the identification information of the patched function and the full path of the hot patch file.
  • the user specifies the full path of the hot patch file to be printed, and then obtains the full path of the hot patch file.
  • the hot patch management thread loads the hot patch file and obtains all patch function information in it. Find the function with the same name of each patch function in the source program. If the function with the same name is found, the function with the same name in the source program is the patched function. If the function with the same name is not found, the patch function is a new function. Record the starting address and size information of the patched function.
  • Step S41 Load the main program call stack information of the process main program and the dynamic library and the dynamic library call stack information.
  • the main program call stack information of the main program of the loading process and the dynamic library call stack information of the dependent dynamic library, the main program call stack information and the dynamic library call stack information are functions generated by the compiler for backtracking Auxiliary information of the call chain.
  • the main program call stack information and the dynamic library call stack information constitute the source program call stack information of the source program.
  • Step S42 Obtain the current number of threads and send a signal to each thread.
  • the hot patch management thread obtains the thread number of the current process, and sends a signal to each thread.
  • the signal is a common signal or a real-time signal, such as SIGUSR1, SIG44 and other common and non-dedicated signals.
  • Step S43 After receiving the signal, each thread traces its current function call chain, and detects whether there is a patched function in the current function call chain. When detecting that there is no patched function, the thread is blocked and waiting; detecting that there is a patched function, the thread continues to run.
  • each thread traces its current function call chain according to the source program call stack information, and then each thread traverses the thread function in each layer of the current function call chain obtained by its own traceback, and detects the current function according to the identification information Whether there is the patched function obtained in step S40 in the call chain, if there is no patched function, the test passes, a global flag is atomically incremented by one, and then enters the waiting lock state; if there is a patched function, the test fails and the thread continues to execute .
  • the identification information of the patched function can be obtained.
  • the identification information includes the main program identification or the dynamic library identification.
  • the identification information is obtained for the identification information of the patched function identified by the main program. After the thread of the main program receives the signal , Use the call stack information of the main program to trace back to its current function call chain, and then, each thread of the main program traverses the thread functions in each layer of the current function call chain, and obtains the identification information according to the patched function identified by the main program The identification information detects whether there is the patched function obtained in step S40 in the current function call chain.
  • the identification information is the identification information of the patched function identified by the dynamic library.
  • the thread of the dynamic library uses the dynamic library call stack information to backtrack its current function call chain, and then each thread of the dynamic library traverses the current function call.
  • the thread function in each layer of the chain detects whether there is the patched function obtained in step S40 in the current function call chain according to the identification information of the patched function whose identification information is the dynamic library identification. If there is no patched function, then If the detection is passed, a global flag is atomically incremented by one, and then it enters the waiting lock state; if there is a patched function, the detection fails and the thread continues to execute.
  • Step S44 Determine whether all threads are in the waiting lock state, if yes, execute step S45; if not, execute step S46.
  • Step S45 Perform function replacement and resume the operation of all threads, and execute step S47.
  • Step S46 Determine whether the number of detected books is greater than the preset detection times threshold, if not, execute step S42; if yes, execute step S47.
  • the hot patch management thread checks whether the value of the global flag is equal to the current number of threads other than the hot patch management thread at a preset time, and if they are equal, the detection passes, and the function replacement is performed, indicating that the patching is successful. Resume the operation of all other threads and clean up resources that are no longer used, such as source program call stack information. If the value of the global flag is not equal to the number of threads other than the current hot patch management thread, the test fails, and then it is judged whether it is greater than the preset detection times threshold, and if it is not greater than the preset detection times threshold, it continues to wait for the next detection . If it is greater than the preset detection times threshold, the process ends.
  • the selection of the preset time can refer to the time for a thread to complete the detection. Assuming that it takes 20 milliseconds for a thread to complete the detection, the preset time can be set to 30 milliseconds in consideration of the scheduling problem of multiple threads. When it prompts that the patching fails, you can prompt the user to retry the consistency check after a certain interval.
  • the consistency detection method provided by the embodiments of the present disclosure can be applied to the technical field of hot patching of linux user mode software written in C/C++ language, and provides a linux user mode program hot patching solution.
  • the consistency detection method provided by the embodiments of the present disclosure is applied to the technical field of hot patching of Linux user-mode software written in the C/C++ language of the X8664 architecture.
  • each thread since each thread backtracks its own current function call chain, on the one hand, it does not need to rely on the ptrace debugging technology provided by the kernel, which avoids frequent switching between the user mode and the kernel mode; on the other hand, Each thread can execute the backtracking process in parallel instead of backtracking one by one.
  • the overall performance is qualitatively improved compared to the solution using ptrace debugging technology, which reduces the backtracking time and has a relatively small impact on the program.
  • the consistency detection method in the embodiment of the present disclosure detects whether the thread function in each layer of the thread function call chain is a patched function, instead of only detecting the first layer, so the consistency detection is complete. As long as each thread passes the test, the program status after patching can be guaranteed to be consistent, which improves the reliability of the hot patch technology.
  • an embodiment of the present disclosure also provides a hot patch file generating device, and the hot patch file generating device 500 includes:
  • the first obtaining module 501 is configured to obtain a first target file in a first project before modification and a second target file in a second project after modification, where the first target file and the second target file are respectively Files with differences on storage nodes corresponding to the first project and the second project;
  • the second obtaining module 502 is configured to obtain a first source file name for generating the first target file and a second source file name for generating the second target file;
  • the third obtaining module 503 is configured to obtain the first main program source file list of the first main program, the first dynamic library source file list of the first dynamic library, the second main program source file list of the second main program, and the second main program source file list of the first dynamic library.
  • the second dynamic library source file list of the dynamic library, the first main program and the first dynamic library belong to the first project, and the second main program and the second dynamic library belong to the first project. Second project;
  • the first determining module 504 is configured to determine the attribution information of the first target file and the second target file, and the attribution information is based on the first source file name, the second source file name, and the first source file name.
  • a main program source file list, the second main program source file list, the first dynamic library source file list, and the second dynamic library source file list are determined, and the attribution information includes any one of the following: attribution The first dynamic library, the second dynamic library, the first main program, and the second main program;
  • the fourth acquisition module 505 is configured to acquire the main program difference function and generate a first intermediate hot patch file, the first intermediate hot patch file includes identification information, the identification information includes a main program identifier, and the main program difference function includes The function corresponding to the difference between the first target file belonging to the first main program and the second target file belonging to the second main program on the corresponding node;
  • the fifth acquiring module 506 is configured to acquire the dynamic library difference function and generate a second intermediate hot patch file, the second intermediate hot patch file includes identification information, the identification information includes a dynamic library identifier, and the dynamic library difference function includes The function corresponding to the difference between the first target file belonging to the first dynamic library and the second target file belonging to the second dynamic library on the corresponding node;
  • the encapsulation module 507 is configured to encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate a hot patch file.
  • the hot patch file generating device includes other modules to implement the steps of the hot patch file generating method described in the above embodiments.
  • the specific functions of each module please refer to the above hot patch.
  • the description in the embodiment of the file generation method will not be repeated here.
  • the hot patch file generating device provided in this embodiment finally generates a hot patch file, which is encapsulated by the second intermediate hot patch file attributable to the dynamic library and the first intermediate hot patch file attributable to the main program.
  • the identification information is recorded in the first and second intermediate hot patch files. It can be obtained whether each patch function in the first and second intermediate hot patch files corresponds to the main program of the source program or the dynamic library.
  • the hot patch generation process can be completed automatically. The production staff does not need to understand the details of the program, but only needs to know how to build the target project. After the first and second projects before and after the construction modification are completed, the remaining steps are realized by automation.
  • the generated hot patch file records the identification information of each patch function, and you can know the corresponding function Whether it is the main program of the source program that needs to be patched or the dynamic library, which reduces the fact that when the main program and dynamic library of the source file have the same function, because the identification information of the patch function is not known, the patched function cannot be accurately determined, resulting in patching Risk of failure or incorrect patching.
  • an embodiment of the present disclosure also provides a consistency detection device, and the consistency detection device 600 includes:
  • the sixth obtaining module 601 is configured to obtain the full path of the hot patch file and the identification information of the patched function
  • the seventh obtaining module 602 is configured to obtain source program call stack information of the source program
  • the parallel backtracking module 603 is configured to, according to the source program call stack information, each thread of the current process of the source program backtracks the current function call chain of each thread in parallel;
  • the detection module 604 is configured to traverse the thread functions in each layer in the current function call chain to perform consistency detection.
  • the consistency detection includes determining the thread status of the thread according to the identification information, and the thread status Including blocked state or continued operation;
  • the second determining module 605 is configured to determine the result of the consistency check according to the thread state of each thread.
  • the consistency detection device provided in this embodiment includes other modules to implement the steps of the consistency detection method described in the foregoing embodiments.
  • each thread since each thread traces its own current function call chain by itself, on the one hand, it does not need to rely on the ptrace debugging technology provided by the kernel, which avoids frequent switching between the user mode and the kernel mode; on the other hand, On the other hand, each thread can execute the backtracking process in parallel instead of backtracking one by one. The overall performance is qualitatively improved compared to the solution using ptrace debugging technology.
  • the consistency detection device in the embodiment of the present disclosure detects whether the thread function in each layer in each thread function call chain is a patched function, instead of only detecting the first layer, so the consistency detection is complete. As long as each thread passes the test, the program status after patching can be guaranteed to be consistent, which improves the reliability of the hot patch technology.
  • an embodiment of the present disclosure also provides a first device 700.
  • the first device 700 includes a first memory 701, a first processor 702, and is stored in the first memory 701 and can be stored in the first processor.
  • the first program running on the 702 and the first data bus 703 configured to realize the connection and communication between the first processor 702 and the first memory 701.
  • the first program is executed by the first processor 702, any one of the above The steps of the hot patch file generation method of the embodiment.
  • the first device provided in this embodiment finally generates a hot patch file, which is encapsulated by the second intermediate hot patch file belonging to the dynamic library and the first intermediate hot patch file belonging to the main program.
  • the identification information is recorded in the intermediate hot patch file. It can be known whether the function corresponds to the main program of the source program that needs to be patched or the dynamic library, which reduces the main program and dynamic library of the source file. Knowing the identification information of the patch function, and then unable to accurately determine the function to be patched, leading to the risk of patching failure or patching errors.
  • the hot patch generation process can be completed automatically. The production staff does not need to understand the details of the program, but only needs to know how to build the target project.
  • the generated hot patch file records the attribution information of each patched function.
  • the operator When applying the hot patch, the operator only needs to specify the patch file, and does not need to understand the program and The details of the patch. The ease of use is very high and will not cause errors due to the operator's reasons, and the reliability of the hot patch technology is improved.
  • an embodiment of the present disclosure also provides a second device 800.
  • the second device includes a second memory 801, a second processor 802, and is stored in the second memory 801 and can be stored in the second processor 802.
  • the second program running on the computer and the second data bus 803 set to realize the connection and communication between the second processor 802 and the second memory 801.
  • the implementation can be implemented as any one of the above The steps of the consistency detection method of the case.
  • each thread since each thread backtracks its own current function call chain, on the one hand, it does not need to rely on the ptrace debugging technology provided by the kernel, which avoids frequent switching between user mode and kernel mode; on the other hand, Each thread can execute the backtracking process in parallel instead of backtracking one by one.
  • the overall performance is qualitatively improved compared to the solution using ptrace debugging technology.
  • the consistency detection method in the embodiment of the present disclosure detects whether the thread function in each layer of the thread function call chain is a patched function, instead of only detecting the first layer, so the consistency detection is complete. As long as each thread passes the test, the program status after patching can be guaranteed to be consistent, which improves the reliability of the hot patch technology.
  • the embodiment of the present disclosure also provides a storage medium configured as a computer-readable storage, the storage medium stores one or more first programs, and the one or more first programs can be executed by one or more first processors, To realize the steps of the hot patch file generation method of any one of the above embodiments;
  • the storage medium stores one or more second programs, and the one or more second programs may be executed by one or more second processors to implement the steps of the consistency detection method in any one of the foregoing embodiments.
  • the division between functional modules/units mentioned in the above description does not necessarily correspond to the division of physical components; for example, a physical component may have multiple functions, or a function or step may consist of several physical components.
  • the components are executed cooperatively.
  • Certain physical components or all physical components can be implemented as software executed by a processor, such as a central processing unit, a digital signal processor, or a microprocessor, or as hardware, or as an integrated circuit, such as an application specific integrated circuit .
  • a processor such as a central processing unit, a digital signal processor, or a microprocessor
  • Such software may be distributed on a computer-readable medium, and the computer-readable medium may include a computer storage medium (or non-transitory medium) and a communication medium (or transitory medium).
  • computer storage medium includes volatile and nonvolatile implementations in any method or technology configured to store information (such as computer-readable instructions, data structures, program modules, or other data).
  • Information such as computer-readable instructions, data structures, program modules, or other data.
  • Computer storage media include but are not limited to RAM, ROM, EEPROM, flash memory or other storage technologies, CD-ROM, digital versatile disk (DVD) or other optical disk storage, magnetic cassettes, magnetic tapes, magnetic disk storage or other magnetic storage devices, or Set up as any other medium that stores the desired information and can be accessed by the computer.
  • communication media usually contain computer-readable instructions, data structures, program modules, or other data in a modulated data signal such as carrier waves or other transmission mechanisms, and may include any information delivery media. .

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Artificial Intelligence (AREA)
  • Audiology, Speech & Language Pathology (AREA)
  • Computational Linguistics (AREA)
  • General Health & Medical Sciences (AREA)
  • Computer Security & Cryptography (AREA)
  • Stored Programmes (AREA)

Abstract

一种热补丁文件生成、一致性检测方法、装置、设备和介质。热补丁文件生成方法通过获取第一、第二过程中第一、第二目标文件，得到第一第二目标文件的源文件名，获取第一第二主程序和动态库各自所对应的第一第二主程序源文件列表、第一第二动态库源文件列表，根据得到的源文件名和源文件列表确定第一第二目标文件的归属信息，生成包括识别信息的第一第二中间热补丁文件最终得到热补丁文件，热补丁文件包括识别信息，可以得到各补丁函数是对应主程序还是动态库，可准确获取被补丁函数，易用性高。

Description

热补丁文件生成、一致性检测方法、装置、设备和介质 技术领域
本公开实施例涉及C/C++语言编写的linux用户态软件的热补丁技术领域，尤其涉及一种热补丁文件生成、一致性检测方法、装置、设备和介质。
背景技术
在通信领域，确保服务的连贯性非常重要，在程序出现故障时需要在线修复故障而不是重启程序。在线修复故障的技术通常称为热补丁技术，该技术将正在运行的被补丁函数(有故障的函数)替换成补丁函数(修复故障后的函数)，以达到修复故障而又不重启程序的目的。热补丁技术基本上都是采用将被补丁函数入口处的指令修改为跳转到补丁函数入口的跳转指令，达到函数替换目的。
由于一般的程序由主程序和依赖的动态库组成，主程序和动态库中可能存在同名函数，如何准确获取被补丁函数是对程序正确打热补丁的前提。比如要对函数A打补丁，可能程序依赖的动态库中不止一个定义了名为A的函数，找错函数将导致程序崩溃。目前业界常用的做法是要么要求打补丁时指定被补丁函数的归属信息(主程序或者动态库)，要么要求在制作补丁时将被补丁函数将归属信息记录在补丁文件中，可是无论是打补丁的人员还是制作补丁的人员都不一定是开发人员，可能并不清楚被补丁函数的归属信息，使得这种方法易用性不好，容易出错，使得热补丁技术的可靠性不高。
发明内容
本公开实施例的主要目的在于提出一种热补丁文件生成、一致性检测方法、装置、设备和介质，旨在实现解决热补丁技术中被补丁函数不能被准确获取的问题，使得热补丁技术的易用性不好，容易出错，可靠性不高的问题。
为实现上述目的，本公开实施例提供了一种热补丁文件生成方法，所述热补丁文件生成方法包括：
获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件，所述第一目标文件和所述第二目标文件分别为所述第一工程与所述第二工程对应存储节点上存在差异的文件；
获取生成所述第一目标文件的第一源文件名、生成所述第二目标文件的第二源文件名；
获取第一主程序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表，所述第一主程序和所述第一动态库归属于所述第一工程，所述第二主程序和 所述第二动态库归属于所述第二工程；
确定所述第一目标文件、所述第二目标文件的归属信息，所述归属信息根据所述第一源文件名、所述第二源文件名、所述第一主程序源文件列表、所述第二主程序源文件列表、所述第一动态库源文件列表、所述第二动态库源文件列表确定，所述归属信息包括以下任意之一：归属于第一动态库、归属于第二动态库、归属于第一主程序、归属于第二主程序；
获取主程序差异函数，生成第一中间热补丁文件，所述第一中间热补丁文件包括识别信息，所述识别信息包括主程序标识，所述主程序差异函数包括对应节点上归属于第一主程序的第一目标文件与归属于第二主程序的第二目标文件中存在差异的函数；
获取动态库差异函数，生成第二中间热补丁文件，所述第二中间热补丁文件包括识别信息，所述识别信息包括动态库标识，所述动态库差异函数包括对应节点上归属于第一动态库的第一目标文件与归属于第二动态库的第二目标文件中存在差异的函数；
封装所述第一中间热补丁文件与所述第二中间热补丁文件，生成热补丁文件。
为实现上述目的，本公开实施例还提出了一种一致性检测方法，所述一致性检测方法包括：
获取热补丁文件的全路径及被补丁函数的识别信息；
获取源程序的源程序调用栈信息；
根据所述源程序调用栈信息，所述源程序的当前进程的各线程并行回溯各所述线程自身的当前函数调用链；
遍历所述当前函数调用链中的每层中的线程函数，进行一致性检测，所述一致性检测包括根据所述识别信息确定所述线程的线程状态，所述线程状态包括阻塞状态或继续运行；
根据各所述线程的所述线程状态确定所述一致性检测的结果。
为实现上述目的，本公开提供了一种热补丁文件生成装置，所述热补丁文件生成装置包括：
第一获取模块，设置为获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件，所述第一目标文件和所述第二目标文件分别为所述第一工程与所述第二工程对应存储节点上存在差异的文件；
第二获取模块，设置为获取生成所述第一目标文件的第一源文件名、生成所述第二目标文件的第二源文件名；
第三获取模块，设置为获取第一主程序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表，所述第一主程序和所述第一动态库归属于所述第一工程，所述第二主程序和所述第二动态库归属于所述第二工程；
第一确定模块，设置为确定所述第一目标文件、所述第二目标文件的归属信 息，所述归属信息根据所述第一源文件名、所述第二源文件名、所述第一主程序源文件列表、所述第二主程序源文件列表、所述第一动态库源文件列表、所述第二动态库源文件列表确定，所述归属信息包括以下任意之一：归属于第一动态库、归属于第二动态库、归属于第一主程序、归属于第二主程序；
第四获取模块，设置为获取主程序差异函数，生成第一中间热补丁文件，所述第一中间热补丁文件包括识别信息，所述识别信息包括主程序标识，所述主程序差异函数包括对应节点上归属于第一主程序的第一目标文件与归属于第二主程序的第二目标文件中存在差异的函数；
第五获取模块，设置为获取动态库差异函数，生成第二中间热补丁文件，所述第二中间热补丁文件包括识别信息，所述标识信息包括动态库标识，所述动态库差异函数包括对应节点上归属于第一动态库的第一目标文件与归属于第二动态库的第二目标文件中存在差异的函数；
封装模块，设置为封装所述第一中间热补丁文件与所述第二中间热补丁文件，生成热补丁文件。
为实现上述目的，本公开提供了一种一致性检测装置，所述一致性检测装置包括：
第六获取模块，设置为获取热补丁文件的全路径及被补丁函数的标识信息；
第七获取模块，设置为获取源程序的源程序调用栈信息；
并行回溯模块，设置为根据所述源程序调用栈信息，所述源程序的当前进程的各线程并行回溯各所述线程自身的当前函数调用链；
检测模块，设置为遍历所述当前函数调用链中的每层中的线程函数，进行一致性检测，所述一致性检测包括根据所述标识信息确定所述线程的线程状态，所述线程状态包括阻塞状态或继续运行；
第二确定模块，设置为根据各所述线程的所述线程状态确定所述一致性检测的结果。
为实现上述目的，本公开提供了一种第一设备，所述第一设备包括第一存储器、第一处理器、存储在所述第一存储器上并可在所述第一处理器上运行的第一程序以及设置为实现所述第一处理器和所述第一存储器之间的连接通信的第一数据总线，所述第一程序被所述第一处理器执行时实现如上述任一项实施例所述的热补丁文件生成方法的步骤。
为实现上述目的，本公开提供了第二设备，所述第二设备包括第二存储器、第二处理器、存储在所述第二存储器上并可在所述第二处理器上运行的第二程序以及设置为实现所述第二处理器和所述第二存储器之间的连接通信的第二数据总线，所述第二程序被所述第二处理器执行时实现如上述任一项实施例所述的一致性检测方法的步骤。
为实现上述目的，本公开提供了一种介质，设置为计算机可读存储，所述存储介质存储有一个或者多个第一程序，所述一个或者多个第一程序可被一个或者 多个第一处理器执行，以实现上述任一项实施例所述的热补丁文件生成方法的步骤；
或，
所述存储介质存储有一个或者多个第二程序，所述一个或者多个第二程序可被一个或者多个第二处理器执行，以实现上述任一项实施例所述的一致性检测方法的步骤。
本公开提出的热补丁文件生成、一致性检测方法、装置、设备和介质，其中热补丁文件生成方法通过获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件，其中，第一目标文件和第二目标文件分别为第一工程与第二工程对应存储节点上存在差异的文件。获取生成第一目标文件的第一源文件名、生成第二目标文件的第二源文件名。获取第一主程序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表，其中，第一主程序和第一动态库归属于第一工程，第二主程序和第二动态库归属于第二工程。确定第一目标文件、第二目标文件的归属信息，归属信息根据第一源文件名、第二源文件名、第一主程序源文件列表、第二主程序源文件列表、第一动态库源文件列表、第二动态库源文件列表确定，归属信息包括以下任意之一：归属于第一动态库、归属于第二动态库、归属于第一主程序、归属于第二主程序。获取主程序差异函数，生成第一中间热补丁文件，第一中间热补丁文件包括识别信息，识别信息包括主程序标识，以标识该第一中间热补丁文件对应的是主程序，主程序差异函数包括对应节点上归属于第一主程序的第一目标文件与归属于第二主程序的第二目标文件中存在差异的函数；获取动态库差异函数，生成第二中间热补丁文件，第二中间热补丁文件包括识别信息，识别信息包括动态库标识，以标识该第二中间热补丁文件对应的是动态库，动态库差异函数包括对应节点上归属于第一动态库的第一目标文件与归属于第二动态库的第二目标文件中存在差异的函数；封装第一中间热补丁文件与第二中间热补丁文件，生成热补丁文件。通过对第一、二目标文件的源文件名与第一、二主程序或第一、二动态库对应的源文件列表进行比对，可以得到该各第一、二目标文件的归属信息，根据归属信息对第一、二目标文件进行分类，将归属信息为第一、二主程序的第一、二目标文件进行比对，获取主程序差异函数，将归属信息为第一、二动态库的第一、二目标文件进行比对，获取动态库差异函数，根据主程序差异函数生成第一中间热补丁文件，并在第一中间热补丁文件中记载主程序标识，根据动态库差异函数生成第二中间热补丁文件，并在第二中间热补丁文件中记载动态库标识，这样，封装得到的热补丁文件中，由于被补丁函数的识别信息与其所在文件的识别信息是相同的，可以根据补丁函数所在的文件，进而知晓该补丁函数是归属于主程序还是归属于动态库，也即，可以清楚准准确的得到每个被补丁函数的是归属于主程序还是归属于动态库的信息。打热 补丁时操作人员只需指定热补丁文件即可，由于热补丁文件中补丁函数的识别信息是已知的，这样可以准确的获取被补丁函数，降低了源文件的主程序和动态库存在有相同函数时，由于不知晓补丁函数的识别信息，进而不能准确确定被补丁函数，导致打补丁失败或打补丁错误的风险。上述操作可以通过自动化的方式实现，此时，操作人员不需要了解程序和补丁的细节，易用性高且有效避免了因为操作人员的原因而导致错误，提升了热补丁技术的可靠性。
附图说明
图1是本公开实施例一提供的一种热补丁文件生成方法的流程图；
图2是本公开实施例一提供的一种热补丁文件生成方法具体应用示例的流程图；
图3是本公开实施例二提供的一种一致性检测方法的流程图；
图4是本公开实施例二提供的一种一致性检测方法具体应用示例的流程图；
图5是本公开实施例三提供的一种热补丁文件生成装置的结构框图；
图6是本公开实施例四提供的一种一致性检测装置的结构框图；
图7是本公开实施例五提供的一种第一设备的结构框图；
图8是本公开实施例六提供的一种第二设备的结构框图。
具体实施方式
应当理解，此处所描述的具体实施例仅仅用以解释本公开，并不用于限定本公开。
在后续的描述中，使用设置为表示元件的诸如“模块”、“部件”或“单元”的后缀仅为了有利于本公开的说明，其本身没有特有的意义。因此，“模块”、“部件”或“单元”可以混合地使用。
实施例一
如图1所示，本实施例提供了一种热补丁文件生成方法，该方法包括但不限于以下步骤：
步骤S10：获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件。
需要说明的是，第一目标文件和第二目标文件分别为第一工程与第二工程对应存储节点上存在差异的文件。其中，由于第二工程是在第一工程的基础上，根据一定规则进行修改后，得到的，因此，通常情况下，第二工程的各修改后文件的存储节点与第一工程中的各修改前的文件的存储节点均存在一定对应关系，因此，对应存储节点上存在差异的文件可以理解为对于第一工程的修改前文件进行修改后，得到的第二工程的修改后文件，若修改前文件与修改后文件的内容上存在差异，此时，修改前文件即为第一目标文件，修改后文件即为第二目标文件。
在一些实施例中，获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件之前，还包括：
根据调试信息的编译参数在同一目录下分别构建修改前的第一工程和修改后的第二工程，
第一目标文件和第二目标文件分别为第一工程和第二工程的各同名二进制文件中存在差异的文件。
需要说明的是，第一工程和第二工程的同名二进制文件的编译路径相同。
在一些实施例中，假设对工程P制作热补丁。假设工程P构建会得到一个主程序和若干依赖的动态库。添加-g参数编译修改前的工程，编译完成后将整个工程改名为P；然后在同一个目录下添加-g参数编译修改源码后的工程,将该工程改名为P'。这样P'的工程目录和P的工程目录中同名二进制文件中的编译路径相同，避免因为编译路径不同而影响后续补丁制作。此时，第一、二目标文件包括第一工程和第二工程的各同名二进制文件中存在差异的文件。具体的可以理解为在第一工程和第二工程中均存在有名称为X的二进制文件，但第一工程中的X文件与第二工程中的X文件的内容不同，则两者存在差异，此时，两个名称为X的文件分别为第一工程的第一目标文件和第二工程的第二目标文件。
在一些实施例中，获取第一、第二目标文件还包括：对比第一工程的工程目录和第二工程的工程目录，生成目标文件列表，目标文件列表中每个节点包括同名的第一目标文件和第二目标文件的全路径名。
在一些实施例中，获取第一、第二目标文件的方法可以为：使用d iff工具对比第一、二工程各自的工程目录，得到两个工程目录下同名的有差异的目标文件的目标文件列表O，其中该目标文件列表O中每个节点记录了同名的第一、二目标文件的全路径名。例如，使用d iff工具对比工程P'和P的工程目录，找到相同路径下储存有文件内容存在区别的同名文件X和X'，则将X和X'做为一对目标文件对，将该目标文件对的全路径名记录在目标文件列表中。
步骤S11：获取生成第一目标文件的第一源文件名、生成第二目标文件的第二源文件名。
在一些实施例中，获取生成第一目标文件的第一源文件名、生成第二目标文件的第二源文件名包括：
解析第一目标文件的调试信息，得到生成第一源文件名；
解析第二目标文件的调试信息，得到生成第二源文件名。
在一些实施例中，可以通过逐个解析第一、二目标文件的调试信息，得到生成第一、二源文件名。
在一些实施例中，当获取到目标文件列表时，则可以通过解析目标文件列表中的各第一、二目标文件的调试信息，得到生成该第一、二目标文件的第一、二源文件名。
步骤S12：获取第一主程序的第一主程序源文件列表、第一动态库的第一动 态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表。
其中，第一主程序和第一动态库归属于第一工程，第二主程序和第二动态库归属于第二工程。
在一些实施例中，第一主程序和第一动态库的获取可以通过获取第一工程对应的主程序和动态库的全路径名来得到。第二主程序和第二动态库的获取可以通过获取第二工程对应的主程序和动态库的全路径名来得到。
在一些实施例中，第一工程与第二工程的同名二进制文件的编译路径相同。第一、二主程序和第一、二动态库可以通过从同名二进制文件中分别获取第一工程和第二工程分别对应的主程序和动态库的全路径名的方式来得到。在一些实施例中，通过分别扫描第一工程和第二工程的工程目标下的二进制文件，进而可以得到并记录第一工程对应的第一主程序和第一动态库的全路径名，第二工程对应的第二主程序和第二动态库的全路径名。具体的全路径名的获取过程，可以采用相关技术得到，在此不再赘述。
需要说明的是，本公开实施例中的动态库为主程序所依赖的动态库。
在一些实施例中，获取第一主程序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表包括：
解析第一主程序的调试信息，得到第一主程序源文件列表；
解析第二主程序的调试信息，得到第二主程序源文件列表；
解析第一动态库的调试信息，得到第一动态库源文件列表；
解析第二动态库的调试信息，得到第二动态库源文件列表。
步骤S13：确定第一目标文件、第二目标文件的归属信息。
其中，归属信息根据第一源文件名、第二源文件名、第一主程序源文件列表、第二主程序源文件列表、第一动态库源文件列表、第二动态库源文件列表确定，归属信息包括以下任意之一：归属于第一动态库、归属于第二动态库、归属于第一主程序、归属于第二主程序；
通过将S11中得到的第一、二源文件名以及S12中得到的第一、二主程序和第一、二动态库分别对应的第一、二主程序源文件列表、第一、二动态库源文件列表进行比对，可以得到，该第一目标文件归属于第一主程序还是第一动态库，第二目标文件归属于第二主程序还是第二动态库。具体的，例如，第一工程中的第一目标文件X的第一源文件名为N，第一工程的第一主程序的第一主程序源文件列表中包括源文件名为N的文件，则可以确定，该第一目标文件X归属于第一主程序。
应当知晓的是，在确定目标文件的归属信息时，由于第一目标文件属于第一工程，则采用第一工程的第一主程序和第一动态库对应的第一主程序、动态库源文件列表进行比对；由于第二目标文件属于第二工程，则采用第二工程的第二主 程序和第二动态库所对应的第二主程序、动态库源文件列表进行比对。
步骤S14：获取主程序差异函数，生成第一中间热补丁文件；
步骤S15：获取动态库差异函数，生成第二中间热补丁文件。
需要说明的是，第一中间热补丁文件包括识别信息，识别信息包括主程序标识，主程序差异函数包括对应节点上归属于第一主程序的第一目标文件与归属于第二主程序的第二目标文件中存在差异的函数；第二中间热补丁文件包括识别信息，识别信息包括动态库标识，动态库差异函数包括对应节点上归属于第一动态库的第一目标文件与归属于第二动态库的第二目标文件中存在差异的函数。其中，动态库标识表明该第一中间热补丁文件对应的是动态库，主程序标识表明该第二中间热补丁文件对应的是主程序。
在一些实施例中，获取主程序差异函数，生成第一中间热补丁文件，获取动态库差异函数，生成第二中间热补丁文件包括：
根据归属信息，将第一目标文件分别链接生成第一主程序中间文件、第一动态库中间文件；
根据归属信息，将第二目标文件分别链接生成第二主程序中间文件、第二动态库中间文件；
提取第一主程序中间文件与第二主程序中间文件中同名二进制文件中存在差异的函数作为主程序差异函数，根据主程序差异函数生成第一中间热补丁文件；
提取第一动态库中间文件与第二动态库中间文件中同名二进制文件中存在差异的函数作为动态库差异函数，根据动态库差异函数生成第二中间热补丁文件。
在一些实施例中，根据归属信息，将第一目标文件分别链接生成第一主程序中间文件、第一动态库中间文件，根据归属信息，将第二目标文件分别链接生成第二主程序中间文件、第二动态库中间文件包括：
对比第一工程和第二工程的工程目录，生成目标文件列表，目标文件列表中每个节点包括同名的第一目标文件的全路径名和第二目标文件的全路径名；
根据归属信息，根据目标文件列表所记录的路径信息将第一目标文件分步链接生成第一主程序中间文件、第一动态库中间文件；
根据归属信息，根据目标文件列表所记录的路径信息将第二目标文件分步链接生成第二主程序中间文件、第二动态库中间文件。
需要说明的是，根据链接方式的不同，第一主程序中间文件可能是一个，也可能是多个。对应的，第二主程序中间文件可能是一个，也可能是多个。第一动态库中间文件可能是一个，也可能是多个。第二动态库中间文件可能是一个，也可能是多个。由于在获取动态库差异函数，需要将第一动态库中间文件与第二动态库中间文件中对应节点上的文件(同名二进制文件)进行比对，此时，若存在多个第一动态库中间文件和多个第二动态库中间文件时，比对过程较为繁琐，工作量较大。同样的，由于在获取主程序差异函数，需要将第一主程序中间文件与第二主程序中间文件中对应节点上的文件(同名二进制文件)进行比对，此时， 若存在多个第一主程序中间文件和多个第二主程序中间文件时，比对过程较为繁琐，工作量较大。若通过分步连接的方式得到的第一主程序中间文件、第二主程序中间文件、第一动态库中间文件、第二动态库中间文件，则可以实现通过一个第一主程序中间文件与一个第二主程序中间文件对应节点上的文件(同名二进制文件)进行对比，得到主程序差异函数，对应的，通过一个第一动态库中间文件与一个第二动态库中间文件对应节点上的文件(同名二进制文件)进行对比，得到动态库差异函数，过程较为简单更加方便快捷，用户体验度更高。
步骤S16：封装第一中间热补丁文件与第二中间热补丁文件，生成热补丁文件。
在一些实施例中，将这第一、二中间热补丁文件通过objcopy工具封装，生成一个热补丁文件。
在一些实施例中，在热补丁文件中，第一中间热补丁文件和第二中间热补丁文件分别作为一个独立的节进行存放。
在一些实施例中，热补丁文件包括主程序信息。这样可以方便后续管理和校验，得以更加准确的知晓该热补丁文件是针对于哪一个主程序的热补丁文件。
需要说明的是，步骤S11、S12的执行先后顺序在本实施例中没有顺序限定，也即，可以是先执行步骤S11后，再执行步骤S12，也可以两部分同时执行，只要在步骤S13执行之前，得到源文件名和源文件列表即可。
在一些实施例中，上述步骤均通过自动方式实现，此时，热补丁的制作不再依赖于人工对补丁函数的归属进行设定，更加便捷，排除了人为误差后，准确度更高。
参见图2，下面以针对于工程P制作热补丁文件为例具体说明本热补丁文件生成方法的实际应用。
步骤S20：加-g参数构建修改前后的工程。
假设工程P构建会得到一个主程序和若干依赖的动态库。添加-g参数编译修改前的工程，编译完成后将得到的整个工程改名为P；在同一个目录下添加-g参数编译修改源码后的工程，得到工程P'。这样两个工程目录P和P'中同名二进制文件中的编译路径完全相同，避免因为编译路径不同而影响后续补丁制作。
步骤S21：获取工程目录下的主程序和动态库的全路径。
具体地，扫描工程P目录下的二进制文件，记录其中第一主程序和第一动态库的全路径名。扫描工程P'目录下的二进制文件，记录其中第二主程序和第二动态库的全路径名。
步骤S22：获取主程序和动态库的源文件列表。
通过第一、二主程序和第一、二动态库的全路径名，进而得到工程P和工程P'各自分别对应的第一主程序和所依赖的第一动态库，第二主程序和第二动态库。
具体地，解析工程P的第一主程序和第一动态库的调试信息，分别得到构成第一主程序和第一动态库的第一主程序、动态库源文件列表。解析工程P'的第 二主程序和第二动态库的调试信息，分别得到构成第二主程序和第二动态库的第二主程序、动态库源文件列表。
步骤S23：获取目标文件列表。
具体地，使用diff工具对比两个工程目录P'和P，得到两个工程目录下同名的有差异的第一目标文件和第二目标文件的地址构成目标文件列表O，其中目标文件列表O中每个节点包含同名的修改前的第一目标文件和修改后的第二目标文件的全路径名。
步骤S24：解析目标文件列表，确定归属信息。
具体地，逐个解析列表O中各节点中的第一、二目标文件的调试信息，得到生成该第一、二目标文件的第一、二源文件名，通过该第一、二源文件名以及步骤S22中得到的第一、二主程序源文件列表和第一、二动态库源文件列表，就可以确定该第一、二目标文件属于第一、二动态库或者第一、二主程序中的哪一个，也即该第一、二目标文件的归属信息。
步骤S25：对比第一、二目标文件，提取差异，生成中间热补丁文件并记录识别信息。
具体地，对于归属信息为第一、二主程序的第一、二目标文件，分别将第一、二目标文件分步链接为一个第一主程序中间文件和一个第二主程序中间文件，然后对比这两个第一主程序中间文件和第二主程序中间文件，提取有差异的函数生成第一中间热补丁文件，同时将该第一中间热补丁文件的识别信息记录为主程序标识；对于归属信息为第一、二动态库的第一、二目标文件，分别将第一、二目标文件分步链接为一个第一动态库中间文件和一个第二动态库中间文件，然后对比这两个第一动态库中间文件和第二动态库中间文件中的同名二进制文件，提取有差异的函数生成第二中间热补丁文件，同时将该第二中间热补丁文件的识别信息记录为动态库标识。此时，可以得到，第一中间热补丁文件中的补丁函数对应的是主程序，第二中间热补丁文件中的补丁函数对应的是动态库。
步骤S26：将第一、二中间热补丁文件封装成热补丁文件。
具体地，将第一、二中间热补丁文件通过objcopy工具封装成一个热补丁文件，其中，第一、二中间热补丁文件可分别做为一个独立的节进行存放。
热补丁文件还可记录主程序的信息，方便后续管理和校验。
在一些实施例中，本公开实施例提供的热补丁文件生成方法可以应用于C/C++语言编写的linux用户态软件的热补丁技术领域。
在一些实施例中，本公开实施例提供的一种热补丁文件生成方法应用于针对X8664体系架构C/C++语言编写的linux用户态软件的热补丁技术领域。在一些实施例中，本实施例提供的热补丁文件生成方法提供了一种linux用户态程序热补丁解决方案。
通过本实施例提供的热补丁文件生成方法，最终生成一个热补丁文件，该热 补丁文件由归属于动态库的第二中间热补丁文件和归属于主程序的第一中间热补丁文件封装而成，而通过对第一、二目标文件的第一、二源文件名与第一、二主程序或第一、二动态库对应的第一、二主程序源文件列表、第一、二动态库源文件列表进行比对，可以得到该第一、二目标文件的归属信息，根据该归属信息，可以实现第一、二中间热补丁文件中均记录识别信息，得到第一、二中间热补丁文件中各补丁函数所对应的是源程序的主程序还是动态库。可以理解，一方面热补丁生成过程各步骤全部可以采用自动化完成，不需要制作人员了解程序的细节，只需要知道如何构建目标工程，在构建修改前后的第一、二工程后，剩余的步骤借助自动化的方式来实现，提升了热补丁文件生成的效率，简化了人工操作的步骤，提升用户体验，打热补丁时操作人员只需指定补丁文件即可，不需要了解程序和补丁的细节。易用性非常高且不会因为操作人员的原因而导致错误，提升热补丁技术的可靠性；另一方面生成的热补丁文件中记录了每个函数的识别信息，可以知晓该函数对应的是需要打补丁的源程序的主程序还是动态库，降低了源文件的主程序和动态库存在有相同函数时，由于不知晓补丁函数的识别信息，进而不能准确确定被补丁函数，导致打补丁失败或打补丁错误的风险。
实施例二
热补丁技术的可靠性还取决于能否确保程序状态的一致性，即打补丁操作完成前程序执行的都是原被补丁函数，打补丁操作完成后程序执行的都是补丁函数，不能存在中间状态，也就是说绝不能允许打补丁操作完成后部分任务还会执行被补丁函数中的旧代码，这样很可能导致程序数据和状态混乱，影响程序功能的正确性甚至引起程序崩溃。这就要求在打热补丁时需要判断程序当前各任务是否正在执行被补丁函数，如果存在则推迟进行函数替换，必须等到所有任务都没有执行被补丁函数时才能进行函数替换。如何判断程序当前各任务是否正在执行被补丁函数就称为一致性检测技术。
相关技术中热补丁一致性检测技术比较典型的方案有以下两种：
方案一：在打热补丁时只检测各任务的当前程序技术器PC是否在被补丁函数中。该方案显然是不完善的，比如要替换程序中的函数A，而打热补丁时某个线程的函数调用链为A->B->C，当前正在执行C的代码，如果只检测当前PC，那么PC在函数C中，不属于函数A，检测通过，于是就将原来的A替换为新的A'，但是这样一来打完热补丁后该线程从B返回后将继续执行原来的A中的剩余代码，而其他新调用A的线程将执行新的A'，这将导致程序状态不一致，可能引起程序功能异常。
方案二：使用Linux内核提供的ptrace调试技术将进程跟踪起来，暂停所有线程，逐个获取线程的函数调用链，检查函数调用链中是否存在被补丁函数。该方案不会出现方案一中程序状态不一致问题，但是一方面在检查过程中需要频繁通过ptrace系统调用读取被检测程序的数据，需要频繁在内核态和用户态之 间切换，性能比较低；另一方面需要对各线程逐个执行上述检查过程检查，如果程序的线程比较多，会比较耗时；而且检测过程中程序中的所有线程全部处于暂停状态，对程序的影响比较大。这对于那些对延时要求比较敏感的通信服务程序来说，可能是无法承受的，甚至可能会导致程序无法再正常运行。
可以看到相关技术中一致性检测方案都存在一些缺陷，要么不可靠，要被性能下降严重，可能导致打热补丁后程序无法正常运行。
如图3所示，本实施例提供了一种一致性检测方法，该方法包括但不限于以下步骤：
步骤S30：获取热补丁文件的全路径及被补丁函数的标识信息。
在一些实施例中，热补丁文件的全路径可以是用户指定的，也可以是通过系统预设等方式设置的。在完成热补丁文件的全路径设置后，获取该热补丁文件的全路径。
在一些实施例中，获取被补丁函数的标识信息包括：在源程序中查找与热补丁文件中的补丁函数的同名函数；若查找到同名函数，同名函数即为被补丁函数；获取被补丁函数的标识信息。在一些实施例中，标识信息包括被补丁函数的起始地址和大小信息。
在一些实施例中，可以通过热补丁管理线程加载热补丁文件，获取该热补丁文件中所有的补丁函数信息，进而在源程序中查找同名函数，若查找到同名函数，则为被补丁函数。记录被补丁函数的起始地址和大小信息。在一些实施例中，可能存在在源程序中查找不到热补丁文件的部门补丁函数，则说明该补丁函数为新增函数。
需要说明的是，本公开实施例中的一致性检测方法中的热补丁文件可以是采用上述实施例给出的热补丁文件生成方法所生成的热补丁文件，也可以是采用相关技术的方法所得到的热补丁文件，在此不做限定。
步骤S31：获取源程序的源程序调用栈信息。
其中，源程序调用栈信息是编译器生成的用于回溯函数调用链的辅助信息。
在一些实施例中，可以在程序初始化时加载需要打热补丁的进程(当前进程)的主程序和依赖的动态库的源程序调用栈信息。当然，也可以在需要打热补丁时，再执行获取源程序和动态库的源程序调用栈信息。本领域的技术人员也可以根据需要，合理设定其他的获取源程序的主程序和动态库的源程序调用栈信息的时机。
步骤S32：根据源程序调用栈信息，源程序的当前进程的各线程并行回溯各所述线程自身的当前函数调用链。
在一些实施例中，源程序的当前进程也即源程序的需要打热补丁的进程的各个线程可以并行执行回溯过程，这样回溯的效率较高。当然，本领域的技术人员也可以根据需要规定部分线程并行回溯部分线程逐个依次回溯，或者各个线程均逐个依次回溯。
步骤S33：遍历当前函数调用链中的每层中的线程函数，进行一致性检测。
需要说明的是，一致性检测包括根据标识信息确定所述线程的线程状态，所述线程状态包括阻塞状态或继续运行。
在一些实施例中，通过对线程进行一致性检测，检测线程函数中是否包括被补丁函数，可以得到该线程是否存在被补丁函数处于被调用的状态。
在一些实施例中，线程利用源程序调用栈信息回溯各线程自身的当前函数调用链，是对当前函数调用链中的每层函数进行回溯，进而判断每层函数中是否包括被补丁函数，而不是仅仅只检测第一层，因此，对于该线程的一致性检测是完备的。进一步的，若当前进程的各个线程的一致性检测均成功，则理论上来说可以保证后续打补丁后的程序状态一致。
在一些实施例中，根据标识信息确定线程的线程状态包括：
检测到线程函数中不包括被补丁函数，线程进入阻塞状态。
在一些实施例中，根据标识信息确定线程的线程状态包括：
检测到线程函数中包括被补丁函数，线程继续运行；
间隔预设时间，再次对线程进行一致性检测。
需要说明的是，预设时间可以是本领域技术人员根据需要合理设定的时间。预设时间也可以是参考一个线程完成检测的时间，比如一个线程完成检测需要20毫秒，那么考虑到多线程调度的问题，可以将检查时间间隔设置为30毫秒。
在一些实施例中，若源程序的当前进程的各线程中存在尚未进入阻塞状态的线程，则重复一致性检测的步骤，直到当源程序的当前进程的各线程均进入阻塞状态，源程序的一致性检测成功，结束流程。
步骤S34：根据各线程的线程状态确定一致性检测的结果。
在一些实施例中，根据各线程的线程状态确定一致性检测的结果包括：
各线程均进入阻塞状态，源程序的一致性检测成功。
需要说明的是，若线程函数中不包括被补丁函数，表明该线程通过了一致性检测，该线程当前打补丁是安全的。若源程序的所有当前进程中的线程均通过了一致性检测，则该源程序的一致性检测成功。需要说明的是，源程序的当前进程包括需要打热补丁的进程。
在一些实施例中，线程进入阻塞状态包括但不限于线程进入等待锁状态。
在一些实施例中，判断源程序的当前进程(需要打热补丁的进程)的各线程是否均进入阻塞状态包括：获取源程序的当前进程的线程数；当线程进入阻塞状态，将一个全局标志原子加1；全局标志原子与线程数相等时，源程序的当前进程的各线程均进入阻塞状态。在一些实施例中，若全局标志原子小于线程数时，则获取任意一个尚未进入阻塞状态的线程的当前已经完成的一致性检测的检测次数，若该检测次数大于预设检测次数阈值，则恢复各处于阻塞状态的线程正常运行。其中，全局标志原子初始化位置为0。需要说明的是，全局标志原子初始化位置还可以是本领域技术人员根据需要设置的其他位置，相应的，可以通过全局标志原子与源程序的当前进行的线程数的关系来判定源程序的当前进程的各 线程是否均进入阻塞状态。例如，全局标志原子初始化位置为5，当前进程的线程数为10，每有一个线程进入阻塞状态，全局标志原子加1，则当全局标志原子为15时，可以得到源程序的当前进程的各线程均进入阻塞状态。
在一些实施例中，各线程均进入阻塞状态，源程序的一致性检测成功之后，还包括：
对源程序进行打热补丁的操作；
完成打热补丁的操作后，恢复所有线程的运行。
也即，当源程序的一致性检测成功后，才对该源程序进行打热补丁的操作，这样可以保证打补丁后程序状态一致，提升了热补丁技术的可靠性。
需要说明的是，完成打热补丁的操作包括以下至少之一：当前进程的所有线程中的被补丁函数均完成函数替换；有新增函数，完成了函数新增。在一些实施例中，完成打热补丁的操作后，提示打补丁成功。
在一些实施例中，根据各线程的线程状态确定一致性检测的结果包括：
若存在线程未处于阻塞状态，获取线程的一致性检测的检测次数；
若检测次数大于预设检测次数阈值，恢复各处于阻塞状态的线程正常运行；
源程序的一致性检测失败。
在一些实施例中，有时可能由于程序业务繁忙，至少一个线程经历过预设检测次数阈值的次数的一致性检测时，该线程中的线程函数中仍然包括被补丁函数，则为了提升用户体验，可以提示用户一致性检测失败，稍后重试，并将已经阻塞的进程中的其他线程恢复正常运行。
在一些实施例中，若某源程序的当前进程一致性检测失败，则可以在接收到下次打热补丁的指令后再次进行一致性检测。其中，下次打热补丁的指令的发出方式包括但不限于：间隔一定时间后自动下发的、是由用户通过相关设备发出的。
预设检测次数阈值可以是本领域技术人员结合实际的使用场景所设定的一个合理的数值。
在一些实施例中，若源程序的一致性检测失败，清理不再使用的资源，该不再使用的资源包括调用栈信息。
在一些实施例中，根据各线程的线程状态确定一致性检测的结果之后，还包括：
清理源程序调用栈信息。
在一些实施例中，一致性检测方法还包括：完成打热补丁的操作后，清理不再使用的资源，该不再使用的资源包括源程序调用栈信息。
在一些实施例中，一致性检测失败后，清理不再使用的资源，该不再使用的资源包括源程序调用栈信息。
在一些实施例中，获取源程序的源程序调用栈信息之后，还包括：
向各线程发送信号，信号为非专用信号；
线程接收到信号后，根据源程序调用栈信息，源程序的当前进程的各线程并 行回溯各线程自身的当前函数调用链。
需要说明的是，信号为非专用信号，非专用信号包括SIGUSR1,SIGUSR2,以及实时信号。
需要说明的是，当前进程包括需要打热补丁的源程序的进程。
在一些实施例中，信号为常用信号或者实时信号，例如SIGUSRI、SIG44等常用且非专用信号。
在一些实施例中，根据标识信息确定线程的线程状态包括：
获取被补丁函数的识别信息，识别信息包括主程序标识或动态库标识；
源程序调用栈信息包括源程序的主程序调用栈信息和源程序的动态库调用栈信息；
根据主程序调用栈信息，源程序的当前进程的主程序的各线程并行回溯各线程自身的当前函数调用链；
根据动态库调用栈信息，源程序的当前进程的动态库的各线程并行回溯各线程自身的当前函数调用链；
根据识别信息包括主程序标识的被补丁函数的标识信息确定主程序的线程的线程状态；
根据识别信息包括动态库标识的被补丁函数的标识信息确定动态库的线程的线程状态。
其中，被补丁函数的识别信息用于区分该被补丁函数对应的是源程序的主程序还是源程序的动态库。其可以通过与该被补丁函数所对应的补丁函数的识别信息得到，被补丁函数的识别信息与补丁函数的识别信息相同。例如，该被补丁函数所对应的补丁函数的识别信息为主程序标识，则该被补丁函数的识别信息也是主程序标识。同理，该被补丁函数所对应的补丁函数的识别信息为动态库标识，则该被补丁函数的识别信息也是动态库标识
由于被补丁函数的识别信息可以将被补丁函数分类为对应主程序的被补丁函数和对应动态库的被补丁函数，因此，可以缩小确定线程状态时，比对的范围，提升确定线程状态的速率和准确度。
参见图4，下面以针对于源程序C为例具体说明本一致性检测方法的实际应用。
步骤S40：获取被补丁函数的标识信息和热补丁文件的全路径。
具体地，通过用户指定需要打的热补丁文件全路径，进而获取热补丁文件的全路径。热补丁管理线程加载热补丁文件并获取其中所有的补丁函数信息。在源程序中查找各补丁函数的同名函数，若找到同名函数则该源程序中的同名函数为被补丁函数，若找不到补丁函数的同名函数，则说明该补丁函数为新增函数。记录被补丁函数的起始地址和大小信息。
步骤S41：加载进程主程序和动态库的主程序调用栈信息和动态库调用栈信息。
具体地，程序初始化时加载进程的主程序的主程序调用栈信息和依赖的动态库的动态库调用栈信息，该主程序调用栈信息和动态库调用栈信息为编译器生成的用于回溯函数调用链的辅助信息。主程序调用栈信息和动态库调用栈信息构成了源程序的源程序调用栈信息。
步骤S42：获取当前线程数并给各线程发送信号。
具体地，热补丁管理线程获取当前进程的线程数，并给每个线程发送一个信号，该信号为常用信号或者实时信号，比如SIGUSR1，SIG44等常用且非专用信号。
步骤S43：各线程收到信号后回溯自己的当前函数调用链，并检测当前函数调用链中是否存在被补丁函数。检测不存在被补丁函数，该线程阻塞等待；检测存在被补丁函数，该线程继续运行。
具体地，各线程收到信号后根据源程序调用栈信息回溯自己当前函数调用链，然后，各线程遍历自己回溯得到的当前函数调用链中的每层中的线程函数，根据标识信息检测当前函数调用链中是否存在步骤S40中得到的被补丁函数，如果不存在被补丁函数则检测通过，将一个全局标志原子加一，然后进入等待锁状态；如果存在被补丁函数则检测失败，线程继续执行。
在一些实施例中，可以获取被补丁函数的识别信息，该识别信息包括主程序标识或动态库标识，获取识别信息为主程序标识的被补丁函数的标识信息，主程序的线程收到信号后，利用主程序调用栈信息回溯自己的当前函数调用链，然后，主程序的各线程遍历该当前函数调用链中的每层中的线程函数，根据获取识别信息为主程序标识的被补丁函数的标识信息检测该当前函数调用链中是否存在步骤S40中得到的被补丁函数，如果不存在被补丁函数则检测通过，将一个全局标志原子加一，然后进入等待锁状态；如果存在被补丁函数则检测失败，线程继续执行。获取识别信息为动态库标识的被补丁函数的标识信息，动态库的线程收到信号后，利用动态库调用栈信息回溯自己的当前函数调用链，然后，动态库的各线程遍历该当前函数调用链中的每层中的线程函数，根据获取识别信息为动态库标识的被补丁函数的标识信息检测该当前函数调用链中是否存在步骤S40中得到的被补丁函数，如果不存在被补丁函数则检测通过，将一个全局标志原子加一，然后进入等待锁状态；如果存在被补丁函数则检测失败，线程继续执行。
步骤S44：判断所有线程是否都处于等待锁状态，若是，则执行步骤S45；若否，执行步骤S46。
步骤S45：进行函数替换并恢复所有线程的运行，执行步骤S47。
步骤S46：判断检测册数是否大于预设检测次数阈值，若否，则执行步骤S42；若是，则执行步骤S47。
步骤S47：结束。
在一些实施例中，热补丁管理线程每隔预设时间检测全局标志的值是否等于当前除热补丁管理线程外的其他线程数，如果相等则检测通过，则进行函数替换， 提示打补丁成功，恢复所有其他线程的运行，清理不再使用的资源，如源程序调用栈信息。如全局标志的值是否不等于当前除热补丁管理线程外的其他线程数，则检测不通过，再判断是否大于预设检测次数阈值，如果没有大于预设检测次数阈值就继续等待进行下一次检测。如果大于预设检测次数阈值，则结束流程。提示打补丁失败，恢复其他线程的运行。清理不再使用的资源，如源程序调用栈信息。其中，预设时间的选择可以参考一个线程完成检测的时间，假设一个线程完成检测需要20毫秒，那么考虑到多线程的调度问题，可以将预设时间设置为30毫秒。当提示打补丁失败后，可以间隔一定时间后，提示用户重试一致性检测。
在一些实施例中，本公开实施例提供的一种一致性检测方法可以应用于C/C++语言编写的linux用户态软件的热补丁技术领域，提供了一种linux用户态程序热补丁解决方案。
在一些实施例中，本公开实施例提供的一种一致性检测方法应用于针对X8664体系架构C/C++语言编写的linux用户态软件的热补丁技术领域。
本公开实施例提供的一致性检测方法由于各线程自行回溯自己的当前函数调用链，一方面不需要依赖内核提供的ptrace调试技术，避免了用户态和内核态之间的频繁切换；另外一方面各线程可并行执行回溯过程而不是逐个依次回溯。综合性能相比使用ptrace调试技术的方案有质的提升，降低了回溯时间，对程序的影响相对较小。另外，本公开实施例中的一致性检测方法通过检测各线程函数调用链中的每层中的线程函数是否为被补丁函数，而不是仅仅只检测第一层，所以一致性检测是完备的，只要各线程都检测通过，就一定能保证打补丁后程序状态一致，提升了热补丁技术的可靠性。
实施例三
如图5所示，本公开实施例还提供了一种热补丁文件生成装置，热补丁文件生成装置500包括：
第一获取模块501，设置为获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件，所述第一目标文件和所述第二目标文件分别为所述第一工程与所述第二工程对应存储节点上存在差异的文件；
第二获取模块502，设置为获取生成所述第一目标文件的第一源文件名、生成所述第二目标文件的第二源文件名；
第三获取模块503，设置为获取第一主程序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表，所述第一主程序和所述第一动态库归属于所述第一工程，所述第二主程序和所述第二动态库归属于所述第二工程；
第一确定模块504，设置为确定所述第一目标文件、所述第二目标文件的归属信息，所述归属信息根据所述第一源文件名、所述第二源文件名、所述第一主程序源文件列表、所述第二主程序源文件列表、所述第一动态库源文件列表、所 述第二动态库源文件列表确定，所述归属信息包括以下任意之一：归属于第一动态库、归属于第二动态库、归属于第一主程序、归属于第二主程序；
第四获取模块505，设置为获取主程序差异函数，生成第一中间热补丁文件，所述第一中间热补丁文件包括识别信息，所述标识信息包括主程序标识，所述主程序差异函数包括对应节点上归属于第一主程序的第一目标文件与归属于第二主程序的第二目标文件中存在差异的函数；
第五获取模块506，设置为获取动态库差异函数，生成第二中间热补丁文件，所述第二中间热补丁文件包括识别信息，所述标识信息包括动态库标识，所述动态库差异函数包括对应节点上归属于第一动态库的第一目标文件与归属于第二动态库的第二目标文件中存在差异的函数；
封装模块507，设置为封装所述第一中间热补丁文件与所述第二中间热补丁文件，生成热补丁文件。
需要说明的是，本实施例所提供的热补丁文件生成装置包括其他模块，以能够实现上述各实施例中所述的热补丁文件生成方法的步骤，具体各模块的各功能可参见上述热补丁文件生成方法实施例中的描述，在此不再赘述。
本实施例提供的热补丁文件生成装置，最终生成一个热补丁文件，该热补丁文件由归属于动态库的第二中间热补丁文件和归属于主程序的第一中间热补丁文件封装而成，第一、第二中间热补丁文件中记录了识别信息。可以得到第一、二中间热补丁文件中各补丁函数所对应的是源程序的主程序还是动态库。一方面热补丁生成过程可以采用自动化完成，不需要制作人员了解程序的细节，只需要知道如何构建目标工程，在构建修改前后的第一、二工程完成后，剩余的步骤借助自动化的方式来实现，提升了热补丁文件生成的效率，简化了人工操作的步骤，提升用户体验，打热补丁时操作人员只需指定补丁文件即可，不需要了解程序和补丁的细节。易用性非常高且不会因为操作人员的原因而导致错误，提升热补丁技术的可靠性；另一方面生成的热补丁文件中记录了每个补丁函数的识别信息，可以知晓该函数对应的是需要打补丁的源程序的主程序还是动态库，降低了源文件的主程序和动态库存在有相同函数时，由于不知晓补丁函数的识别信息，进而不能准确确定被补丁函数，导致打补丁失败或打补丁错误的风险。
实施例四
如图6所示，本公开实施例还提供了一种一致性检测装置，一致性检测装置600包括：
第六获取模块601，设置为获取热补丁文件的全路径及被补丁函数的标识信息；
第七获取模块602，设置为获取源程序的源程序调用栈信息；
并行回溯模块603，设置为根据所述源程序调用栈信息，所述源程序的当前进程的各线程并行回溯各所述线程自身的当前函数调用链；
检测模块604，设置为遍历所述当前函数调用链中的每层中的线程函数，进行一致性检测，所述一致性检测包括根据所述标识信息确定所述线程的线程状态，所述线程状态包括阻塞状态或继续运行；
第二确定模块605，设置为根据各所述线程的所述线程状态确定所述一致性检测的结果。
需要说明的是，本实施例所提供的一致性检测装置包括其他模块，以能够实现上述各实施例中所述的一致性检测方法的步骤，具体各模块的各功能可参见上述一致性检测方法实施例中的描述，在此不再赘述。
本公开实施例提供的一致性检测装置，由于各线程自行回溯自己的当前函数调用链，一方面不需要依赖内核提供的ptrace调试技术，避免了用户态和内核态之间的频繁切换；另外一方面各线程可并行执行回溯过程而不是逐个依次回溯。综合性能相比使用ptrace调试技术的方案有质的提升。另外，本公开实施例中的一致性检测装置通过检测各线程函数调用链中的每层中的线程函数是否为被补丁函数，而不是仅仅只检测第一层，所以一致性检测是完备的，只要各线程都检测通过，就一定能保证打补丁后程序状态一致，提升了热补丁技术的可靠性。
实施例五
如图7所示，本公开实施例还提供了一种第一设备700，第一设备700包括第一存储器701、第一处理器702、存储在第一存储器701上并可在第一处理器702上运行的第一程序以及设置为实现第一处理器702和第一存储器701之间的连接通信的第一数据总线703，第一程序被第一处理器702执行时实现如上述任一项实施例的热补丁文件生成方法的步骤。
本实施例提供的第一设备，最终生成一个热补丁文件，该热补丁文件由归属于动态库的第二中间热补丁文件和归属于主程序的第一中间热补丁文件封装而成，第一、二中间热补丁文件中记录了识别信息，可以知晓该函数对应的是需要打补丁的源程序的主程序还是动态库，降低了源文件的主程序和动态库存在有相同函数时，由于不知晓补丁函数的识别信息，进而不能准确确定被补丁函数，导致打补丁失败或打补丁错误的风险。热补丁生成过程可以采用自动化完成，不需要制作人员了解程序的细节，只需要知道如何构建目标工程，在构建修改前后的工程后，剩余的步骤借助自动化的方式来实现，提升了热补丁文件生成的效率，简化了人工操作的步骤，提升用户体验，生成的热补丁文件中记录了每个被补丁函数的归属信息，打热补丁时操作人员只需指定补丁文件即可，不需要了解程序和补丁的细节。易用性非常高且不会因为操作人员的原因而导致错误，提升热补丁技术的可靠性。
实施例六
如图8所示，本公开实施例还提供了一种第二设备800，第二设备包括第二存储器801、第二处理器802、存储在第二存储器801上并可在第二处理器802上运行的第二程序以及设置为实现第二处理器802和第二存储器801之间的连接通信的第二数据总线803，第二程序被第二处理器802执行时实现如上述任一项实施例的一致性检测方法的步骤。
本公开实施例提供的第二设备，由于各线程自行回溯自己的当前函数调用链，一方面不需要依赖内核提供的ptrace调试技术，避免了用户态和内核态之间的频繁切换；另外一方面各线程可并行执行回溯过程而不是逐个依次回溯。综合性能相比使用ptrace调试技术的方案有质的提升。另外，本公开实施例中的一致性检测方法通过检测各线程函数调用链中的每层中的线程函数是否为被补丁函数，而不是仅仅只检测第一层，所以一致性检测是完备的，只要各线程都检测通过，就一定能保证打补丁后程序状态一致，提升了热补丁技术的可靠性。
本公开实施例还提供了一种存储介质，设置为计算机可读存储，存储介质存储有一个或者多个第一程序，一个或者多个第一程序可被一个或者多个第一处理器执行，以实现上述任一项实施例的热补丁文件生成方法的步骤；
或，
存储介质存储有一个或者多个第二程序，一个或者多个第二程序可被一个或者多个第二处理器执行，以实现上述任一项实施例的一致性检测方法的步骤。
本领域普通技术人员可以理解，上文中所公开方法中的全部或某些步骤、系统、设备中的功能模块/单元可以被实施为软件、固件、硬件及其适当的组合。
在硬件实施方式中，在以上描述中提及的功能模块/单元之间的划分不一定对应于物理组件的划分；例如，一个物理组件可以具有多个功能，或者一个功能或步骤可以由若干物理组件合作执行。某些物理组件或所有物理组件可以被实施为由处理器，如中央处理器、数字信号处理器或微处理器执行的软件，或者被实施为硬件，或者被实施为集成电路，如专用集成电路。这样的软件可以分布在计算机可读介质上，计算机可读介质可以包括计算机存储介质(或非暂时性介质)和通信介质(或暂时性介质)。如本领域普通技术人员公知的，术语计算机存储介质包括在设置为存储信息(诸如计算机可读指令、数据结构、程序模块或其他数据)的任何方法或技术中实施的易失性和非易失性、可移除和不可移除介质。计算机存储介质包括但不限于RAM、ROM、EEPROM、闪存或其他存储器技术、CD-ROM、数字多功能盘(DVD)或其他光盘存储、磁盒、磁带、磁盘存储或其他磁存储装置、或者可以设置为存储期望的信息并且可以被计算机访问的任何其他的介质。此外，本领域普通技术人员公知的是，通信介质通常包含计算机可读指令、数据结构、程序模块或者诸如载波或其他传输机制之类的调制数据信号中的其他数据，并且可包括任何信息递送介质。
以上参照附图说明了本公开的可选实施例，并非因此局限本公开的权利范围。本领域技术人员不脱离本公开的范围和实质内所作的任何修改、等同替换和改进， 均应在本公开的权利范围之内。

Claims (21)

  1. 一种热补丁文件生成方法，所述热补丁文件生成方法包括：
    获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件，所述第一目标文件和所述第二目标文件分别为所述第一工程与所述第二工程对应存储节点上存在差异的文件；
    获取生成所述第一目标文件的第一源文件名、生成所述第二目标文件的第二源文件名；
    获取第一主程序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表，所述第一主程序和所述第一动态库归属于所述第一工程，所述第二主程序和所述第二动态库归属于所述第二工程；
    确定所述第一目标文件、所述第二目标文件的归属信息，所述归属信息根据所述第一源文件名、所述第二源文件名、所述第一主程序源文件列表、所述第二主程序源文件列表、所述第一动态库源文件列表、所述第二动态库源文件列表确定，所述归属信息包括以下任意之一：归属于第一动态库、归属于第二动态库、归属于第一主程序、归属于第二主程序；
    获取主程序差异函数，生成第一中间热补丁文件，所述第一中间热补丁文件包括识别信息，所述标识信息包括主程序标识，所述主程序差异函数包括对应节点上归属于第一主程序的第一目标文件与归属于第二主程序的第二目标文件中存在差异的函数；
    获取动态库差异函数，生成第二中间热补丁文件，所述第二中间热补丁文件包括识别信息，所述标识信息包括动态库标识，所述动态库差异函数包括对应节点上归属于第一动态库的第一目标文件与归属于第二动态库的第二目标文件中存在差异的函数；
    封装所述第一中间热补丁文件与所述第二中间热补丁文件，生成热补丁文件。
  2. 根据权利要求1所述的热补丁文件生成方法，其中，所述获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件之前，还包括：
    根据调试信息的编译参数在同一目录下分别构建修改前的第一工程和修改后的第二工程，所述第一工程和所述第二工程的同名二进制文件的编译路径相同；
    所述第一目标文件和所述第二目标文件分别为所述第一工程和所述第二工程的各同名二进制文件中存在差异的文件。
  3. 根据权利要求2所述的热补丁文件生成方法，其中，所述获取生成所述第一目标文件的第一源文件名、生成所述第二目标文件的第二源文件名包括：
    解析所述第一目标文件的调试信息，得到生成所述第一源文件名；
    解析所述第二目标文件的调试信息，得到生成所述第二源文件名。
  4. 根据权利要求2所述的热补丁文件生成方法，其中，所述获取第一主程 序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表包括：
    解析所述第一主程序的调试信息，得到所述第一主程序源文件列表；
    解析所述第二主程序的调试信息，得到所述第二主程序源文件列表；
    解析所述第一动态库的调试信息，得到所述第一动态库源文件列表；
    解析所述第二动态库的调试信息，得到所述第二动态库源文件列表。
  5. 根据权利要求2所述的热补丁文件生成方法，其中，所述获取主程序差异函数，生成第一中间热补丁文件，获取动态库差异函数，生成第二中间热补丁文件包括：
    根据所述归属信息，将所述第一目标文件分别链接生成第一主程序中间文件、第一动态库中间文件；
    根据所述归属信息，将所述第二目标文件分别链接生成第二主程序中间文件、第二动态库中间文件；
    提取所述第一主程序中间文件与第二主程序中间文件中同名二进制文件中存在差异的函数作为所述主程序差异函数，根据所述主程序差异函数生成所述第一中间热补丁文件；
    提取所述第一动态库中间文件与第二动态库中间文件中同名二进制文件中存在差异的函数作为所述动态库差异函数，根据所述动态库差异函数生成所述第二中间热补丁文件。
  6. 根据权利要求5所述的热补丁文件生成方法，其中，所述根据所述归属信息，将所述第一目标文件分别链接生成第一主程序中间文件、第一动态库中间文件，根据所述归属信息，将所述第二目标文件分别链接生成第二主程序中间文件、第二动态库中间文件包括：
    对比所述第一工程和所述第二工程的工程目录，生成目标文件列表，所述目标文件列表中每个节点包括同名的所述第一目标文件的全路径名和所述第二目标文件的全路径名；
    根据所述归属信息，根据所述目标文件列表所记录的路径信息将所述第一目标文件分步链接生成第一主程序中间文件、第一动态库中间文件；
    根据所述归属信息，根据所述目标文件列表所记录的路径信息将所述第二目标文件分步链接生成第二主程序中间文件、第二动态库中间文件。
  7. 根据权利要求1至6任一项所述的热补丁文件生成方法，其中，所述热补丁文件生成方法还包括以下至少之一：
    所述热补丁文件中，所述第一中间热补丁文件和所述第二中间热补丁文件分别作为一个独立的节进行存放；
    所述热补丁文件包括主程序信息。
  8. 一种一致性检测方法，所述一致性检测方法包括：
    获取热补丁文件的全路径及被补丁函数的标识信息；
    获取源程序的源程序调用栈信息；
    根据所述源程序调用栈信息，所述源程序的当前进程的各线程并行回溯各所述线程自身的当前函数调用链；
    遍历所述当前函数调用链中的每层中的线程函数，进行一致性检测，所述一致性检测包括根据所述标识信息确定所述线程的线程状态，所述线程状态包括阻塞状态或继续运行；
    根据各所述线程的所述线程状态确定所述一致性检测的结果。
  9. 根据权利要求8所述的一致性检测方法，其中所述根据所述标识信息确定所述线程的线程状态包括：
    检测到所述线程函数中不包括所述被补丁函数，所述线程进入阻塞状态。
  10. 根据权利要求9所述的一致性检测方法，其中，所述根据各所述线程的所述线程状态确定所述一致性检测的结果包括：
    各所述线程均进入阻塞状态，所述源程序的一致性检测成功。
  11. 根据权利要求10所述的一致性检测方法，其中，所述各所述线程均进入阻塞状态，所述源程序的一致性检测成功之后，还包括：
    对所述源程序进行打热补丁的操作；
    完成所述打热补丁的操作后，恢复所有所述线程的运行。
  12. 根据权利要求8所述的一致性检测方法，其中，所述根据所述标识信息确定所述线程的线程状态包括：
    检测到所述线程函数中包括被补丁函数，所述线程继续运行；
    间隔预设时间，再次对所述线程进行所述一致性检测。
  13. 根据权利要求12所述的一致性检测方法，其中，所述根据各所述线程的所述线程状态确定所述一致性检测的结果包括：
    若存在所述线程未处于阻塞状态，获取所述线程的一致性检测的检测次数；
    若所述检测次数大于预设检测次数阈值，恢复各处于阻塞状态的所述线程正常运行；
    所述源程序的一致性检测失败。
  14. 根据权利要求8至13任一项所述的一致性检测方法，其中，所述获取源程序的源程序调用栈信息之后，还包括：
    向各所述线程发送信号，所述信号为非专用信号；
    所述线程接收到所述信号后，根据所述源程序调用栈信息，所述源程序的当前进程的各线程并行回溯各所述线程自身的当前函数调用链。
  15. 根据权利要求8至13任一项所述的一致性检测方法，其中，所述根据所述标识信息确定所述线程的线程状态包括：
    获取所述被补丁函数的识别信息，所述识别信息包括主程序标识或动态库标识；
    所述源程序调用栈信息包括所述源程序的主程序调用栈信息和所述源程序 的动态库调用栈信息；
    根据所述主程序调用栈信息，所述源程序的当前进程的主程序的各线程并行回溯各所述线程自身的当前函数调用链；
    根据所述动态库调用栈信息，所述源程序的当前进程的动态库的各线程并行回溯各所述线程自身的当前函数调用链；
    根据所述识别信息包括主程序标识的所述被补丁函数的所述标识信息确定所述主程序的所述线程的线程状态；
    根据所述识别信息包括动态库标识的所述被补丁函数的所述标识信息确定所述动态库的所述线程的线程状态。
  16. 根据权利要求8至13任一项所述的一致性检测方法，其中，所述根据各所述线程的所述线程状态确定所述一致性检测的结果之后，还包括：
    清理所述源程序调用栈信息。
  17. 一种热补丁文件生成装置，所述热补丁文件生成装置包括：
    第一获取模块，设置为获取修改前的第一工程中的第一目标文件、修改后的第二工程中的第二目标文件，所述第一目标文件和所述第二目标文件分别为所述第一工程与所述第二工程对应存储节点上存在差异的文件；
    第二获取模块，设置为获取生成所述第一目标文件的第一源文件名、生成所述第二目标文件的第二源文件名；
    第三获取模块，设置为获取第一主程序的第一主程序源文件列表、第一动态库的第一动态库源文件列表、第二主程序的第二主程序源文件列表、第二动态库的第二动态库源文件列表，所述第一主程序和所述第一动态库归属于所述第一工程，所述第二主程序和所述第二动态库归属于所述第二工程；
    第一确定模块，设置为确定所述第一目标文件、所述第二目标文件的归属信息，所述归属信息根据所述第一源文件名、所述第二源文件名、所述第一主程序源文件列表、所述第二主程序源文件列表、所述第一动态库源文件列表、所述第二动态库源文件列表确定，所述归属信息包括以下任意之一：归属于第一动态库、归属于第二动态库、归属于第一主程序、归属于第二主程序；
    第四获取模块，设置为获取主程序差异函数，生成第一中间热补丁文件，所述第一中间热补丁文件包括识别信息，所述标识信息包括主程序标识，所述主程序差异函数包括对应节点上归属于第一主程序的第一目标文件与归属于第二主程序的第二目标文件中存在差异的函数；
    第五获取模块，设置为获取动态库差异函数，生成第二中间热补丁文件，所述第二中间热补丁文件包括识别信息，所述标识信息包括动态库标识，所述动态库差异函数包括对应节点上归属于第一动态库的第一目标文件与归属于第二动态库的第二目标文件中存在差异的函数；
    封装模块，设置为封装所述第一中间热补丁文件与所述第二中间热补丁文件，生成热补丁文件。
  18. 一种一致性检测装置，所述一致性检测装置包括：
    第六获取模块，设置为获取热补丁文件的全路径及被补丁函数的标识信息；
    第七获取模块，设置为获取源程序的源程序调用栈信息；
    并行回溯模块，设置为根据所述源程序调用栈信息，所述源程序的当前进程的各线程并行回溯各所述线程自身的当前函数调用链；
    检测模块，设置为遍历所述当前函数调用链中的每层中的线程函数，进行一致性检测，所述一致性检测包括根据所述标识信息确定所述线程的线程状态，所述线程状态包括阻塞状态或继续运行；
    第二确定模块，设置为根据各所述线程的所述线程状态确定所述一致性检测的结果。
  19. 一种第一设备，所述第一设备包括第一存储器、第一处理器、存储在所述第一存储器上并可在所述第一处理器上运行的第一程序以及设置为实现所述第一处理器和所述第一存储器之间的连接通信的第一数据总线，所述第一程序被所述第一处理器执行时实现如权利要求1至7任一项所述的热补丁文件生成方法的步骤。
  20. 一种第二设备，所述第二设备包括第二存储器、第二处理器、存储在所述第二存储器上并可在所述第二处理器上运行的第二程序以及设置为实现所述第二处理器和所述第二存储器之间的连接通信的第二数据总线，所述第二程序被所述第二处理器执行时实现如权利要求8至16任一项所述的一致性检测方法的步骤。
  21. 一种介质，设置为计算机可读存储，所述存储介质存储有一个或者多个第一程序，所述一个或者多个第一程序可被一个或者多个第一处理器执行，以实现权利要求1至7中任一项所述的热补丁文件生成方法的步骤；
    或，
    所述存储介质存储有一个或者多个第二程序，所述一个或者多个第二程序可被一个或者多个第二处理器执行，以实现权利要求8至16中任一项所述的一致性检测方法的步骤。
PCT/CN2021/099526 2020-06-12 2021-06-10 热补丁文件生成、一致性检测方法、装置、设备和介质 WO2021249518A1 (zh)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
CN202010534121.XA CN113805928A (zh) 2020-06-12 2020-06-12 热补丁文件生成、一致性检测方法、装置、设备和介质
CN202010534121.X 2020-06-12

Publications (1)

Publication Number Publication Date
WO2021249518A1 true WO2021249518A1 (zh) 2021-12-16

Family

ID=78846885

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/CN2021/099526 WO2021249518A1 (zh) 2020-06-12 2021-06-10 热补丁文件生成、一致性检测方法、装置、设备和介质

Country Status (2)

Country Link
CN (1) CN113805928A (zh)
WO (1) WO2021249518A1 (zh)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115964065A (zh) * 2022-12-28 2023-04-14 天翼云科技有限公司 一种用于管理虚拟机监视器进程热补丁的方法及装置
US20230305868A1 (en) * 2022-03-23 2023-09-28 Microsoft Technology Licensing, Llc Changing program behavior at runtime

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115687159B (zh) * 2022-12-29 2023-03-21 飞腾信息技术有限公司 调试方法、装置及计算机可读存储介质

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8468516B1 (en) * 2008-12-19 2013-06-18 Juniper Networks, Inc. Creating hot patches for embedded systems
US8607208B1 (en) * 2008-10-01 2013-12-10 Oracle International Corporation System and methods for object code hot updates
CN105159738A (zh) * 2015-08-20 2015-12-16 上海斐讯数据通信技术有限公司 一种热补丁实现方法及系统
CN105630557A (zh) * 2015-12-24 2016-06-01 迈普通信技术股份有限公司 热补丁方法和装置
CN106796522A (zh) * 2015-01-22 2017-05-31 华为技术有限公司 用于更新源代码文件的系统和方法
CN110851168A (zh) * 2019-11-15 2020-02-28 腾讯科技（深圳）有限公司 数据处理方法及其装置、计算机可读存储介质

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8607208B1 (en) * 2008-10-01 2013-12-10 Oracle International Corporation System and methods for object code hot updates
US8468516B1 (en) * 2008-12-19 2013-06-18 Juniper Networks, Inc. Creating hot patches for embedded systems
CN106796522A (zh) * 2015-01-22 2017-05-31 华为技术有限公司 用于更新源代码文件的系统和方法
CN105159738A (zh) * 2015-08-20 2015-12-16 上海斐讯数据通信技术有限公司 一种热补丁实现方法及系统
CN105630557A (zh) * 2015-12-24 2016-06-01 迈普通信技术股份有限公司 热补丁方法和装置
CN110851168A (zh) * 2019-11-15 2020-02-28 腾讯科技（深圳）有限公司 数据处理方法及其装置、计算机可读存储介质

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20230305868A1 (en) * 2022-03-23 2023-09-28 Microsoft Technology Licensing, Llc Changing program behavior at runtime
CN115964065A (zh) * 2022-12-28 2023-04-14 天翼云科技有限公司 一种用于管理虚拟机监视器进程热补丁的方法及装置

Also Published As

Publication number Publication date
CN113805928A (zh) 2021-12-17

Similar Documents

Publication Publication Date Title
WO2021249518A1 (zh) 热补丁文件生成、一致性检测方法、装置、设备和介质
US11281570B2 (en) Software testing method, system, apparatus, device medium, and computer program product
KR100868762B1 (ko) 임베디드용 소프트웨어의 오류 검출 방법
US9032371B2 (en) Method and apparatus for automatic diagnosis of software failures
US10509693B2 (en) Method for identifying a cause for a failure of a test
US9921948B2 (en) Software commit risk level
CN105988798B (zh) 补丁处理方法及装置
US20060107121A1 (en) Method of speeding up regression testing using prior known failures to filter current new failures when compared to known good results
US9619356B2 (en) Detection of hardware errors using periodically synchronized redundant transactions and comparing results from cores of a multi-core processor
US8327191B2 (en) Automatically populating symptom databases for software applications
US9317254B1 (en) Fault tolerance model, methods, and apparatuses and their validation techniques
CN111240980A (zh) 一种基于云管平台的自动回归测试方法
CN111831554B (zh) 一种代码检查方法及装置
JP2015011372A (ja) デバッグ支援システム、方法、プログラム及び記録媒体
CN110990289B (zh) 一种自动提交bug的方法、装置、电子设备及存储介质
CN115034173A (zh) 芯片仿真模型的测试方法
CN112506802B (zh) 测试数据的管理方法及系统
US11132286B1 (en) Dynamic reordering of test case execution
US11086768B1 (en) Identifying false positives in test case failures using combinatorics
CN116610575A (zh) 一种软件测试的方法、装置及电子设备
CN113760340B (zh) 一种应用于Linux系统的热补丁方法和装置
CN114253846B (zh) 自动化测试异常定位方法、装置、设备及可读存储介质
CN114356643B (zh) 一种遥感卫星处理系统中自动发现任务失败和恢复方法
JP5181699B2 (ja) コンピュータ試験方法，プログラムおよび情報処理装置
CN114116468A (zh) 一种应用测试方法、装置、电子设备及存储介质

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21822406

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

32PN Ep: public notification in the ep bulletin as address of the adressee cannot be established

Free format text: NOTING OF LOSS OF RIGHTS PURSUANT TO RULE 112(1) EPC (EPO FORM 1205 DATED 22/05/2023)

122 Ep: pct application non-entry in european phase

Ref document number: 21822406

Country of ref document: EP

Kind code of ref document: A1