Hot patch file generation, consistency detection method, device, equipment and medium

Abstract

Embodiments of the present application disclose a hot patch file generation method, a consistency detection method, a device, equipment and a medium. The hot patch file generation method comprises the following steps: obtaining a first target file and a second target file in a first process and a second process; obtaining source file names of the first target file and the second target file; obtaining a first main program source file list and a first dynamic library source file list corresponding to a first main program and a first dynamic library respectively; obtaining a second main program source file list and a second dynamic library source file list corresponding to a second main program and a second dynamic library respectively; determining attribution information of the first target file and the second target file according to the obtained source file names and the source file lists; generating a first intermediate hot patch file and a second intermediate hot patch file including identification information; and finally obtaining a hot patch file. The hot patch file includes identification information, so that it can be determined whether each patch function corresponds to a main program or a dynamic library, the patched function can be accurately obtained, and the hot patch file is easy to use. Embodiments of the present application further provide a consistency detection method and device, a consistency detection method, a hot patch file generation device, equipment and a medium, and the reliability of the hot patch technology is improved.

Description

TECHNICAL FIELD

[0001] The embodiment of the present application relates to the technical field of hot patching technology of C / C++ language written linux user mode software, and particularly relates to a hot patching file generation, consistency detection method, device and medium. BACKGROUND

[0002] In the communication field, it is very important to ensure the continuity of services, and it is necessary to repair faults online instead of restarting programs when the programs have faults. The technology of repairing faults online is usually called hot patching technology, which replaces the running patched function (the function with faults) into the patching function (the function after repairing faults) to achieve the purpose of repairing faults without restarting programs. The hot patching technology basically modifies the instruction at the entrance of the patched function into the jump instruction jumping to the entrance of the patching function to achieve the function replacement purpose.

[0003] Since a general program is composed of a main program and dependent dynamic libraries, there may be functions with the same name in the main program and the dynamic libraries, and how to accurately obtain the patched function is the premise of correctly patching the program. For example, if function A is to be patched, more than one function named A may be defined in the dependent dynamic libraries, and finding the wrong function will cause the program to crash. The common method in the industry is to require the patching personnel to specify the ownership information (the main program or the dynamic library) of the patched function when patching, or to require the patching personnel to record the ownership information of the patched function in the patching file when making the patching. However, neither the patching personnel nor the patching personnel is necessarily the developer, and may not be clear about the ownership information of the patched function, so that this method is not easy to use, is prone to errors, and the reliability of the hot patching technology is not high. SUMMARY

[0004] The main purpose of the embodiment of the present application is to provide a hot patching file generation, consistency detection method, device, equipment and medium, which aims to solve the problem that the patched function cannot be accurately obtained in the hot patching technology, so that the hot patching technology is not easy to use, is prone to errors, and the reliability is not high.

[0005] To achieve the above purpose, the embodiment of the present application provides a hot patching file generation method, which comprises:

[0006] Obtaining a first target file in a first project before modification and a second target file in a second project after modification, the first target file and the second target file being respectively files existing differences on the storage nodes corresponding to the first project and the second project;

[0007] Obtaining a first source file name for generating the first target file and a second source file name for generating the second target file;

[0008] 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 dynamic library source file list of the second 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 second project.

[0009] The ownership information of the first target file and the second target file is determined. The ownership information is determined 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, the first dynamic library source file list, and the second dynamic library source file list. The ownership information includes any one of the following: belonging to the first dynamic library, belonging to the second dynamic library, belonging to the first main program, and belonging to the second main program.

[0010] Obtain the main program difference function and generate a first intermediate hot patch file. The first intermediate hot patch file includes identification information, which includes the main program identifier. The main program difference function includes functions that differ 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.

[0011] Obtain the dynamic library difference function and generate a second intermediate hot patch file. The second intermediate hot patch file includes identification information, which includes a dynamic library identifier. The dynamic library difference function includes functions that differ 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.

[0012] The first intermediate hot patch file and the second intermediate hot patch file are packaged together to generate a hot patch file.

[0013] To achieve the above objectives, embodiments of the present invention also propose a consistency detection method, the consistency detection method comprising:

[0014] Obtain the full path of the hot patch file and the identification information of the patched function;

[0015] Obtain the source program call stack information;

[0016] Based on the source program call stack information, each thread of the current process of the source program backtracks its own current function call chain in parallel.

[0017] Traverse the thread functions in each layer of the current function call chain and perform consistency checks. The consistency checks include determining the thread state of the thread based on the identification information. The thread state includes a blocked state or continued execution.

[0018] The result of the consistency check is determined based on the thread state of each thread.

[0019] To achieve the above objectives, the present invention provides a hot patch file generation apparatus, the hot patch file generation apparatus comprising:

[0020] The first acquisition module is used to acquire 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 that differ on the corresponding storage nodes of the first project and the second project, respectively.

[0021] The second acquisition module is used to acquire the first source file name for generating the first target file and the second source file name for generating the second target file;

[0022] The third acquisition module is used 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 source file list of the second 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 second project.

[0023] The first determining module is used to determine the ownership information of the first target file and the second target file. The ownership information is determined 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, the first dynamic library source file list, and the second dynamic library source file list. The ownership information includes any one of the following: belonging to the first dynamic library, belonging to the second dynamic library, belonging to the first main program, and belonging to the second main program.

[0024] The fourth acquisition module is used to acquire the main program difference functions and generate a first intermediate hot patch file. The first intermediate hot patch file includes identification information, which includes the main program identifier. The main program difference functions include functions that differ 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.

[0025] The fifth acquisition module is used to acquire dynamic library difference functions 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 functions include functions that differ 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.

[0026] The encapsulation module is used to encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate a hot patch file.

[0027] To achieve the above objectives, the present invention provides a consistency detection device, the consistency detection device comprising:

[0028] The sixth module is used to obtain the full path of the hot patch file and the identification information of the patched function;

[0029] The seventh module is used to obtain the source program call stack information;

[0030] The parallel backtracking module is used to backtrack the current function call chain of each thread in the current process of the source program in parallel, based on the source program call stack information.

[0031] The detection module is used to traverse the thread functions in each layer of the current function call chain and perform consistency detection. The consistency detection includes determining the thread state of the thread based on the identification information. The thread state includes a blocked state or continued running.

[0032] The second determining module is used to determine the result of the consistency detection based on the thread state of each thread.

[0033] To achieve the above objectives, the present invention provides a first device, the first device including a first memory, a first processor, a first program stored on the first memory and executable on the first processor, and a first data bus for implementing connection communication between the first processor and the first memory, wherein when the first program is executed by the first processor, it implements the steps of the hot patch file generation method as described in any of the above embodiments.

[0034] To achieve the above objectives, the present invention provides a second device, the second device including a second memory, a second processor, a second program stored in the second memory and executable on the second processor, and a second data bus for implementing connection communication between the second processor and the second memory, wherein the second program, when executed by the second processor, implements the steps of the consistency detection method as described in any of the above embodiments.

[0035] To achieve the above objectives, the present invention provides a medium for computer-readable storage, wherein the storage medium stores one or more first programs, which can be executed by one or more first processors to implement the steps of the hot patch file generation method described in any of the above embodiments;

[0036] or,

[0037] The storage medium stores one or more second programs, which can be executed by one or more second processors to implement the steps of the consistency detection method described in any of the above embodiments.

[0038] This invention proposes a hot patch file generation and consistency detection method, apparatus, device, and medium. The hot patch file generation method involves obtaining a first target file from a first project before modification and a second target file from a second project after modification, wherein the first and second target files are files that differ on the corresponding storage nodes of the first and second projects, respectively. The method further involves obtaining the first source filename for generating the first target file and the second source filename for generating the second target file. It also involves obtaining a list of source files for the first main program, the first dynamic library, the second main program, and the second dynamic library, wherein 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. Finally, the method determines the ownership information of the first and second target files based on the first and second source filenames, the list of source files for the first and second main programs, the list of source files for the second main program, the list of source files for the first dynamic library, and the list of source files for the second dynamic library. The ownership information includes any one of the following: belonging to the first dynamic library, belonging to the second dynamic library, belonging to the first main program, or belonging to the second main program. The process involves: acquiring the main program's differencing functions and generating a first intermediate hot patch file. The first intermediate hot patch file includes identification information, including a main program identifier to indicate that it corresponds to the main program. The main program's differencing functions include functions that differ between the first target file belonging to the first main program and the second target file belonging to the second main program at the corresponding node. Next, the process involves acquiring the dynamic library's differencing functions and generating a second intermediate hot patch file. The second intermediate hot patch file includes identification information, including a dynamic library identifier to indicate that it corresponds to a dynamic library. The dynamic library's differencing functions include functions that differ between the first target file belonging to the first dynamic library and the second target file belonging to the second dynamic library at the corresponding node. Finally, the first and second intermediate hot patch files are encapsulated to generate a hot patch file.By comparing the source filenames of the first and second target files with the source file lists corresponding to the first and second main programs or the first and second dynamic libraries, the attribution information of each first and second target file can be obtained. Based on this attribution information, the first and second target files are categorized. The first and second target files belonging to the first and second main programs are compared to obtain the main program's difference functions. The first and second target files belonging to the first and second dynamic libraries are compared to obtain the dynamic library's difference functions. A first intermediate hot patch file is generated based on the main program's difference functions, and the main program's identifier is recorded in the first intermediate hot patch file. A second intermediate hot patch file is generated based on the dynamic library's difference functions, and the dynamic library's identifier is recorded in the second intermediate hot patch file. Thus, in the encapsulated hot patch file, since the identification information of the patched function is the same as the identification information of the file it resides in, it is possible to know whether the patched function belongs to the main program or the dynamic library based on the file where the patched function is located. In other words, it is possible to clearly and accurately obtain information on whether each patched function belongs to the main program or the dynamic library. When applying hot patches, operators only need to specify the hot patch file. Since the identification information of the patch functions in the hot patch file is known, the function to be patched can be accurately identified. This reduces the risk of patching failure or errors when the main program and dynamic libraries in the source file have the same function, as the identification information of the patch function is unknown, leading to an inability to accurately identify the function to be patched. This operation can be automated. In this case, operators do not need to understand the details of the program and the patch, resulting in high usability and effectively avoiding errors caused by operator error, thus improving the reliability of hot patching technology. Attached Figure Description

[0039] Figure 1 This is a flowchart of a hot patch file generation method provided in Embodiment 1 of the present invention;

[0040] Figure 2 This is a flowchart illustrating a specific application example of a hot patch file generation method provided in Embodiment 1 of the present invention;

[0041] Figure 3 This is a flowchart of a consistency detection method provided in Embodiment 2 of the present invention;

[0042] Figure 4 This is a flowchart illustrating a specific application example of a consistency detection method provided in Embodiment 2 of the present invention;

[0043] Figure 5 This is a structural block diagram of a hot patch file generation device provided in Embodiment 3 of the present invention;

[0044] Figure 6 This is a structural block diagram of a consistency detection device provided in Embodiment 4 of the present invention;

[0045] Figure 7 This is a structural block diagram of a first device provided in Embodiment 5 of the present invention;

[0046] Figure 8 This is a structural block diagram of a second device provided in Embodiment Six of the present invention. Detailed Implementation

[0047] It should be understood that the specific embodiments described herein are merely illustrative of the invention and are not intended to limit the invention.

[0048] In the following description, the use of suffixes such as "module," "part," or "unit" to denote elements is solely for the purpose of illustrative purposes and has no inherent meaning. Therefore, "module," "part," or "unit" may be used interchangeably.

[0049] Example 1

[0050] like Figure 1 As shown, this embodiment provides a method for generating hot patch files, which includes, but is not limited to, the following steps:

[0051] Step S10: Obtain the first target file in the first project before modification and the second target file in the second project after modification.

[0052] It should be noted that the first target file and the second target file are files that differ in their corresponding storage nodes in the first project and the second project, respectively. Since the second project is obtained by modifying the first project according to certain rules, the storage nodes of each modified file in the second project typically correspond to the storage nodes of each unmodified file in the first project. Therefore, files that differ in their corresponding storage nodes can be understood as modified files in the second project obtained by modifying the unmodified files in the first project. If there are differences in content between the unmodified and modified files, then the unmodified file is the first target file, and the modified file is the second target file.

[0053] In some embodiments, 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:

[0054] Based on the compilation parameters from the debugging information, build the first project (before modification) and the second project (after modification) in the same directory.

[0055] The first target file and the second target file are the files that differ from the binary files with the same name in the first project and the second project, respectively.

[0056] It should be noted that the compilation paths for the binary files with the same name in both the first and second projects are the same.

[0057] In some embodiments, it is assumed that a hot patch is being created for project P. Assume that building project P will result in a main program and several dependent dynamic libraries. The unmodified project is compiled with the -g parameter added, and the entire project is renamed P after compilation. Then, in the same directory, the modified project is compiled with the -g parameter added again, and this modified project is renamed P'. This ensures that the compilation paths of the binary files with the same name in the project directories of P' and P are the same, avoiding interference with subsequent patch creation due to different compilation paths. At this point, the first and second object files include the files with differences between the binary files with the same name in the first and second projects. Specifically, it can be understood that both the first and second projects contain a binary file named X, but the content of the X file in the first project differs from that in the second project. Therefore, the two files named X are respectively the first object file of the first project and the second object file of the second project.

[0058] In some embodiments, obtaining the first and second target files further includes: comparing the project directory of the first project and the project directory of the second project to generate a target file list, wherein each node in the target file list includes the full path name of the first target file and the second target file with the same name.

[0059] In some embodiments, the method for obtaining the first and second target files can be as follows: using a diff tool to compare the project directories of the first and second projects, a target file list O is obtained where the target files with the same name but different contents are stored in the two project directories, wherein each node in the target file list O records the full path name of the first and second target files with the same name. For example, using a diff tool to compare the project directories of projects P' and P, if files X and X' with the same name but different contents are found stored in the same path, then X and X' are treated as a pair of target files, and the full path name of the pair of target files is recorded in the target file list.

[0060] 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.

[0061] In some embodiments, 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:

[0062] Parse the debugging information of the first target file to obtain the name of the first source file;

[0063] The debugging information of the second target file is parsed to obtain the name of the generated second source file.

[0064] In some embodiments, the names of the first and second source files can be obtained by parsing the debugging information of the first and second target files one by one.

[0065] In some embodiments, when the target file list is obtained, the first and second source file names for generating the first and second target files can be obtained by parsing the debugging information of each first and second target file in the target file list.

[0066] 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 dynamic library source file list of the second dynamic library.

[0067] The first main program and the first dynamic library belong to the first project, while the second main program and the second dynamic library belong to the second project.

[0068] In some embodiments, the first main program and the first dynamic library can be obtained by acquiring 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 acquiring the full path names of the main program and the dynamic library corresponding to the second project.

[0069] In some embodiments, the compilation paths of the binary files with the same name in the first and second projects are the same. The first and second main programs and the first and second dynamic libraries can be obtained by retrieving the full path names of the main program and dynamic library corresponding to the first and second projects respectively from the binary files with the same name. In some embodiments, by scanning the binary files under the project targets of the first and second projects respectively, the full path names of the first main program and the first dynamic library corresponding to the first project, and the full path names of the second main program and the second dynamic library corresponding to the second project, can be obtained and recorded. The specific process of obtaining the full path names can be achieved using relevant technologies, which will not be elaborated here.

[0070] It should be noted that the dynamic library in this embodiment of the invention is the dynamic library that the main program depends on.

[0071] In some embodiments, obtaining 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 source file list of the second dynamic library includes:

[0072] Analyze the debugging information of the first main program to obtain the list of source files for the first main program;

[0073] Analyze the debugging information of the second main program to obtain the list of source files for the second main program;

[0074] Parse the debugging information of the first dynamic library to obtain the list of source files of the first dynamic library;

[0075] The debugging information of the second dynamic library is parsed to obtain the list of source files for the second dynamic library.

[0076] Step S13: Determine the ownership information of the first target file and the second target file.

[0077] The attribution information is determined 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, the first dynamic library source file list, and the second dynamic library source file list. The attribution information includes any one of the following: belonging to the first dynamic library, belonging to the second dynamic library, belonging to the first main program, or belonging to the second main program.

[0078] By comparing the first and second source file names obtained in S11 with the source file lists of the first and second main programs and the first and second dynamic libraries obtained in S12, respectively, it can be determined whether the first object file belongs to the first main program or the first dynamic library, and whether the second object file belongs to the second main program or the second dynamic library. Specifically, for example, if the first source file name of the first object file X in the first project is N, and the source file list of the first main program in the first project includes a file with source file name N, then it can be determined that the first object file X belongs to the first main program.

[0079] It should be understood that when determining the ownership information of target files, since the first target file belongs to the first project, the first main program and the first dynamic library source file list corresponding to the first dynamic program of the first project are compared; since the second target file belongs to the second project, the second main program and the second dynamic library source file list corresponding to the second dynamic program of the second project are compared.

[0080] Step S14: Obtain the main program's difference functions and generate the first intermediate hot patch file;

[0081] Step S15: Obtain the dynamic library difference functions and generate the second intermediate hot patch file.

[0082] It should be noted that the first intermediate hot patch file includes identification information, including a main program identifier, and the main program difference functions include functions that differ between the first object file belonging to the first main program and the second object file belonging to the second main program at the corresponding node. The second intermediate hot patch file also includes identification information, including a dynamic library identifier, and the dynamic library difference functions include functions that differ between the first object file belonging to the first dynamic library and the second object file belonging to the second dynamic library at the corresponding node. The dynamic library identifier indicates that the first intermediate hot patch file corresponds to a dynamic library, and the main program identifier indicates that the second intermediate hot patch file corresponds to the main program.

[0083] In some embodiments, obtaining the main program's difference functions and generating a first intermediate hot patch file, and obtaining the dynamic library's difference functions and generating a second intermediate hot patch file, include:

[0084] Based on the attribution information, the first target file is linked to generate the first main program intermediate file and the first dynamic library intermediate file.

[0085] Based on the attribution information, the second target file is linked to generate the second main program intermediate file and the second dynamic library intermediate file respectively;

[0086] Extract the functions that differ from the binary files with the same name in the first and second main program intermediate files as the main program difference functions, and generate the first intermediate hot patch file based on the main program difference functions;

[0087] Extract the functions that differ from the binary files with the same name in the first and second intermediate dynamic library files as dynamic library difference functions, and generate the second intermediate hot patch file based on the dynamic library difference functions.

[0088] In some embodiments, linking the first object files to generate a first main program intermediate file and a first dynamic library intermediate file according to the attribution information, and linking the second object files to generate a second main program intermediate file and a second dynamic library intermediate file according to the attribution information, includes:

[0089] Compare the project directories of the first project and the second project to generate a list of target files. Each node in the target file list includes the full path name of the first target file with the same name and the full path name of the second target file.

[0090] Based on the attribution information and the path information recorded in the target file list, the first target file is linked step by step to generate the first main program intermediate file and the first dynamic library intermediate file;

[0091] Based on the attribution information and the path information recorded in the target file list, the second target file is linked step by step to generate the second main program intermediate file and the second dynamic library intermediate file.

[0092] It should be noted that, depending on the linking method, there may be one or more first main program intermediate files. Similarly, there may be one or more second main program intermediate files. The same applies to the first and second dynamic library intermediate files. Because obtaining the difference functions of the dynamic libraries requires comparing the files (binary files with the same name) at the corresponding nodes in the first and second dynamic library intermediate files, the comparison process becomes cumbersome and labor-intensive if multiple first and second dynamic library intermediate files exist. Likewise, obtaining the difference functions of the main program requires comparing the files (binary files with the same name) at the corresponding nodes in the first and second main program intermediate files. This process is also cumbersome and labor-intensive if multiple first and second main program intermediate files exist. 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 a step-by-step linking method, then the main program difference functions can be obtained by comparing the files (binary files with the same name) at the corresponding nodes of the first main program intermediate file and the second main program intermediate file. Similarly, the dynamic library difference functions can be obtained by comparing the files (binary files with the same name) at the corresponding nodes of the first and second dynamic library intermediate files. The process is simpler, more convenient, faster, and provides a better user experience.

[0093] Step S16: Encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate a hot patch file.

[0094] In some embodiments, the first and second intermediate hot patch files are packaged using the objcopy tool to generate a single hot patch file.

[0095] In some embodiments, the first intermediate hot patch file and the second intermediate hot patch file are stored as separate sections in the hot patch file.

[0096] In some embodiments, the hot patch file includes main program information. This facilitates subsequent management and verification, allowing for a more accurate determination of which main program the hot patch file applies to.

[0097] It should be noted that the execution order of steps S11 and S12 is not limited in this embodiment. That is, step S11 can be executed first and then step S12 can be executed, or the two parts can be executed simultaneously, as long as the source file name and source file list are obtained before step S13 is executed.

[0098] In some embodiments, the above steps are all implemented automatically. In this case, the creation of hot patches no longer depends on manual setting of the patch function, which is more convenient and more accurate after eliminating human error.

[0099] See Figure 2 The following example, using the creation of a hot patch file for project P, illustrates the practical application of this hot patch file generation method.

[0100] Step S20: Add the -g parameter to build the project before and after modification.

[0101] Assume that building project P will result in a main program and several dependent dynamic libraries. Compile the original project with the `-g` parameter, and rename the entire project to P after compilation. Then, in the same directory, compile the modified project with the `-g` parameter again, resulting in project P'. This ensures that the compilation paths for binary files with the same name in both project directories P and P' are identical, preventing discrepancies in compilation paths from affecting subsequent patch creation.

[0102] Step S21: Obtain the full paths of the main program and dynamic libraries in the project directory.

[0103] Specifically, scan the binary files in the project P directory and record the full path names of the first main program and the first dynamic library. Scan the binary files in the project P' directory and record the full path names of the second main program and the second dynamic library.

[0104] Step S22: Obtain the list of source files for the main program and dynamic libraries.

[0105] By using the full path names of the first and second main programs and the first and second dynamic libraries, we can obtain the first main program and the first dynamic library, the second main program and the second dynamic library that each project P and project P' depend on.

[0106] Specifically, the debugging information of the first main program and the first dynamic library of project P is analyzed to obtain the source file lists of the first main program and the dynamic library that constitute the first main program and the first dynamic library, respectively. The debugging information of the second main program and the second dynamic library of project P' is analyzed to obtain the source file lists of the second main program and the second dynamic library that constitute the second main program and the second dynamic library, respectively.

[0107] Step S23: Obtain the list of target files.

[0108] Specifically, the diff tool is used to compare the two project directories P' and P, obtaining the results of the same...

[0109] The addresses of the first and second target files with different names constitute a target file list O, where each node in the target file list O contains the full path names of the first target file before modification and the second target file after modification with the same name.

[0110] Step S24: Parse the target file list to determine ownership information.

[0111] Specifically, the debugging information of the first and second target files in each node of list O is parsed one by one to obtain the first and second source file names of the first and second target files. By using the first and second source file names and 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 which of the first and second target files belongs to, the first and second dynamic libraries or the first and second main programs, that is, the ownership information of the first and second target files.

[0112] Step S25: Compare the first and second target files, extract the differences, generate an intermediate hot patch file and record the identification information.

[0113] Specifically, for the first and second object files whose ownership information is the first and second main programs, the first and second object files are linked step-by-step into a first main program intermediate file and a second main program intermediate file, respectively. Then, the two first main program intermediate files and the second main program intermediate file are compared, and the functions with differences are extracted to generate a first intermediate hot patch file. At the same time, the identification information of the first intermediate hot patch file is recorded as the main program identifier. For the first and second object files whose ownership information is the first and second dynamic libraries, the first and second object files are linked step-by-step into a first dynamic library intermediate file and a second dynamic library intermediate file, respectively. Then, the binary files with the same name in the two first dynamic library intermediate files and the second dynamic library intermediate files are compared, and the functions with differences are extracted to generate a second intermediate hot patch file. At the same time, the identification information of the second intermediate hot patch file is recorded as the dynamic library identifier. At this point, it can be seen that the patch functions in the first intermediate hot patch file correspond to the main program, and the patch functions in the second intermediate hot patch file correspond to the dynamic library.

[0114] Step S26: Package the first and second intermediate hot patch files into a hot patch file.

[0115] Specifically, the first and second intermediate hot patch files are packaged into a single hot patch file using the objcopy tool, where the first and second intermediate hot patch files can be stored as separate sections.

[0116] Hot patch files can also record information about the main program, facilitating subsequent management and verification.

[0117] In some embodiments, the hot patch file generation method provided by the present invention can be applied to the field of hot patching technology for Linux user-space software written in C / C++.

[0118] In some embodiments, the hot patch file generation method provided by this invention is applied to the field of hot patching technology for Linux user-space software written in C / C++ for the x8664 architecture. In some embodiments, the hot patch file generation method provided in this embodiment offers a hot patching solution for Linux user-space programs.

[0119] The hot patch file generation method provided in this embodiment ultimately generates a hot patch file, which is encapsulated by a second intermediate hot patch file belonging to a dynamic library and a first intermediate hot patch file belonging to the main program. By comparing the first and second source file names of the first and second target files with the first and second main program or the first and second dynamic library source file lists, the attribution information of the first and second target files can be obtained. Based on this attribution information, identification information can be recorded in both the first and second intermediate hot patch files to determine whether each patch function in the first and second intermediate hot patch files corresponds to the main program or the dynamic library of the source program. It can be understood that, on the one hand, all steps in the hot patch generation process can be automated, without requiring the developer to understand the details of the program; they only need to know how to build the target project. After building the first and second projects before and after modification, the remaining steps are implemented automatically, improving the efficiency of hot patch file generation, simplifying manual operations, and enhancing the user experience. When applying hot patches, the operator only needs to specify the patch file and does not need to understand the details of the program and the patch. It is highly user-friendly and will not cause errors due to operator error, thus improving the reliability of hot patching technology. On the other hand, the generated hot patch file records the identification information of each function, which can tell whether the function corresponds to the main program of the source program that needs to be patched or the dynamic library. This reduces the risk of patching failure or patching error when the main program of the source file and the dynamic library have the same function, because the identification information of the patch function is not known, and therefore the function to be patched cannot be accurately determined.

[0120] Example 2

[0121] The reliability of hot patching technology also depends on ensuring the consistency of the program state. Before patching, the program executes the original patched function; after patching, it executes the patched function. There cannot be any intermediate states. In other words, it is absolutely unacceptable for some tasks to continue executing old code from the patched function after patching, as this could lead to data and state inconsistencies, affecting program functionality and even causing crashes. This necessitates checking whether each task is currently executing the patched function during hot patching. If so, function replacement is postponed until all tasks have stopped executing the patched function. The method for determining whether each task is currently executing the patched function is called consistency detection technology.

[0122] Among related technologies, the following two are typical solutions for hot patch consistency detection:

[0123] Option 1: When applying hot patches, only check if the current program counter (PC) of each task is within the function being patched. This option is clearly imperfect. For example, if function A in the program needs to be replaced, and the function call chain of a certain thread during hot patching is A->B->C, and the code in C is currently being executed, if only the current PC is checked, then the PC is in function C, not function A, and the check passes. Therefore, the original A is replaced with the new A'. However, after the hot patch is applied, when the thread returns from B, it will continue executing the remaining code in the original A, while other newly calling threads will execute the new A'. This will lead to inconsistent program states, potentially causing program malfunctions.

[0124] Option 2: Use the ptrace debugging technique provided by the Linux kernel to trace the process, pause all threads, and obtain the function call chain of each thread to check for the presence of patched functions. This option avoids the inconsistent program state problem of Option 1. However, it has several drawbacks. First, it requires frequent data reading from the program being tested via ptrace system calls, necessitating frequent switching between kernel and user modes, resulting in low performance. Second, it requires performing the check on each thread individually, which can be time-consuming if the program has many threads. Furthermore, all threads are paused during the check, significantly impacting the program's performance. This may be unacceptable for latency-sensitive communication services, potentially even causing the program to malfunction.

[0125] It can be seen that the consistency detection schemes in the relevant technologies all have some defects. They are either unreliable or suffer from severe performance degradation, which may cause the program to fail to run properly after hot patching.

[0126] like Figure 3As shown, this embodiment provides a consistency detection method, which includes, but is not limited to, the following steps:

[0127] Step S30: Obtain the full path of the hot patch file and the identification information of the patched function.

[0128] In some embodiments, the full path to the hot patch file can be specified by the user or set via system presets. After setting the full path to the hot patch file, obtain the full path of the hot patch file.

[0129] In some embodiments, obtaining the identification information of the patched function includes: searching in the source program for a function with the same name as the patch function in the hot patch file; if a function with the same name is found, the function with the same name is the patched function; and obtaining the identification information of the patched function. In some embodiments, the identification information includes the starting address and size information of the patched function.

[0130] In some embodiments, a hot patch file can be loaded through a hot patch management thread to obtain information on all patch functions within the file. Then, a function with the same name can be searched for in the source program. If a function with the same name is found, it is the function to be patched. The starting address and size information of the patched function are recorded. In some embodiments, there may be some patch functions that cannot be found in the source program; this indicates that the patch function is a newly added function.

[0131] It should be noted that the hot patch file in the consistency detection method in the embodiments of the present invention can be a hot patch file generated by the hot patch file generation method given in the above embodiments, or a hot patch file obtained by using related technologies, and there is no limitation here.

[0132] Step S31: Obtain the source program call stack information of the source program.

[0133] Among them, the source program call stack information is auxiliary information generated by the compiler for tracing back the function call chain.

[0134] In some embodiments, the main program of the process requiring hot patching (the current process) and the source program call stack information of its dependent dynamic libraries can be loaded during program initialization. Alternatively, the source program and dynamic library call stack information can be retrieved only when hot patching is required. Those skilled in the art can also reasonably set other times for retrieving the main program and dynamic library call stack information as needed.

[0135] Step S32: Based on the source program call stack information, each thread of the current process of the source program backtracks its own current function call chain in parallel.

[0136] In some embodiments, the threads of the current process of the source program, i.e., the process of the source program that needs hot patching, can execute the backtracking process in parallel, which results in higher backtracking efficiency. Of course, those skilled in the art can also specify that some threads backtrack in parallel while others backtrack sequentially, or that each thread backtracks sequentially, as needed.

[0137] Step S33: Traverse the thread functions in each level of the current function call chain and perform consistency checks.

[0138] It should be noted that the consistency check includes determining the thread state of the thread based on the identification information, and the thread state includes a blocked state or continued running.

[0139] In some embodiments, by performing consistency checks on threads to detect whether the thread function includes a patched function, it can be determined whether the thread has a patched function that is being called.

[0140] In some embodiments, threads use the source program call stack information to backtrack their own current function call chain. This involves backtracking each level of the current function call chain to determine whether each level includes the patched function, rather than just checking the first level. Therefore, the consistency check for that thread is complete. Furthermore, if the consistency checks of all threads in the current process are successful, theoretically, the consistency of the program state after subsequent patching can be guaranteed.

[0141] In some embodiments, determining the thread state of a thread based on identification information includes:

[0142] If the function being patched is not found in the thread's function, the thread enters a blocked state.

[0143] In some embodiments, determining the thread state of a thread based on identification information includes:

[0144] If the thread function is found to contain a patched function, the thread continues to run.

[0145] Perform a consistency check on the thread again at preset intervals.

[0146] It should be noted that the preset time can be a time reasonably set by those skilled in the art as needed. The preset time can also be based on the time it takes for a thread to complete the detection. For example, if it takes 20 milliseconds for a thread to complete the detection, then considering the issue of multi-threaded scheduling, the detection interval can be set to 30 milliseconds.

[0147] In some embodiments, if there are threads in the current process of the source program that have not yet entered the blocked state, the consistency check steps are repeated until all threads in the current process of the source program enter the blocked state, the consistency check of the source program is successful, and the process ends.

[0148] Step S34: Determine the consistency check result based on the thread state of each thread.

[0149] In some embodiments, determining the consistency check result based on the thread state of each thread includes:

[0150] All threads entered a blocked state, and the consistency check of the source program was successful.

[0151] It should be noted that if the thread function does not include the function being patched, it indicates that the thread has passed the consistency check, and patching the current thread is safe. If all threads in the current process of the source program have passed the consistency check, then the consistency check of the source program is successful. It should also be noted that the current process of the source program includes the process that needs hot patching.

[0152] In some embodiments, a thread entering a blocked state includes, but is not limited to, a thread entering a waiting state for a lock.

[0153] In some embodiments, determining whether all threads of the current process of the source program (the process requiring hot patching) have entered a blocked state includes: obtaining the number of threads in the current process of the source program; incrementing a global flag atom by 1 when a thread enters a blocked state; and determining that all threads of the current process of the source program have entered a blocked state when the global flag atom is equal to the number of threads. In some embodiments, if the global flag atom is less than the number of threads, the number of consistency checks completed by any thread that has not yet entered a blocked state is obtained. If the number of checks is greater than a preset check count threshold, the normal operation of each thread in the blocked state is restored. The global flag atom is initialized to 0. It should be noted that the global flag atom initialization position can also be other positions set by those skilled in the art as needed. Correspondingly, the relationship between the global flag atom and the current number of threads in the source program can be used to determine whether all threads of the current process of the source program have entered a blocked state. For example, if the global flag atom initialization position is 5, the current process has 10 threads, and the global flag atom is incremented by 1 for each thread entering a blocked state, then when the global flag atom is 15, it can be determined that all threads of the current process of the source program have entered a blocked state.

[0154] In some embodiments, all threads enter a blocked state, and after the consistency check of the source program is successful, the following steps are also included:

[0155] Apply hotfixes to the source code;

[0156] After completing the hot patching operation, resume running all threads.

[0157] In other words, hot patching is only performed on the source program after the consistency check is successful. This ensures that the program state remains consistent after patching, thus improving the reliability of hot patching technology.

[0158] It should be noted that completing the hot patching operation includes at least one of the following: the patched function in all threads of the current process has been replaced; or a new function has been added, and the function addition has been completed. In some embodiments, after completing the hot patching operation, a message indicating successful patching is displayed.

[0159] In some embodiments, determining the consistency check result based on the thread state of each thread includes:

[0160] If there are threads that are not in a blocked state, obtain the number of consistency checks performed on those threads;

[0161] If the number of detections exceeds the preset detection threshold, restore the normal operation of each thread that is in a blocked state;

[0162] The consistency check of the source code failed.

[0163] In some embodiments, sometimes due to busy program operations, if at least one thread has undergone a number of consistency checks exceeding a preset threshold, and the thread function in that thread still includes the patched function, then to improve the user experience, the user can be prompted that the consistency check failed and will be retried later, and other threads in the blocked process can be restored to normal operation.

[0164] In some embodiments, if the current process consistency check of a source program fails, the consistency check can be performed again after receiving the instruction for the next hot patch. The instruction for the next hot patch can be issued in ways including, but not limited to, automatically after a certain time interval, or issued by the user through a relevant device.

[0165] The preset threshold for the number of tests can be a reasonable value set by those skilled in the art in combination with the actual use scenario.

[0166] In some embodiments, if the consistency check of the source program fails, unused resources are cleaned up, including call stack information.

[0167] In some embodiments, after determining the consistency check result based on the thread state of each thread, the method further includes:

[0168] Clean up the source program's call stack information.

[0169] In some embodiments, the consistency detection method further includes: after completing the hot patching operation, cleaning up unused resources, including source program call stack information.

[0170] In some embodiments, after a consistency check fails, unused resources are cleaned up, including source program call stack information.

[0171] In some embodiments, after obtaining the source program call stack information, the method further includes:

[0172] Send signals to each thread; these signals are not dedicated signals.

[0173] After receiving the signal, each thread in the current process of the source program traces its own current function call chain in parallel, based on the source program's call stack information.

[0174] It should be noted that these are non-dedicated signals, including SIGUSR1, SIGUSR2, and real-time signals.

[0175] It should be noted that the current process includes the process of the source code that needs to be hot-patched.

[0176] In some embodiments, the signal is a common signal or a real-time signal, such as SIGUSRI, SIG44, or other common but non-dedicated signals.

[0177] In some embodiments, determining the thread state of a thread based on identification information includes:

[0178] Obtain the identification information of the patched function, including the main program identifier or dynamic library identifier;

[0179] The source program call stack information includes the main program call stack information and the dynamic library call stack information of the source program;

[0180] Based on the main program call stack information, each thread of the main program in the current process of the source program backtracks its own current function call chain in parallel.

[0181] Based on the dynamic library call stack information, the current process of the source program's dynamic library threads trace back their own current function call chains in parallel.

[0182] The thread state of the main program's thread is determined based on the identification information, including the identification information of the patched function identified by the main program.

[0183] The thread state of the dynamic library's thread is determined based on the identification information, including the identification information of the patched function and the dynamic library identifier.

[0184] 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 a dynamic library of the source program. It can be obtained from the identification information of the patch function corresponding to the patched function; the identification information of the patched function and the patch function are the same. For example, if the identification information of the patch function corresponding to the patched function is the main program identifier, then the identification information of the patched function is also the main program identifier. Similarly, if the identification information of the patch function corresponding to the patched function is a dynamic library identifier, then the identification information of the patched function is also a dynamic library identifier.

[0185] Since the identification information of the patched function can classify the patched function into the patched function of the corresponding main program and the patched function of the corresponding dynamic library, the scope of comparison when determining the thread state can be narrowed, thereby improving the speed and accuracy of determining the thread state.

[0186] See Figure 4 The following section uses source program C as an example to illustrate the practical application of this consistency detection method.

[0187] Step S40: Obtain the identification information of the function being patched and the full path of the hot patch file.

[0188] Specifically, the full path of the hot patch file to be applied is specified by the user, and then the full path of the hot patch file is obtained. The hot patch management thread loads the hot patch file and obtains all the patch function information within it. It searches for functions with the same name as each patch function in the source program. If a function with the same name is found, then that function in the source program is the function being patched; if no function with the same name is found, then the patch function is a newly added function. The starting address and size information of the patched function are recorded.

[0189] Step S41: Load the main program call stack information and dynamic library call stack information of the process main program and dynamic library.

[0190] Specifically, during program initialization, the main program call stack information of the process's main program and the dynamic library call stack information of its dependent dynamic libraries are loaded. This main program call stack information and dynamic library call stack information are auxiliary information generated by the compiler for tracing the function 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.

[0191] Step S42: Obtain the current number of threads and send signals to each thread.

[0192] Specifically, the hot patch management thread obtains the current thread count of the process and sends a signal to each thread. This signal can be a common signal or a real-time signal, such as SIGUSR1, SIG44, or other common but non-dedicated signals.

[0193] Step S43: After receiving the signal, each thread backtracks its current function call chain and checks if there is a patched function in the current function call chain. If no patched function is found, the thread blocks and waits; if a patched function is found, the thread continues to run.

[0194] Specifically, after receiving the signal, each thread backtracks its current function call chain based on the source program call stack information. Then, each thread traverses the thread functions at each level of the current function call chain it has backtracked, and checks whether the patched function obtained in step S40 exists in the current function call chain based on the identification information. If the patched function does not exist, the check passes, a global flag is atomically incremented, and then the thread enters the lock waiting state; if the patched function exists, the check fails, and the thread continues to execute.

[0195] In some embodiments, the identification information of the patched function can be obtained, including the main program identifier or dynamic library identifier. The identification information of the patched function whose identification information is the main program identifier is obtained. After receiving the signal, the main program thread uses the main program call stack information to backtrack its current function call chain. Then, each thread of the main program traverses the thread function in each level of the current function call chain and checks whether the patched function obtained in step S40 exists in the current function call chain based on the identification information of the patched function whose identification information is the main program identifier. If the patched function does not exist, the detection passes, a global flag is atomically incremented by one, and then the thread enters the waiting lock state. If the patched function exists, the detection fails, and the thread continues to execute. The identification information of the patched function identified by the dynamic library is obtained. After receiving the signal, the thread of the dynamic library uses the dynamic library call stack information to backtrack its current function call chain. Then, each thread of the dynamic library traverses the thread function at each level of the current function call chain and checks whether the patched function obtained in step S40 exists in the current function call chain based on the identification information of the patched function identified by the dynamic library. If the patched function does not exist, the check passes, a global flag is atomically incremented, and then the thread enters the waiting lock state; if the patched function exists, the check fails, and the thread continues to execute.

[0196] Step S44: Determine if all threads are in a waiting state for the lock. If yes, proceed to step S45; otherwise, proceed to step S46.

[0197] Step S45: Perform function replacement and resume the operation of all threads, then proceed to step S47.

[0198] Step S46: Determine whether the number of books to be detected is greater than the preset detection threshold. If not, proceed to step S42; if yes, proceed to step S47.

[0199] Step S47: End.

[0200] In some embodiments, the hot patch management thread checks at preset intervals whether the value of a global flag is equal to the number of other threads besides the hot patch management thread. If they are equal, the check passes, function replacement is performed, a successful patch is indicated, all other threads resume execution, and unused resources, such as source code call stack information, are cleaned up. If the value of the global flag is not equal to the number of other threads besides the hot patch management thread, the check fails, and the number of checks is then checked against a preset check count threshold. If the number of checks does not exceed the threshold, the process continues to wait for the next check. If the number of checks exceeds the threshold, the process ends, a patching failure is indicated, other threads resume execution, and unused resources, such as source code call stack information, are cleaned up. The preset time can be chosen based on the time it takes for one thread to complete the check. For example, if one thread takes 20 milliseconds to complete the check, then considering multi-threaded scheduling, the preset time can be set to 30 milliseconds. After indicating a patching failure, the user can be prompted to retry the consistency check after a certain interval.

[0201] In some embodiments, the consistency detection method provided by this invention can be applied to the field of hot patching technology for Linux user-space software written in C / C++, providing a hot patching solution for Linux user-space programs.

[0202] In some embodiments, the consistency detection method provided by this invention is applied to the field of hot patching technology for Linux user-space software written in C / C++ for the X8664 architecture.

[0203] The consistency detection method provided in this invention, because each thread backtracks its own current function call chain, eliminates the need for kernel-provided ptrace debugging technology, avoiding frequent switching between user mode and kernel mode. Furthermore, each thread can execute the backtracking process in parallel instead of sequentially backtracking. Overall, this represents a significant performance improvement compared to solutions using ptrace debugging technology, reducing backtracking time and minimizing the impact on the program. In addition, the consistency detection method in this invention detects whether the thread function in each layer of the function call chain is the function to be patched, rather than just checking the first layer. Therefore, the consistency detection is complete; as long as each thread passes the detection, the program state is guaranteed to be consistent after patching, improving the reliability of hot patching technology.

[0204] Example 3

[0205] like Figure 5 As shown, this embodiment of the invention also provides a hot patch file generation device, the hot patch file generation device 500 comprising:

[0206] The first acquisition module 501 is used to acquire the first target file in the first project before modification and the second target file in the second project after modification, wherein the first target file and the second target file are files that differ on the corresponding storage nodes of the first project and the second project, respectively.

[0207] The second acquisition module 502 is used to acquire the first source file name for generating the first target file and the second source file name for generating the second target file;

[0208] The third acquisition module 503 is used 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 source file list of the second 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 second project.

[0209] The first determining module 504 is used to determine the ownership information of the first target file and the second target file. The ownership information is determined 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, the first dynamic library source file list, and the second dynamic library source file list. The ownership information includes any one of the following: belonging to the first dynamic library, belonging to the second dynamic library, belonging to the first main program, and belonging to the second main program.

[0210] The fourth acquisition module 505 is used to acquire the main program difference functions 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 functions include functions that differ 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.

[0211] The fifth acquisition module 506 is used to acquire dynamic library difference functions 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 functions include functions that differ 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.

[0212] The encapsulation module 507 is used to encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate a hot patch file.

[0213] It should be noted that the hot patch file generation device provided in this embodiment includes other modules to implement the steps of the hot patch file generation method described in the above embodiments. The specific functions of each module can be found in the descriptions in the above embodiments of the hot patch file generation method, and will not be repeated here.

[0214] The hot patch file generation device provided in this embodiment ultimately generates a hot patch file, which is encapsulated by a second intermediate hot patch file belonging to a dynamic library and a first intermediate hot patch file belonging to the main program. The first and second intermediate hot patch files record identification information, allowing us to determine whether each patch function in the first and second intermediate hot patch files corresponds to the main program or a dynamic library in the source program. On one hand, the hot patch generation process can be automated, eliminating the need for developers to understand program details; they only need to know how to build the target project. After building the first and second projects before and after modification, the remaining steps are automated, improving the efficiency of hot patch file generation, simplifying manual operations, and enhancing the user experience. When applying hot patches, operators only need to specify the patch file and do not need to understand the details of the program and the patch. It boasts high ease of use and eliminates the risk of errors due to operator negligence, thus enhancing the reliability of hot-patching technology. Furthermore, the generated hot-patch file records the identification information of each patch function, allowing the system to determine whether the function corresponds to the main program of the source code or a dynamic library requiring patching. This reduces the risk of patching failures or errors when the main program and dynamic libraries contain the same function, as the lack of identification information prevents accurate identification of the function to be patched.

[0215] Example 4

[0216] like Figure 6 As shown, this embodiment of the invention also provides a consistency detection device, the consistency detection device 600 including:

[0217] The sixth acquisition module 601 is used to acquire the full path of the hot patch file and the identification information of the patched function;

[0218] The seventh acquisition module 602 is used to acquire the source program call stack information of the source program;

[0219] The parallel backtracking module 603 is used to backtrack the current function call chain of each thread in the current process of the source program in parallel based on the source program call stack information.

[0220] The detection module 604 is used to traverse the thread functions in each layer of the current function call chain and perform consistency detection. The consistency detection includes determining the thread state of the thread based on the identification information. The thread state includes a blocked state or continued running.

[0221] The second determining module 605 is used to determine the result of the consistency detection based on the thread state of each thread.

[0222] It should be noted that the consistency detection device provided in this embodiment includes other modules to implement the steps of the consistency detection method described in the above embodiments. The specific functions of each module can be found in the descriptions in the above consistency detection method embodiments, and will not be repeated here.

[0223] The consistency detection device provided in this embodiment of the invention, because each thread backtracks its own current function call chain, eliminates the need to rely on the kernel-provided ptrace debugging technology, thus avoiding frequent switching between user mode and kernel mode. Furthermore, each thread can execute the backtracking process in parallel instead of backtracking sequentially. Overall performance is significantly improved compared to solutions using ptrace debugging technology. In addition, the consistency detection device in this embodiment detects whether the thread function in each layer of the function call chain is the function to be patched, rather than just checking the first layer. Therefore, the consistency detection is complete; as long as each thread passes the detection, the program state is guaranteed to be consistent after patching, improving the reliability of hot patching technology.

[0224] Example 5

[0225] like Figure 7 As shown, this embodiment of the invention also provides a first device 700, which includes a first memory 701, a first processor 702, a first program stored in the first memory 701 and executable on the first processor 702, and a first data bus 703 for implementing connection communication between the first processor 702 and the first memory 701. When the first program is executed by the first processor 702, it implements the steps of the hot patch file generation method as described in any of the above embodiments.

[0226] The first device provided in this embodiment ultimately generates a hot patch file, which is encapsulated by a second intermediate hot patch file belonging to a dynamic library and a first intermediate hot patch file belonging to the main program. The first and second intermediate hot patch files record identification information, indicating whether the function corresponds to the main program of the source program that needs patching or a dynamic library. This reduces the risk of patching failure or errors when the main program and dynamic library contain the same function, as the identification information of the patch function is unknown, leading to inaccurate identification of the function to be patched. The hot patch generation process can be automated, requiring no knowledge of the program details from the developers; they only need to know how to build the target project. After building the project before and after modification, the remaining steps are automated, improving the efficiency of hot patch file generation, simplifying manual operations, and enhancing user experience. The generated hot patch file records the attribution information of each patched function; when applying a hot patch, the operator only needs to specify the patch file, without needing to understand the program and patch details. It is highly usable and avoids errors due to operator error, improving the reliability of hot patching technology.

[0227] Example 6

[0228] like Figure 8 As shown, this embodiment of the invention also provides a second device 800, which includes a second memory 801, a second processor 802, a second program stored on the second memory 801 and executable on the second processor 802, and a second data bus 803 for implementing connection communication between the second processor 802 and the second memory 801. When the second program is executed by the second processor 802, it implements the steps of the consistency detection method as described in any of the above embodiments.

[0229] The second device provided in this embodiment of the invention, because each thread independently backtracks its current function call chain, eliminates the need to rely on the kernel-provided ptrace debugging technology, thus avoiding frequent switching between user mode and kernel mode. Furthermore, each thread can execute the backtracking process in parallel instead of backtracking sequentially. Overall performance is significantly improved compared to solutions using ptrace debugging technology. In addition, the consistency detection method in this embodiment detects whether the thread function in each layer of the function call chain is the function to be patched, rather than just checking the first layer. Therefore, the consistency detection is complete; as long as each thread passes the detection, the program state is guaranteed to be consistent after patching, improving the reliability of hot patching technology.

[0230] This invention also provides a storage medium for computer-readable storage, the storage medium storing one or more first programs, which can be executed by one or more first processors to implement the steps of the hot patch file generation method of any of the above embodiments;

[0231] or,

[0232] The storage medium stores one or more second programs, which can be executed by one or more second processors to implement the steps of the consistency detection method of any of the above embodiments.

[0233] Those skilled in the art will understand that all or some of the steps in the methods disclosed above, as well as the functional modules / units in the systems and devices, can be implemented as software, firmware, hardware, or suitable combinations thereof.

[0234] In hardware implementations, 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 be performed collaboratively by several physical components. Some or all physical components may be implemented as software executed by a processor, such as a central processing unit, digital signal processor, or microprocessor, or as hardware, or as an integrated circuit, such as an application-specific integrated circuit. Such software may be distributed on a computer-readable medium, which may include computer storage media (or non-transitory media) and communication media (or transient media). As is known to those skilled in the art, the term computer storage media includes volatile and non-volatile, removable and non-removable media implemented in any method or technology for storing information (such as computer-readable instructions, data structures, program modules, or other data). Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, flash memory or other memory technologies, CD-ROM, digital versatile disc (DVD) or other optical disc storage, magnetic cartridges, magnetic tape, disk storage or other magnetic storage devices, or any other medium that can be used to store desired information and is accessible to a computer. Furthermore, as is known to those skilled in the art, communication media typically contain computer-readable instructions, data structures, program modules, or other data in modulated data signals such as carrier waves or other transmission mechanisms, and may include any information delivery medium.

[0235] The preferred embodiments of the present invention have been described above with reference to the accompanying drawings, but this does not limit the scope of the invention. Any modifications, equivalent substitutions, and improvements made by those skilled in the art without departing from the scope and spirit of the present invention should be within the scope of the present invention.

Claims

1. A method for generating a hot patch file, the method comprising: 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 that differ on the corresponding storage nodes of the first project and the second project, respectively. Obtain the first source file name for generating the first target file and the second source file name for generating the second target file; 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 dynamic library source file list of the second 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 second project. The ownership information of the first target file and the second target file is determined. The ownership information is determined 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, the first dynamic library source file list, and the second dynamic library source file list. The ownership information includes any one of the following: belonging to the first dynamic library, belonging to the second dynamic library, belonging to the first main program, and belonging to the second main program. Obtain the main program difference functions and generate a first intermediate hot patch file. The first intermediate hot patch file includes identification information, and the identification information includes the main program identifier. The main program difference functions include functions that differ 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. 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 functions that differ 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 first intermediate hot patch file and the second intermediate hot patch file are packaged together to generate a hot patch file.

2. The hot patch file generation method according to claim 1, characterized in that, Before obtaining the first target file in the first project before modification and the second target file in the second project after modification, the process also includes: Based on the compilation parameters in the debugging information, build the first project before modification and the second project after modification in the same directory, with the compilation paths of the binary files with the same name in the first project and the second project being the same; The first target file and the second target file are files that differ from the binary files with the same name in the first project and the second project, respectively.

3. The hot patch file generation method according to claim 2, characterized in that, The step of 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: Parse the debugging information of the first target file to obtain the name of the first source file; The debugging information of the second target file is parsed to obtain the name of the generated second source file.

4. The hot patch file generation method according to claim 2, characterized in that, The process of obtaining 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 source file list of the second dynamic library includes: Parse the debugging information of the first main program to obtain the list of source files of the first main program; The debugging information of the second main program is parsed to obtain the list of source files of the second main program; Parse the debugging information of the first dynamic library to obtain the list of source files of the first dynamic library; The debugging information of the second dynamic library is parsed to obtain the list of source files of the second dynamic library.

5. The hot patch file generation method according to claim 2, characterized in that, The steps of obtaining the main program's difference functions, generating the first intermediate hot patch file, and obtaining the dynamic library's difference functions, generating the second intermediate hot patch file, include: Based on the attribution information, the first target file is linked to generate the first main program intermediate file and the first dynamic library intermediate file respectively; Based on the attribution information, the second target file is linked to generate the second main program intermediate file and the second dynamic library intermediate file respectively; Extract the functions that differ from the binary files with the same name in the first and second main program intermediate files as the main program difference functions, and generate the first intermediate hot patch file based on the main program difference functions; Extract the functions that differ from the binary files with the same name in the first and second dynamic library intermediate files as the dynamic library difference functions, and generate the second intermediate hot patch file based on the dynamic library difference functions.

6. The hot patch file generation method according to claim 5, characterized in that, The step of linking the first target file to generate a first main program intermediate file and a first dynamic library intermediate file according to the attribution information, and linking the second target file to generate a second main program intermediate file and a second dynamic library intermediate file according to the attribution information, includes: By comparing the project directories of the first project and the second project, a list of target files is generated. Each node in the list of target files includes the full path name of the first target file and the full path name of the second target file with the same name. Based on the attribution information, and based on the path information recorded in the target file list, the first target file is linked step by step to generate the first main program intermediate file and the first dynamic library intermediate file; Based on the attribution information, and according to the path information recorded in the target file list, the second target file is linked step by step to generate the second main program intermediate file and the second dynamic library intermediate file.

7. The hot patch file generation method according to any one of claims 1-6, characterized in that, The hot patch file generation method further includes at least one of the following: In the hot patch file, the first intermediate hot patch file and the second intermediate hot patch file are each stored as an independent section; The hot patch file includes main program information.

8. A consistency detection method, characterized in that, The consistency detection method includes: Obtain the full path of the hot patch file and the identification information of the function being patched; the hot patch file is a file generated using the hot patch file generation method as described in any one of claims 1 to 7; Obtain the source program call stack information; Based on the source program call stack information, each thread of the current process of the source program backtracks its own current function call chain in parallel. Traverse the thread functions in each layer of the current function call chain and perform consistency checks. The consistency checks include determining the thread state of the thread based on the identification information. The thread state includes a blocked state or continued execution. The result of the consistency check is determined based on the thread state of each thread.

9. The consistency detection method according to claim 8, characterized in that, Determining the thread state of the thread based on the identification information includes: If the thread function is found to be missing the patched function, the thread enters a blocked state.

10. The consistency detection method according to claim 9, characterized in that, Determining the consistency check result based on the thread state of each thread includes: All threads entered a blocked state, and the consistency check of the source program was successful.

11. The consistency detection method according to claim 10, characterized in that, After all the aforementioned threads enter a blocked state, and the consistency check of the source program is successful, the process further includes: Perform a hot patch operation on the source program; After completing the hot patching operation, resume the operation of all the threads.

12. The consistency detection method according to claim 8, characterized in that, Determining the thread state of the thread based on the identification information includes: If the thread function is found to contain a patched function, the thread continues to run; The consistency check is performed on the thread again at a preset time interval.

13. The consistency detection method according to claim 12, characterized in that, Determining the consistency check result based on the thread state of each thread includes: If any of the threads are not in a blocked state, obtain the number of consistency checks performed on that thread; If the number of detections exceeds a preset detection threshold, the threads that are in a blocked state will resume normal operation. The consistency check of the source program failed.

14. The consistency detection method according to any one of claims 8-13, characterized in that, After obtaining the source program call stack information, the process further includes: Send a signal to each of the aforementioned threads, wherein the signal is a non-dedicated signal; After receiving the signal, the thread, based on the source program call stack information, backtracks the current function call chain of each thread in the current process of the source program in parallel.

15. The consistency detection method according to any one of claims 8-13, characterized in that, Determining the thread state of the thread based on the identification information includes: Obtain the identification information of the patched function, the identification information including the main program identifier or dynamic library identifier; The source program call stack information includes the main program call stack information and the dynamic library call stack information of the source program; Based on the main program call stack information, each thread of the main program in the current process of the source program backtracks its own current function call chain in parallel; Based on the dynamic library call stack information, each thread of the dynamic library in the current process of the source program backtracks its own current function call chain in parallel. The thread state of the thread of the main program is determined based on the identification information, including the identification information of the patched function of the main program; The thread state of the thread of the dynamic library is determined based on the identification information of the patched function, including the identification information of the dynamic library.

16. The consistency detection method according to any one of claims 8-13, characterized in that, After determining the consistency check result based on the thread state of each thread, the method further includes: Clean up the source program call stack information.

17. A hot patch file generation apparatus, characterized in that, The hot patch file generation device includes: The first acquisition module is used to acquire 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 that differ on the corresponding storage nodes of the first project and the second project, respectively. The second acquisition module is used to acquire 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 used 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 source file list of the second 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 second project. The first determining module is used to determine the ownership information of the first target file and the second target file. The ownership information is determined 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, the first dynamic library source file list, and the second dynamic library source file list. The ownership information includes any one of the following: belonging to the first 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 used to acquire the main program difference functions 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 functions include functions that differ 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 acquisition module is used to acquire dynamic library difference functions 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 functions include functions that differ 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 is used to encapsulate the first intermediate hot patch file and the second intermediate hot patch file to generate a hot patch file.

18. A consistency detection device, characterized in that, The consistency detection device includes: The sixth acquisition module is used to acquire the full path of the hot patch file and the identification information of the function being patched; the hot patch file is a file generated using the hot patch file generation device as described in claim 17; The seventh module is used to obtain the source program call stack information; The parallel backtracking module is used to backtrack the current function call chain of each thread in the current process of the source program in parallel, based on the source program call stack information. The detection module is used to traverse the thread functions in each layer of the current function call chain and perform consistency detection. The consistency detection includes determining the thread state of the thread based on the identification information. The thread state includes a blocked state or continued running. The second determining module is used to determine the result of the consistency detection based on the thread state of each thread.

19. A first device, characterized in that, The first device includes a first memory, a first processor, a first program stored on the first memory and executable on the first processor, and a first data bus for implementing communication between the first processor and the first memory. When the first program is executed by the first processor, it implements the steps of the hot patch file generation method as described in any one of claims 1-7.

20. A second device, characterized in that, The second device includes a second memory, a second processor, a second program stored in the second memory and executable on the second processor, and a second data bus for implementing connection communication between the second processor and the second memory. When the second program is executed by the second processor, it implements the steps of the consistency detection method as described in any one of claims 8-16.

21. A medium for computer-readable storage, characterized in that, The storage medium stores one or more first programs, which can be executed by one or more first processors to implement the steps of the hot patch file generation method according to any one of claims 1-7; or, The storage medium stores one or more second programs, which can be executed by one or more second processors to implement the steps of the consistency detection method according to any one of claims 8-16.

Images