CN115952017B - Memory processing method, device, equipment and medium - Google Patents
Memory processing method, device, equipment and medium Download PDFInfo
- Publication number
- CN115952017B CN115952017B CN202310221060.5A CN202310221060A CN115952017B CN 115952017 B CN115952017 B CN 115952017B CN 202310221060 A CN202310221060 A CN 202310221060A CN 115952017 B CN115952017 B CN 115952017B
- Authority
- CN
- China
- Prior art keywords
- virtual function
- function table
- address
- pointer
- table data
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y02—TECHNOLOGIES OR APPLICATIONS FOR MITIGATION OR ADAPTATION AGAINST CLIMATE CHANGE
- Y02D—CLIMATE CHANGE MITIGATION TECHNOLOGIES IN INFORMATION AND COMMUNICATION TECHNOLOGIES [ICT], I.E. INFORMATION AND COMMUNICATION TECHNOLOGIES AIMING AT THE REDUCTION OF THEIR OWN ENERGY USE
- Y02D10/00—Energy efficient computing, e.g. low power processors, power management or thermal management
Abstract
The embodiment of the application provides a memory processing method, a device, equipment and a medium, wherein the method comprises the following steps: after reestablishing communication connection between the target process and the shared memory, determining a designated area in the shared memory; obtaining virtual function table data corresponding to a target process from a process address space of the target process; and copying the acquired virtual function table data to a designated area in the shared memory, so that the target process calls the virtual function required by the target process from the virtual function table data stored in the designated area through the virtual function table pointer. By adopting the embodiment of the invention, the validity of the virtual function table pointer can be ensured when the non-POD type data containing the virtual function table pointer is stored in the shared memory.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a memory processing method, apparatus, device, and medium.
Background
Shared memory is a data caching scheme that allows multiple processes to access the same memory space, and is an efficient way to share and transfer data between multiple processes.
Practice shows that when the Data management of the shared memory is realized, virtual function table pointers contained in non-POD (Plain Old Data) type Data can be invalid when the process is restarted; this results in non-POD type data not being stored into the shared memory, not only limiting the type of data stored in the shared memory, but also greatly limiting the development ability of the developer.
Disclosure of Invention
The embodiment of the application provides a memory processing method, a device, equipment and a medium, which can ensure the validity of a virtual function table pointer when non-POD type data containing the virtual function table pointer is stored in a shared memory.
In one aspect, an embodiment of the present application provides a memory processing method, where the method includes:
after reestablishing communication connection between the target process and the shared memory, determining a designated area in the shared memory, wherein the designated area is used for storing virtual function table data corresponding to the target process; the shared memory stores non-POD type data, the non-POD type data comprises virtual function table pointers corresponding to the target process, and the virtual function table pointers are preset to point to the designated area;
obtaining virtual function table data corresponding to a target process from a process address space of the target process;
And copying the acquired virtual function table data to a designated area in the shared memory, so that the target process calls the virtual function required by the target process from the virtual function table data stored in the designated area through the virtual function table pointer.
In another aspect, an embodiment of the present application provides a memory processing apparatus, including:
the processing unit is used for determining a designated area in the shared memory after the communication connection is rebuilt between the target process and the shared memory, wherein the designated area is used for storing virtual function table data corresponding to the target process; the shared memory stores non-POD type data, and the virtual function table pointer corresponding to the target process contained in the non-POD type data is preset to point to a designated area;
the acquisition unit is used for acquiring virtual function table data corresponding to the target process from a process address space of the target process;
and the processing unit is also used for copying the acquired virtual function table data to a designated area in the shared memory, so that the target process calls the virtual function required by the target process operation from the virtual function table data stored in the designated area through the virtual function table pointer.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object, where the function addresses of the virtual functions are used to indicate: address space location of the virtual function in the process address space;
The virtual function table pointer is preset to point to a target memory location in the designated area, the target memory location being: and the function address of the virtual function to be called by the virtual function pointer in the virtual function table data is stored in a designated area.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; the processing unit is further used for:
obtaining an objective function address of each virtual function in one or more virtual functions, wherein the objective function address of the virtual function is used for indicating: after the communication connection is rebuilt between the target process and the shared memory, the address space position of the virtual function updated in the process address space of the target process;
updating the corresponding reference function address in the virtual function table data by adopting the target function address of each virtual function to obtain updated virtual function table data; the reference function address of the dummy function is used to indicate: before the communication connection is reestablished between the target process and the shared memory, the virtual function is located in an address space of the process address space of the target process.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; the processing unit is further used for:
After a target object of a target process is created in a shared memory, virtual function table data corresponding to the target process is obtained from a process address space of the target process;
copying the obtained virtual function table data to a designated area in the shared memory;
obtaining address offset of virtual function table pointers of one or more base classes of the target object; the address offset of the virtual function table pointer of the base class is used to indicate: an offset between an address space location pointed by the virtual function table pointer of the base class in the process address space and a starting address space location of the virtual function table data in the process address space;
the target memory location pointed to in the specified region is determined for the virtual function table pointer of each base class based on the address offset of the virtual function table pointer of one or more base classes and the memory address of the virtual function table data in shared memory.
In one implementation, the processing unit is configured to, when obtaining address offsets of virtual function table pointers of one or more base classes of the target object, specifically:
obtaining virtual function table pointers of each base class; the first pointer address of the virtual function table pointer of the base class is used to indicate: the function address of the virtual function to be called by the base class is at the address space position in the process address space;
And subtracting the first pointer address of the virtual function table pointer of each base class from the initial address of the virtual function table data in the process address space to obtain the address offset of the virtual function table pointer of each base class.
In one implementation, the processing unit is configured to, when obtaining the virtual function table pointer of each base class, specifically:
acquiring a base class pointer of each base class, wherein the base class pointer of the base class is used for pointing to a target object;
and performing pointer type conversion on the base class pointers of each base class to obtain virtual function table pointers of each base class.
In one implementation, the processing unit is configured to determine, for each base class of virtual function table pointers, a target memory location pointed to in a specified area based on address offsets of virtual function table pointers of one or more base classes and memory addresses of virtual function table data in the shared memory, specifically configured to:
acquiring the initial address of the copied virtual function table data in the shared memory;
the initial address of the virtual function table data in the shared memory is respectively added with the address offset of the virtual function table pointer of each base class to obtain a second pointer address of the virtual function table pointer of each base class; the second pointer address of the virtual function table pointer of the base class is used to indicate: the function address of the virtual function to be called by the base class is at the target memory position in the shared memory;
And replacing the first pointer address of the virtual function table pointer of the corresponding base class by adopting the second pointer address of the virtual function table pointer of each base class.
In one implementation, a processing unit is configured to obtain virtual function table data corresponding to a target process from a process address space of the target process; when the obtained virtual function table data is copied to the appointed area in the shared memory, the method is specifically used for:
acquiring a starting address and an ending address of virtual function table data in a process address space of a target process;
copying data between a start address and an end address in a process address space to a designated area in a shared memory; in the process address space, the data between the starting address and the ending address are virtual function table data.
In one implementation, virtual function table data of the target object is stored in a read-only reentrant section in a process address space, and an address of the read-only reentrant section in the process address space is determined by a program loader; when the read-only reentrant segment only contains the virtual function table data of the target object, the processing unit is configured to obtain a start address and an end address of the virtual function table data in the process address space, and specifically is configured to:
Acquiring a first address variable and a second address variable, wherein the first address variable is used for acquiring a start address of a read-only reentrant section, and the second address variable is used for acquiring an end address of the read-only reentrant section;
generating a target link script based on the first address variable and the second address variable, and attaching the target link script to a default script to obtain an attached default script;
and loading the attached default script by adopting a program loader, and outputting the start address and the end address of the read-only reentrant segment.
In one implementation, virtual function table data of a target object is stored in a read-only reentrant section in a process address space of a target process; when the read-only reentrant section contains one or more virtual function table data of different objects and the one or more virtual function table data contains virtual function table data of a target object, the processing unit is used for acquiring virtual function table data corresponding to the target process from a process address space of the target process; when the obtained virtual function table data is copied to the appointed area in the shared memory, the method is specifically used for:
acquiring one or more virtual function table data in a read-only reentrant section from a process address space of a target process;
And copying the acquired one or more virtual function table data to a designated area in the shared memory.
In this embodiment, a specified area is defined in the shared memory to cache virtual function table data, and each virtual function table pointer that needs to call the virtual function table data is bound at one time, that is, each virtual function table pointer is preset to point to the specified area in the shared memory, specifically to the memory location where the function address of the virtual function to be called in the specified area is located. Thus, after the target process is restarted at any time (which can be understood as reestablishing communication connection between the target process and the shared memory, or remapping the shared memory by the target process so that the target process can use the shared memory to cache data), only the updated virtual function table data in the process address space is required to be copied into the designated area, namely, new virtual function table data is adopted to cover the virtual function table data before the restart of the target process in the shared memory; the target process can call the function address of the virtual function required by the target process operation from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, so that the one-time restoration of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports dividing the appointed area in the shared memory to cache the virtual function table data, so that after the non-POD type data containing the virtual function table pointer is stored in the shared memory, the virtual function table pointer can directly read the correct function address of the virtual function to be called from the shared memory, and the validity of the virtual function table pointer is always maintained. In addition, the developer is not limited by the selection of the data type any more, and any custom object data can be stored in the shared memory, such as storing non-POD type object data or storing POD type object data in the shared memory.
Drawings
In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings that are required in the embodiments or the description of the prior art will be briefly described below, it being obvious that the drawings in the following description are only some embodiments of the present application, and that other drawings may be obtained according to these drawings without inventive effort for a person skilled in the art.
FIG. 1 is a schematic diagram of a memory space layout of a process address space according to an exemplary embodiment of the present application;
FIG. 2 is a diagram of a mapping between physical memory and virtual memory provided in accordance with an exemplary embodiment of the present application;
FIG. 3a is a schematic diagram of a memory processing scheme according to an exemplary embodiment of the present application;
FIG. 3b is a schematic diagram of another memory processing scheme according to an exemplary embodiment of the present application;
FIG. 4 is a flow chart of a memory processing method according to an exemplary embodiment of the present application;
FIG. 5 is a flow chart of copying virtual function table data from a process address space to a designated area in a shared memory according to an exemplary embodiment of the present application;
FIG. 6 is a schematic diagram of updating function addresses in virtual function table data after reestablishing a communication connection between a target process and a shared memory according to one exemplary embodiment of the present application;
FIG. 7 is a flowchart of another memory processing method according to an exemplary embodiment of the present disclosure;
FIG. 8 is a schematic diagram of determining a second pointer address for a virtual function table pointer provided in an exemplary embodiment of the present application;
FIG. 9 is a schematic diagram of a memory processing device according to an exemplary embodiment of the present application;
fig. 10 is a schematic structural diagram of a computer device according to an exemplary embodiment of the present application.
Detailed Description
The following description of the embodiments of the present application will be made clearly and fully with reference to the accompanying drawings, in which it is evident that the embodiments described are only some, but not all, of the embodiments of the present application. All other embodiments, which can be made by one of ordinary skill in the art based on the embodiments herein without making any inventive effort, are intended to be within the scope of the present application.
Technical terms and related concepts related to the embodiments of the present application are briefly described below, where:
1. Memory (Memory).
The memory may be referred to as an internal memory or a main memory, and is used for temporarily storing operation data in a central processing unit (Central Processing Unit, CPU), data exchanged with an external memory such as a hard disk, and the like. The memory in the operating system can be roughly divided into: physical Memory (Physical Memory) and Virtual Memory (Virtual Memory); the following will briefly describe the related contents of the physical memory and the virtual memory, where:
(1) Physical memory (Physical memory). The physical memory refers to a memory space obtained by a physical memory stripe deployed in a computer device; if the memory size of the physical memory in the operating system is fixed and if the memory size of the physical memory stripe deployed in the computer device is 4 megabytes (MByte, MB), then the memory size of the physical memory of the operating system deployed in the computer device is determined to be 4 megabytes.
When a process in an operating system has a need to create a shared area from physical memory to achieve data sharing and transfer between multiple processes, any process may apply to the operating system to create a shared memory. Shared memory is a common data caching scheme that allows multiple processes to access the same memory space to enable sharing and transferring data between the multiple processes. Specifically, when the operating system detects that a process has a requirement for creating a shared memory (for example, the process initiates a request for creating the shared memory), the operating system arranges the same memory area (namely, the shared memory) for different processes in the physical memory, so that a plurality of processes can connect the shared memory to the address space of the processes so as to realize data sharing in the shared memory; in other words, each process establishes communication connection with the shared memory, and each process can access the address in the shared memory to acquire the data stored in the shared memory. Further, if one process modifies data in the shared memory, the data read from the shared memory by other processes will also change. That is, the shared memory is a memory space divided by the operating system from the physical memory for a plurality of processes, and supports the processes to perform data read-write (read and write) operations in the shared memory, so as to realize data sharing and transfer by the processes through the shared memory.
In addition to the above-mentioned feature of supporting multi-process access, the shared memory is different from the common memory and has the following features: when a process exits (such as a connection failure between the process and the shared memory), if the data in the shared memory is not actively released by the process, the data in the shared memory is not recovered by the operating system; after the process has remapped the shared memory, the process data can be restored. This is because the shared memory supports mapping data in memory to local files to ensure that data is not lost at the end of a process; and, can resume the memory data according to the local file after the process restarts (namely, the process and the shared memory reestablish the communication connection). Thus, depending on the data caching characteristics of the shared memory, the shared memory is often used for short-term persistence of data (e.g., when storing non-POD type data in the shared memory, short-term persistence of the non-POD type data in the shared memory may be achieved) and fast recovery of data after a process crash.
(2) Virtual Memory (Virtual Memory). Unlike physical memory, virtual memory is a memory space that an operating system virtualizes for a process, providing an independent and private memory space for the process; through a virtual memory mechanism, the process occupies all physical memory for itself. The above-mentioned Process is a running activity of a program in a computer on a certain data set, is a basic unit of resource allocation and scheduling of a system, and is a basis of an operating system structure. Briefly, a process may be understood as a program running in an operating system; for example, when a computer device opens and runs a game-like application, a process needs to be started for the running of the game to achieve successful running of the game through the process.
Taking an operating system with 48 bits of virtual memory as an example, its virtual address space (i.e., the process address space of a process)Is in the range of
TeraByte (TB) and kernel space (kernel space) and user space each occupy 128TB, divided in a 1:1 ratio; the memory space layout of the process address space of the process can be seen in fig. 1. As shown in fig. 1, for a process, the user space in its process address space is approximately distributed as follows: program segments (Text), initialized Data (Data), uninitialized Data (BSS), stack (Stack), and Heap (Heap). Wherein: the program segment is used for storing the mapping of the process code in the memory, and storing the binary code of the function body (namely, the whole of all codes defining one function in the programming language). Initialized data refers to data that has been initialized for variables at the beginning of program execution. Uninitialized data refers to data that has not been initialized for variables at the beginning of program execution. The stack is used for storing local and temporary variables; storing a return pointer of the function and controlling the call and return of the function when the function is called; memory is automatically allocated at the beginning of a block and is automatically released at the end of a block, in a manner similar to a stack in a data structure. The heap is used for realizing the allocation of the storage dynamic memory, and needs manual allocation and manual release of a developer; the heap in the process address space and the heap in the data structure are two-way, and are distributed in a similar manner to a linked list. Furthermore, as can be seen from the structure of the process address space shown in fig. 1, the address space layout of the process is "segment+page", i.e. the process address space of the process is implemented in the form of "segment+page". Segmentation refers to dividing a memory into segments (e.g., code segments, data segments, … …), and the length of each segment may be different.
To improve security of the process address space, an address space layout randomization (Address Space Layout Randomization, ASLR) mechanism is supported to be added in the operating system; the ASLR mechanism prevents an attacker from jumping to a specific position of the memory to utilize a function by randomly placing an address space of a key data area of a process so as to prevent a malicious program from attacking a known memory address. The key data areas mentioned above may include, but are not limited to, code segments (.text), data segments (.data or. Bss), heap regions (.heap), stack regions (.stack), mmap (memory mapped segments), dynamic libraries, and the like in the process address space.
Based on the above description of the physical memory and the virtual memory, the operating system allocates a virtual process address space for the process, but the data and codes of the process must be put into the physical memory, so a mechanism must be provided to memorize which physical memory address is put into a certain data in the process address space, which is called address space mapping; i.e. the mapping of virtual memory addresses to physical memory addresses. In practical application, the mapping relation from virtual memory address to physical memory address is recorded through page table. The page table can be used for storing the mapping relation between the virtual memory address and the physical memory address; each process has its own page table so that each process can determine its own mapping relationship between virtual memory address and physical memory address by its own page table.
A schematic diagram of an exemplary mapping between physical memory and virtual memory may be seen in fig. 2; as shown in FIG. 2, there is a block of physical memory in the operating system, the process address space of process 1 (alternatively referred to as the virtual address space, i.e., the virtual memory mentioned above), and the process address space of process 2. For processes (such as process 1 and process 2), the corresponding process address space is similar to a look-up table through which the process reads data from physical memory; for example, when the process 1 wants to acquire data in the virtual space a in the process address space, the virtual memory address of the virtual memory a should be converted into the physical memory address a, and then the data should be read from the physical memory address a in the physical memory. Notably, unused address space in the process address space is not mapped into physical memory, so that the operating system does not need to allocate physical memory for that segment of address space; in this way, the physical memory allocated by the kernel to the process just created can be very small, and the kernel allocates physical memory to the process as required as the process runs and uses the memory continuously.
2. Data.
The data related to the embodiment of the application mainly comprises: POD (Plain Old Data) type Data and non-POD type Data. The biggest difference between POD type data and non-POD type data on the data plane is that: whether a virtual function table pointer is included; the virtual function table pointer is a key data structure for implementing virtual functions and virtual base classes. The description will be made below of the above-mentioned POD type data, non-POD type data, virtual functions, virtual base classes, virtual function table pointers, and the like.
In practical application, the bottom layer of the operating system is basically written in a C (programming language), and after basic data types (such as int (integer), char (pointer), float (floating point), enumeration, pointer, array, structure, etc.) defined in the C language are copied by binary, the data can still be kept unchanged, that is, the compiler can correctly parse the data in the basic data types through binary data. However, classes in the computer high-level programming language c++ (C plus) generated by the expansion and upgrading of the C language (which is a procedural-oriented, abstract general-purpose programming language, widely applied to bottom development) introduce new concepts such as inheritance and derivation, and the compiler cannot parse these complex data structures; therefore, the c++ language proposes the concept of a POD data structure in order to be compatible with the C language. That is, the POD type data is a data structure defined by the c++ language and compatible with the C language.
Specifically, the POD type data may refer to a class (class), a structure (struct), etc., capable of operating using a function such as memcpy () of C language; since the data types basically built in the c++ language are all POD types, it is generally discussed whether classes (class), structures (struct), and variables (unit) are POD type data. For example, data belonging to the POD type may include, but is not limited to: default constructors (methods for initializing objects when they are created) and destructors (methods for cleaning up data (e.g., freeing memory space allocated when objects are created) after the object has finished the generation cycle), default copy constructors (methods for completing construction and initialization based on the same class of objects) and move constructors (methods for implementing resource transfer of objects), default copy assignment operators and move assignment operators; etc., the virtual functions and/or virtual base classes cannot be included in these POD-type data.
It should be noted that (1) the above-mentioned class is a collection of different objects (or called instances, such as objects belonging to a class of vehicles that may include bicycles, cars, trucks, etc.) that share the same features in the programming language c++. A member function for each object may be defined in the class; when a class is created, the class needs to be instantiated before use, that is, an instance (i.e., an object) of the class is created, and an operating system allocates an internal space in a shared memory for the instance of the class, so that an instance method of the object can be invoked to realize some functions. In the C++ language, classes have inheritance; inheritance is the creation of a new class based on an existing class; the original program codes can be reused by utilizing the inheritance of the class, thereby reducing the redundancy of the program codes, enhancing the function of the programming language and improving the software development efficiency. In the inheritance relationship, the inherited class is called a base class (or parent class), and the new class created by the inheritance relationship is called a derived class (or child class); the derived class inherits the data and functions of the base class, which may point to the derived class object (i.e., the data resulting from the instantiation of the derived class) through the base class pointer.
(2) The virtual function refers to a member function in the class that is modified by a keyword, where the keyword is virtual. The virtual base class refers to a virtual base class if only one instance of the base class is to be saved after multiple instances (or objects) are generated based on multiple inheritance paths of the base class. In practical application, in order to realize polymorphism during process operation, a compiler adds a virtual function table pointer vtptr for an object on generating object data memory layout; the virtual function table pointer points to a read-only area, and the read-only area stores a piece of virtual function table data (or virtual function table for short); the virtual function table is used to record the function addresses (i.e., address space locations (i.e., memory locations) of the virtual functions in the process address space of the target process) of one or more virtual functions of the object. Thus, the object or the base class of the object can acquire the function address of the virtual function from the virtual function table through the pointers of the respective virtual function table, so that the virtual function is read from the process address space of the target process according to the function address of the virtual function.
(3) Polymorphism is a core concept in the field of object-oriented programming; the base class pointer, which is simply summarized as a base class, points to the object of the subclass, and then the member function (e.g., virtual function) of the object is called through the object pointer of the base class. That is, polymorphism refers to which virtual function a base class calls, depending on which type of object the pointer object of the base class points to. The above mentioned polymorphic and virtual functions are briefly described below by way of exemplary codes as follows:
#include
File with head
using namespace std;// declaration variables
class A// class A
{
public:// public members
virtual void Print() { cout
endl }// virtual function
(v/inheritance class A)
class B public A// class B
{
public:// public members
virtual void Print() { cout
Endl }// rewriting the virtual function
(v/inheritance class A)
class C public A// class C
{
public:// public members
virtual void Print() { cout
Endl; }// rewriting the virtual function +.>
(v/inheritance class A)
Main function of int main ()// return integer data
{
B b; C c;
A
pa =&b;// base class pointer pa points to derivative class object b
pa- > Print ();// polymorphism, b.print () is called, outputs: b: print
pa= & c;// base class pointer pa points to derivative class object c
pa- > Print ();// polymorphism, c.print () is called, outputs: c: print
return 0;// return 0
}
As can be seen from the above code, the virtual key is added to the member function Print () of the base class a, and the member function Print () is determined to be a virtual function. The virtual function of which derived class object (such as derived class object B inheriting the base class A or derived class object C inheriting the base class A) is specifically called by the base class A depends on the object type pointed by the base class A base class pointer; that is, when the base class pointer of the base class is used for calling, the interface actually called by the base class pointer is dynamically determined according to the object pointed by the pointer. For example, the member function is rewritten in the derived class object B (or the derived class object C) (e.g., the member function is rewritten in the derived class object B as: print () { cout) 
endl }; at program run-time, if the base class pointer pa of the base class a points to the derived class object B, it is determined that the base class a calls a member function (Print () { cout) of the derived class object B
endl;) and then output B:: print. For another example, the base class pointer pa of base class A points to the derived class pairLike C, it is determined that the base class A calls a member function (Print () { cout +.>
endl;) and then output C:: print.
Based on the related description of the shared memory, the shared memory not only supports multi-process access, but also can realize data short-term persistence and data recovery; these advantages of shared memory make storing data in shared memory an indispensable development step for developers in development engineering. However, when data management of the shared memory is realized, only POD type data can be stored in the shared memory, and non-POD type data cannot be stored. This is because object data containing virtual functions or virtual base classes may introduce virtual function table pointers and virtual function table data for implementing polymorphisms. The virtual function table pointer is used for pointing to virtual function table data, the virtual function table pointer and object data of a target object are stored together, and virtual function table data of different objects belonging to the same class are uniformly placed in a process virtual space called a read-only reentrant section (. Data. Rel. Ro), and the read-only reentrant section is positioned in a code section (. Text) of a process address space; for convenience of explanation, the following will take the example of the virtual function table data only including the target object in the read-only reentrant segment, which is specifically described herein. As shown in fig. 3a, a code section (text) 301 in the process address space contains a read-only reentrant section in which virtual function table data of the target object is stored. The virtual function table data is a continuous memory, and is similar to an array, the virtual function table data contains function addresses of one or more virtual functions declared for a target object (such as any object), and the function address of any virtual function is used for indicating: the address space position of any virtual function in the process address space, namely the storage position of the function information of any virtual function in the process address space. As shown in FIG. 3a, the virtual function table data contains the function address 303 of the virtual function 302, where the function address 303 may be considered as a function pointer (ptr) for pointing to the virtual function 302, the function pointer pointing to the address space location in the code segment where the virtual function 302 is stored, so that the virtual function (e.g., obj:: fun 1) may be read from the function address 303.
Because of the ALSR mechanism in the operating system, after each restart of the target process, the address space of each segment (including the code segment) in the process address space of the target process is not fixed, so that the address of the read-only reentrant segment contained in the code segment changes (specifically, the starting address and the ending address of the read-only reentrant segment in the process address space change after the communication connection is reestablished between the target process and the shared memory each time), and then the address of the virtual function table data contained in the read-only reentrant segment changes, that is, the virtual function table pointed by the virtual function table pointer changes. Then based on the virtual function table pointer stored in the shared memory before the process is restarted, the virtual function table data after the process is restarted cannot be read from the process address space, so that the virtual function table pointer will fail after the target process is restarted. Therefore, the virtual function table data cannot be reused by the virtual function table pointer after the target process is restarted, so that the selection of the data stored in the shared memory in the actual development process is greatly limited, namely only POD type data can be stored, but non-POD type data containing the virtual function table pointer cannot be stored, the data types supported by the shared memory are limited, and the data customized to be stored in the shared memory by a developer is greatly limited.
Based on this, the embodiment of the application provides a memory processing scheme, and the scheme is specifically a scheme for persisting non-POD type data in a shared memory. That is, the memory processing scheme is not limited to the data types stored in the shared memory, that is, the shared memory can not only hold POD type data, but also can permanently store non-POD type data, wherein the non-POD type data comprises virtual function table pointers corresponding to the target process, and the validity of the virtual function table pointers in the non-POD type data is maintained, so that a developer is helped to store any type of custom data in the shared memory. The memory processing schemes provided in the embodiments of the present application can be generally divided into fig. 3a and 3 b: a preset phase and a restart phase. Wherein:
(1) in the preset stage, when the target process is started for the first time, virtual function table data in a process address space of the target process is copied into a designated area in the shared memory (as shown in fig. 3 a), so as to determine the memory position pointed by a virtual function table pointer in the shared memory; and modifying the virtual function table pointer originally pointing to the virtual function table data in the process address space to point to the specified area (as shown in fig. 3a or fig. 3 b) when the target object is created (i.e., the process of writing the class in the target process into the shared memory and creating the target object corresponding to the class in the shared memory). That is, in the preset phase, the virtual function table pointer is preset to point to a target memory location in the specified area, where the target memory location refers to: and the function address of the virtual function to be called by the virtual function pointer in the virtual function table data is stored in a designated area. As shown in fig. 3b, assuming that after the virtual function table data is copied to the designated area in the shared memory, the virtual function table pointer is to call the function address of the virtual function, and the storage location in the designated area is 0x4568445, the pointer address of the virtual function table pointer is set to 0x4568445. Therefore, in the preset stage, the virtual function table pointer is only required to be fixedly pointed to the target memory position in the appointed area in the shared memory, but not to the process address space, so that the invalidation of the virtual function table pointer caused by the change of the address of each section in the process address space can be avoided.
(2) In the restart stage (i.e., the stage of restarting (or simply restarting) the target process), the virtual function table data updated by the function address in the process address space needs to be copied back to the designated area (as shown in fig. 3a or fig. 3 b), specifically, the virtual function table data in the designated area is covered with the updated virtual function table data (the virtual function table data is copied into the designated area before the target process is restarted this time). Therefore, the function addresses contained in the virtual function table data can be updated at one time in the designated area, namely the function addresses are replaced with correct function addresses, so that the virtual function table pointers pointing to the function addresses can be repaired at one time, and the target process can call virtual functions required by the target process from the virtual function table data stored in the designated area through the virtual function table pointers.
In summary, according to the memory processing scheme provided by the embodiment of the application, the virtual function table data of the non-POD type data is modified only when the target object is created, and the virtual function table data stored in the shared memory is modified at one time when the target process is restarted, so that the repair of all virtual function pointer data can be completed, and the virtual function pointer is ensured to be effective all the time. For a developer, the type of data which can be stored in the shared memory does not need to be considered, for example, the developer can directly store non-POD type data into the shared memory, so that the developer is helped to store custom data of any data type into the shared memory, the problem of data failure after the process is restarted does not need to be considered, and the data storage flow is optimized.
Based on the above description of the memory processing scheme provided in the embodiments of the present application, the following points are worth explaining:
(1) as described above, the concepts of classes, virtual function table pointers, virtual function table data, and the like, which are related to the embodiments of the present application, are proposed by the c++ language; therefore, the memory processing scheme provided by the embodiment of the application has universality and is suitable for all application scenes which are written by using the C++ language and need to carry out data recovery of the shared memory. For example, in a scenario where game code is written in the c++ language, to ensure continuity of a game, it is often necessary to allocate a shared memory for a plurality of processes required for running the game, and then virtual function table data in the data may be copied to a designated area in the shared memory. Therefore, when the process is restarted (for example, after the game player exits the game due to network connection failure of the game player, the game player needs to reenter the game, namely, the process is restarted at the moment), the updated virtual function table data is copied to the designated area again, and the virtual function table pointer in the shared memory can read the function address of the correct virtual function from the designated area, so that the continuity of the game in the game scene is ensured. Of course, the foregoing is only an exemplary application scenario of the embodiment of the present application, and the embodiment of the present application does not limit the specific application scenario of the memory processing scheme.
(2) Embodiments of the present application support execution of memory processing schemes by computer devices. The computer device may be any device including a memory; alternatively, the computer device may be a terminal device, which may include, but is not limited to: the types of terminal devices are not limited in the embodiments of the present application, and examples of the devices include smart phones, tablet computers, portable personal computers, mobile internet devices (MID for short), vehicle-mounted devices, and head-mounted devices. Optionally, the computer device may be a server, where the server may be an independent physical server, or may be a server cluster or a distributed system formed by multiple physical servers, or may be a cloud server that provides cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communications, middleware services, domain name services, security services, CDN (Content Delivery Network ), and basic cloud computing services such as big data and artificial intelligence platforms; the embodiment of the application does not limit the specific type of the server.
Based on the above-described memory processing scheme, the embodiment of the present application proposes a more detailed memory processing method, and a detailed description will be given below of a specific implementation procedure of the process restarting stage in the memory processing method according to the embodiment of the present application with reference to fig. 4. FIG. 4 is a flow chart illustrating a memory processing method according to an exemplary embodiment of the present application; the memory processing method may be performed by the above-mentioned computer device, and the memory processing method may include, but is not limited to, steps S401-S403:
S401: after the communication connection is reestablished between the target process and the shared memory, determining a designated area in the shared memory.
In a specific implementation, after the target process exits for some reason (i.e. the target process ends the life cycle), it is determined that the communication connection between the target process and the shared memory is disconnected, i.e. the target process cannot read data from the shared memory. The reason why the target process exits is not limited in the embodiment of the present application. For example, when a game player exits a game room due to a network failure in a game scenario, a target process assigned to the game is determined to exit. And the following steps: in a game scenario, the target process exits due to the game player wanting to switch processes (e.g., during the course of a game in a game room, want to switch to a social application to view social information, at which point the target process assigned to the game exits). Further, when the target process is restarted, the communication connection between the target process and the shared memory needs to be re-established at this time, so that after the communication connection is successfully established, the target process can read data from the shared memory. The process of reestablishing the communication connection between the target process and the shared memory may include: the target process reconnects the shared memory to the process address space of the target process so as to reestablish the address mapping relationship between the process address space and the shared memory; for the relevant content of the address mapping relationship between the process address space and the shared memory, reference may be made to the foregoing relevant description, which is not repeated herein.
Furthermore, after the communication connection is reestablished between the target process and the shared memory, that is, after the target process is restarted successfully, the designated area in the shared memory needs to be determined, so as to prepare for subsequent data copying. The designated area in the shared memory may refer to: the shared memory is used for storing the virtual function table data corresponding to the target process; the specific location of the specific area in the shared memory may be specifically located in a shared memory mapping section (mmap section) in the shared memory, as shown in fig. 3a, where the specific location of the specific area in the shared memory mapping section is not limited in the embodiment of the present application. The designated area in the shared memory may be designated at the time of creation of the target object; specifically, when the target object is created, a default area is defined in the shared memory as a designated area for storing the virtual function table data of the target object, so that the virtual function table data of the target object (i.e., the virtual function table data corresponding to the target process mentioned above) can be copied into the designated area later.
Notably, the number of classes in a target process is often rich, and instantiating a class can result in one or more objects. In order to facilitate management of virtual function table data for objects of different classes in a shared memory, embodiments of the present application support partitioning of one or more objects of the same class in the shared memory into a designated region, and partitioning of different designated regions in the shared memory into different classes of objects. By partitioning a specified region for one or more objects of the same class, it may be meant that: virtual function table data for one or more objects belonging to the same class may be stored in the same designated area in shared memory. The division of different designated areas for different classes of objects may refer to: virtual function table data of objects belonging to different classes are stored in different designated areas in the shared area. For example, assuming that object 1 and object 2 belong to class 1 and object 3 belongs to class 2, partitioning of designated region 1 in shared memory is supported to store virtual function table data of object 1 and virtual function table data of object 2 in class 1, partitioning of designated region 2 in shared memory is supported to store virtual function table data of object 3 in class 2. For convenience of explanation, the embodiment of the present application uses a designated area in the shared memory, where the designated area is used to store virtual function table data of a target object (such as any object) after class instantiation, which is described herein.
S402: and acquiring virtual function table data corresponding to the target process from a process address space of the target process.
S403: and copying the acquired virtual function table data to a designated area in the shared memory.
In steps S402 to S403, after remapping the shared memory and the target process based on the foregoing steps, the embodiment of the present application further needs to obtain virtual function table data corresponding to the target process, specifically virtual function table data of the target object in the target process, where the virtual function table data includes function addresses of one or more virtual functions declared for the target object; so as to copy the acquired virtual function table data to the appointed area in the shared memory. Thus, the virtual function table pointer in the shared memory for calling the virtual function can successfully call the virtual function by pointing to the designated area in the shared memory.
It should be noted that, as can be seen from the foregoing description, on the one hand, the virtual function table data of the target object is a read-only reentrant segment stored in the process address space; the read-only reentrant segment may be used to store virtual function table data for different objects belonging to the same class, where the different objects belonging to the same class include the target object. On the other hand, the virtual function table data of different objects in the same class in the shared memory is divided into the same designated area, that is, the virtual function table data of different objects in the same class can be stored in the same designated area in the shared memory. Based on the above, when the virtual function table data is copied from the process address space to the designated area in the shared memory, specifically, all the data contained in the read-only reentrant section where the virtual function table data is located in the process address space is copied to the designated area in the shared memory. For example, assume that one or more virtual function table data of different objects belonging to the same class are included in the read-only reentrant section, and virtual function data of the target object is included in the one or more virtual function table data; the process of obtaining the virtual function table data corresponding to the target process from the address space of the target process and copying the obtained virtual function table data to the designated area in the shared memory may include: and acquiring one or more virtual function table data in the read-only reentrant section from a process address space of the target process, and copying the acquired one or more virtual function table data to a designated area in the shared memory. By the way of copying all data in the read-only reentrant section, batch copying of the virtual function table data of different objects belonging to the same class can be realized, and compared with independent copying of the virtual function table data of each object in the read-only reentrant section, the data copying speed and efficiency are greatly improved.
For convenience of explanation, taking the virtual function table data only containing the target object in the read-only reentrant section in the process address space as an example, the specific implementation process of copying the virtual function table data from the process address space to the execution area in the shared memory is described; wherein, this implementation can be seen in FIG. 5, including but not limited to steps s11-s12:
s11: and acquiring a start address and an end address of the virtual function table data in a process address space. Wherein the virtual function table data is a section of memory, and the address space occupied by the virtual function table data in the process address space is: a continuous area from a start address in the process address space of the memory to an end address in the process address space of the memory; the memory size occupied by the continuous area is the memory size occupied by the virtual function table data in the process address space.
It should be understood that when only the virtual function table data of the target object is included in the read-only reentrant section, the start address of the virtual function table data in the process address space may be considered as: a start address of the read-only reentrant segment in the process address space; the end address of the virtual function table data in the process address space is: a start address of the read-only reentrant segment in the process address space; the memory size occupied by the virtual function table data in the process address space is as follows: the memory size occupied by the read-only reentrant segment in the process address space. The start address and the end address of the read-only reentrant segment are acquired, and the start address and the end address of the virtual function table data in the process address space can be determined, so that the virtual function table data is copied based on the start address and the end address of the virtual function table data in the process address space.
It is contemplated that the address of the read-only reentrant section in the process address space is determined by the program loader (or process loader) each time the target process is loaded, and the behavior of the program loader is controlled by the linker (linker) of the program through a link script (linker script). That is, when the program loader loads the link script through the linker, the memory occupied in the process address space may be determined for the read-only reentrant segment, that is, the start address and the end address of the read-only reentrant segment in the process address space may be determined. Wherein (1) the program loader mentioned above is responsible for loading the program, specifically placing the program into memory and letting the program start running in the memory; the linker mentioned above supports resolving undefined symbolic references, replacing placeholders in the file with addresses of symbols. (2) The above-mentioned link script is an executable file that supports being loaded into a process address space by a process loader to begin performing certain functions; for example, after the linking script is loaded into the process address space, it may be used to specify that each data in the program is placed in a different segment in the process address space, and may also be used to control the program loader to assign variables (such as __ executable_start program start position and __ etext code segment end position) when some target processes run.
As can be seen from the above description, the program loader determines the address for the read-only reentrant section by loading the link script; thus, embodiments of the present application support having the program loader export the start address and end address of the read-only reentrant segment by generating a linked script. The method for leading the program loader to derive the start address and the end address of the read-only re-entry segment by loading the link script does not need to additionally increase equipment or devices and change the original loading mode of the program loader, can reduce the invasiveness to the original code by adopting the original loading mode of the program loader, has smaller memory occupied by the link script for acquiring the read-only re-entry segment, and does not generate larger memory expenditure.
In the specific implementation, a first address variable and a second address variable are firstly acquired, wherein the first address variable is used for acquiring a start address of a read-only reentrant section, and the second address variable is used for acquiring an end address of the read-only reentrant section; then, generating a target link script based on the first address variable and the second address variable, wherein the target link script is used for requesting a program loader to export a start address and an end address of the read-only reentrant segment; then, the target link script is added to a default script (i.e. a script containing the original logic when the program is loaded), after the added default script is obtained, the program loader can be used to load the added default script, and at this time, the program loader can output the start address and the end address of the read-only reentrant segment. An exemplary target link script is illustrated as follows:
/
get vtable section start address./>
/
__ vtable_start __ =addr (.data. Rel. Ro);// get the start address of the read-only re-entry segment
/
get vtable section end address./>
/
__ vtable_end __ = __ vtable_start __ +sizeof (. Data. Rel. Ro);// get end address of read-only re-entry segment
Wherein "+.
get vtable section start address./>
The function of the code for annotating the next row "__ vtable_start __ =addr (.data. Rel. Ro)": the start address of the read-only re-entry segment is obtained. Similarly, "/-, in the code above>
get vtable section end address./>
The function of the code "__ vtable_end __ = __ vtable_start __ +sizeof (data. Rel. Ro)" for annotating the next row is: an end address of the read-only reentrant segment is obtained. The aforementioned first address variable is "__ vtable_start __" in the aforementioned code; the aforementioned second address variable is "__ vtable_end __" in the code.
s12: copying data between a start address and an end address of a read-only reentrant section in a process address space to a designated area in a shared memory; the data between the start address and the end address of the read-only reentrant section is virtual function table data of the target object.
Based on the target link script shown in step s11, after the start address and the end address of the read-only reentrant segment are obtained, the memory size occupied by the read-only reentrant segment in the process address space can be determined through the start address and the end address, so that the data (i.e., the virtual function table data) in the read-only reentrant segment is copied to the designated area in the shared memory directly through the start address, the end address and the memory size. Illustratively, the code in copying the data in the read-only reentrant segment based on the start address, end address, and memory size is as follows:
Special symbol X of// customization
The start address of the read-only reentrant segment where the data of the virtual function table is located is/are written in the external char __ vtable_start __ [ ]
The ending address of the read-only reentrant segment where the data of the virtual function table is located is/are written in the external char __ vtable_end __ [ ]
Long size= (long) __ vtable_end __ - (long) __ vtable_start __;// memory size of read-only reentrant segment
memcpy (dest, __ vtable_start __, size);// copying data in the read-only reentrant section to a specified region (e.g., the specified region is addressed to the dest address)
The code can determine that the read-only reentrant section occupies the memory size long size in the process address space according to the start address and the end address of the read-only reentrant section after the start address and the end address of the read-only reentrant section are acquired; the method specifically comprises the step of subtracting a starting address from an ending address to obtain the memory size long size occupied by the read-only reentrant segment in a process address space. It should be noted that, the above-mentioned custom special symbol X needs to be linked to the shm.lds file loaded by the linker, so that when the linker loads the shm.lds, the code of the linked special symbol X can be loaded together, so as to implement the function (i.e. copying the virtual function table data in the read-only reentrant section to the designated area in the shared memory) reached by the code (i.e. the code of the special symbol X).
As can be seen from the above steps s11 and s12, on the one hand, in the embodiment of the present application, after the start address and the end address of the read-only reentrant segment are derived through the target link script, virtual function table data in the read-only reentrant segment can be directly copied from the process address space to the designated area in the shared memory through the start address and the end address; the data is flexibly copied through the address, the data copying speed and efficiency are improved to a certain extent, and the data copying performance is improved. On the other hand, considering that the read-only re-entry segment is only used for storing the virtual function table data, that is, the read-only re-entry segment does not contain other data except the virtual function table data, the embodiment of the application does not care about specific data content in the read-only re-entry segment, and only needs to copy all the data contained in the read-only re-entry segment, so the embodiment of the application considers that all the data between the start address and the end address are copied directly based on the start address and the end address of the read-only re-entry segment, and does not need to care about the copied data content. Further, as can be seen from the foregoing description of the program loader, the address of the read-only reentrant section in the process address space is determined by the program loader, and when the program loader loads the link script, the link script can control the program loader to export the variables (such as the start address and the end address of the program) during running; this makes the procedure of exporting the start address and the end of the read-only reentrant segment by letting the program loader load the target link script, which is consistent with the original loading logic of the program loader, ensures the feasibility of address export.
In addition, as can be seen from the foregoing description, in order to ensure data security, an ASLR mechanism is introduced into the operating system, which causes the address of each segment in the process address space of the target process to change after each restart; if the addresses of the code segments in the process address space change, virtual functions and virtual function table data are stored in the code segments, this also results in a change of the function addresses of the virtual functions in the process address space. Therefore, after the target process is restarted, the function address contained in the virtual function table data in the read-only reentrant section is updated once, so that the function address in the updated virtual function table data can point to the correct storage position of the corresponding virtual function, and the virtual function table pointer can only find the virtual function to be called from the process address space based on the function address.
In a specific implementation, after the communication connection is reestablished between the target process and the shared memory, the target function addresses of one or more virtual functions of the target object may be obtained, where the target function addresses of the virtual functions are used to indicate: after the communication connection is reestablished between the target process and the shared memory, the address space position (or storage position) of the virtual function updated in the process address space is obtained; then, updating the corresponding reference function address in the virtual function table data by adopting the target function address of each virtual function to obtain updated virtual function table data; wherein the reference function address of the dummy function is used to indicate: the virtual function is at an address space location (or storage location) in the process address space before the communication connection is reestablished between the target process and the shared memory. As shown in fig. 6, it is assumed that, before the communication connection is reestablished between the target process and the shared memory, the function address of the virtual function table data containing the virtual function a is 0x1234, which indicates that the storage location of the virtual function a in the process address space is where the function address 0x1234 is located; after the communication connection is rebuilt between the target process and the shared memory, the address space position of the virtual function A in the process address space changes, if the storage position of the virtual function A in the process address space changes to be 0x2234, the function address 0x2234 of the virtual function is adopted to replace the function address 0x1234 in the virtual function table data, so that the function address of the virtual function A is updated in the virtual function table data. Further, the replacement process is executed for each function address in the virtual function table data, so that updated virtual function table data can be obtained.
Furthermore, the updated virtual function table data is copied to the appointed area in the shared memory, so that the function addresses of the virtual functions stored in the appointed area can be updated at one time or in batches, and the virtual function table pointers pointing to the function addresses of the virtual functions can be repaired at one time.
In summary, after the target process is restarted (i.e. the communication connection is reestablished between the target process and the shared memory) at any time, the embodiment of the application supports that only the updated virtual function table data in the process address space is copied to the designated area, that is, the new virtual function table data is adopted to cover the virtual function table data before the restart of the target process; the target process can call the function address of the virtual function required by the target process operation from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, so that the one-time restoration of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports dividing the appointed area in the shared memory to cache the virtual function table data, so that after the non-POD type data containing the virtual function table pointer is stored in the shared memory, the virtual function table pointer can directly read the correct function address of the virtual function to be called from the shared memory, and the validity of the virtual function table pointer is always maintained. In addition, the developer is not limited by the selection of the data type any more, and any custom object data can be stored in the shared memory.
The embodiment shown in fig. 4 mainly describes the specific implementation process of the process restart stage in the memory processing method in detail, and the specific implementation process of the preset stage in the memory processing method is described in detail below with reference to fig. 7. FIG. 7 is a flow chart illustrating a memory processing method according to an exemplary embodiment of the present application; the memory processing method may be performed by the above-mentioned computer device including a memory, and the memory processing method may include, but is not limited to, steps S701-S707:
s701: after a target object of the target process is created in the shared memory, virtual function table data corresponding to the target process is obtained from a process address space of the target process.
S702: and copying the acquired virtual function table data to a designated area in the shared memory.
In steps S701-S702, when the target process is started for the first time, copying virtual function table data of a target object in a process address space of the target process to a designated area in the shared memory is supported, so that when the target object is created (for example, a class is loaded to the shared memory and the target object of the class is created in the shared memory), based on a memory address of the virtual function table data in the shared memory, a pointer address (referred to as a first pointer address in the embodiment of the present application) pointed to by each virtual function table pointer pointing to the virtual function table data is replaced by a memory address of the virtual function table data in the shared memory; thus, no matter whether the target process is restarted or not later, the pointer address (called a second pointer address in the embodiment of the application) of the virtual function table pointer is not required to be updated, and the validity of the virtual function table pointer can be maintained.
It should be noted that, the specific implementation process of acquiring the virtual function table data corresponding to the target process from the process address space and copying the acquired virtual function table data to the designated area in the shared memory shown in steps S701-S702 is similar to the specific implementation process shown in steps S402-S402 in the embodiment shown in fig. 4, and reference may be made to the related descriptions in steps S402-S402, which are not repeated herein.
S703: an address offset of virtual function table pointers of one or more base classes of the target object is obtained.
After non-POD type data is successfully created in the shared memory (e.g., non-POD type data including virtual function table pointers is stored in the shared memory, and virtual function table data pointed by the virtual function table pointers is copied to a designated area in the shared memory), the embodiment of the present application supports modification of the data of the virtual function table pointers of the non-POD type data, that is, address replacement is performed on all virtual function table pointers of the virtual function table data pointed to the target object; the virtual function table data processing method comprises the steps of replacing first pointer addresses of virtual function table pointers of all virtual function table data pointing to a process address space with addresses of virtual function table data stored in a designated area in a shared memory. Thus, the virtual function table pointer after address replacement can read the function address of the virtual function to be called from the virtual function table data stored in the designated area in the shared memory.
In practical application, the base class of the target object (namely the parent class inherited by the class of the target object) can call any virtual function of the target object through the virtual function table pointer; the arbitrary virtual function may include: the target object inherits virtual functions from the base class or virtual functions specific to the target object. Thus, all the above mentioned virtual function table pointers to the virtual function table data of the target object may comprise: virtual function table pointers for one or more base classes of the target object.
The embodiment of the application supports the determination of the pointed address in the appointed area in the shared memory for the virtual function table pointer through the address offset of the virtual function table pointer of the base class so as to realize the restoration of the virtual function table pointer. Wherein the address offset of the virtual function table pointer of any base class may be used to indicate: an offset between an address space location pointed to by the virtual function table pointer of the base class in the process address space and a starting address space location of the virtual function table data in the process address space. In other words, as described above, the virtual function table data is an array in which the function addresses of one or more virtual functions are sequentially stored, and then the address offset of the virtual function table pointer of any base class indicates: in the process address space, the virtual function table data is arranged with the function address of the virtual function to be called by the virtual function table pointer. For example, in the virtual function table data, the function address 1 of the virtual function 1, the function address 2 of the virtual function 2 and the function address 3 of the virtual function 3 are arranged in sequence, and the virtual function table pointer points to the function address 3 of the virtual function 3 in the virtual function table data, the address offset of the virtual function table pointer is 3, which indicates that the offset of the address pointed by the virtual function table pointer relative to the starting address of the virtual function table data is 3.
In a specific implementation, the implementation process of determining, for the virtual function table pointer, the address pointed to in the specified area in the shared memory by using the address offset of the virtual function table pointer of the base class may include:
first, one or more base classes of a target object are obtained. Taking into account that the base class of the target object can call the virtual function of the target object; thus, it is supported to collect all base classes of the target object first, so as to perform address replacement for each base class of virtual function table pointers used to call virtual functions of the target object. Specifically, all base classes of the target object are supported to be collected through std:: tr2:: bases class; the std:: tr2: bases class is a method supported by a compiler and used for automatically acquiring the base class of the type in the class hierarchy, and through the std:: tr2: bases class can automatically return to the base class list of the target object, wherein the base class list comprises one or more base classes of the target object.
Then, a base class pointer for each base class is obtained. The base class pointer of any base class is used to point to the target object and the portion of the virtual function inherited from the base class by the derived class object can be invoked by the base class pointer. In a specific implementation, an object pointer (i.e. a pointer pointing to a target object) can be converted through a dynamic_cast function, and the converted result is used as a base class pointer of a base class; wherein the dynamic_cast function is a function for realizing pointer type conversion.
Further, obtaining virtual function table pointers of each base class; in particular, the pointer address (may be referred to as a first pointer address in the embodiment of the present application) of the virtual function table pointer of each base class is obtained, where the first pointer address of the virtual function table pointer of any base class is used to indicate: the function address of the virtual function to be called by any base class is at the address space position in the process address space; i.e. the function address of the virtual function to be called by the virtual function table pointer in the virtual function table data, a storage location in the process address space. From the foregoing description, the derived classes may additionally add virtual functions that are not included in some base classes, in addition to inheriting virtual functions from the base classes; after the base class pointer is converted into the virtual function table pointer, the base class can call the member function specific to the target object through the virtual function table pointer. In a specific implementation, pointer type conversion can be performed on a base class pointer of each base class to obtain a first pointer address of a virtual function table pointer of each base class; considering that the first 8 bytes of the base class pointer store the virtual function table pointer address, then support to use the reinterpre_cast function to implement the forced conversion of the base class pointer into the virtual function table pointer to obtain the first pointer address of the virtual function table pointer; wherein, the reinterpres_cast function is a forced type converter, which can convert the base class pointer downwards to obtain the virtual function table pointer. Thus, the function address of the virtual function specific to the target object in the virtual function table data of the target object can be called through the first pointer address of the virtual function table pointer of the base class.
Finally, after the first pointer address of the virtual function table pointer of each base class is obtained based on the steps, determining and obtaining the function address of the virtual function to be called of each base class in the virtual function table data, and locating the address space in the process address space. Further, the first pointer address of the virtual function table pointer of each base class is subtracted from the initial address of the virtual function table data in the process address space, so that the address offset of the virtual function table pointer of each base class can be obtained, that is, the distance between the storage position of the function address of the virtual function called by each base class in the virtual function table data and the initial position of the virtual function table data is obtained.
S704: the target memory location pointed to in the specified region is determined for the virtual function table pointer of each base class based on the address offset of the virtual function table pointer of one or more base classes and the memory address of the virtual function table data in shared memory.
Based on the specific implementation process shown in the aforementioned step S703, after the address offset of the virtual function table pointer of each base class of the target object is obtained, the distance between the storage position of the function address of the virtual function to be called of each base class in the virtual function table data in the process address space and the start address of the virtual function table data is determined. Considering that after the virtual function table data is copied from the process address space to the designated area in the shared memory, the starting address of the virtual function table data changes (i.e., the starting address of the virtual function table data in the process address space is different from the starting address in the shared memory), but the internal structure of the virtual function table data does not change, i.e., the distance (i.e., the address offset) between the function addresses included in the virtual function table data is the same. And adding the address offset of the virtual function table pointer of each base class with the initial address of the virtual function table data in the shared memory after the virtual function table data is copied to the appointed area in the shared memory, thereby obtaining the storage address (namely the second pointer address) of the function address of the virtual function pointed by each virtual function table pointer in the shared memory.
In a specific implementation, the initial address of the copied virtual function table data in the shared memory can be acquired first. Then, the initial address of the virtual function table data in the shared memory is respectively added with the address offset of the virtual function table pointer of each base class of the target object to obtain a second pointer address of the virtual function table pointer of each base class; the second pointer address of the virtual function table pointer of any base class is used to indicate: the function address of the virtual function to be called by any base class is a target memory location (or referred to as a storage location) in the shared memory. And finally, replacing the first pointer address of the virtual function table pointer of the corresponding base class by adopting the second pointer address of the virtual function table pointer of each base class, namely replacing the address pointed by the virtual function table pointer of the base class in the process address space with the address pointed by the virtual function table pointer in the shared memory.
In summary, based on the steps S703 to S705, the address offset of the virtual function table pointer based on the base class and the starting address of the copied virtual function table data in the shared memory may be implemented, so as to obtain the second pointer address of the virtual function table pointer of the base class in the shared memory. The flow shown in the above steps S703 to S704 may be implemented by the following codes:
Base
base_ptr = dynamic_cast/>
(&instance)// obtain Address of object Base class (Base) pointer
long vptr =
reinterpret_cast/>
(base_ptr);// force rotationFor addresses pointed to by virtual function table pointers, i.e. first pointer addresses converted into virtual function table pointers
Long vptr_offset=vptr- (long) __ vtable_start __;// relative data. Rel. Ro segment offset, i.e., address offset of the virtual function table pointer
Long new_vptr= (Long) dest+vptr_offset;// dest shared memory segment address, the address relative to the shared memory segment is calculated, i.e. the second pointer address of the virtual function table pointer is calculated
long
cast_pointer = reinterpret_cast/>
(base_ptr);// numerical conversion
Further, to facilitate a better understanding of the implementation of the address replacement given above, an exemplary process for determining the address offset of the virtual function table pointer of the base class and determining the second pointer address of the virtual function table pointer described above is described below in conjunction with fig. 8. As shown in fig. 8, assume that when the target object is created, the start address of the virtual function table data in the process address space is 0x2344E; and, a first pointer address of the virtual function table pointer is 0x23456, indicating that the virtual function table pointer points to address 0x23456 in the process address space, the first pointer address 0x23456 stores function address 0x2234, indicating that the virtual function table pointer is used to call the virtual function at address 0x2234 in the process address space; the address offset of the virtual function table pointer in the process address space is determined as: the first pointer address of the virtual function table pointer, 0x23456, subtracts the start address of the virtual function table data in the process address space, 0x2344E, and takes the subtraction result, 8, as the address offset. Further, after copying the virtual function table data in the process address space to the designated area in the shared memory, in order to make the virtual function table pointer point to the virtual function in the virtual function table data copied in the shared memory, the address offset of the virtual function table pointer and the starting address of the virtual function table data in the shared memory need to be added to obtain the pointer address (i.e. the second pointer address) of the virtual function table pointer in the shared memory. For example, assuming that the starting address of the virtual function table data in the shared memory is 0x456843D, given that the address offset of the virtual function table pointer is 8, the second pointer address of the virtual function table pointer in the shared memory may be determined to be: the virtual function table data adds the address offset 8 of the virtual function table pointer to the starting address 0x456843D in the shared memory and takes the addition result 0x4568445 as the second pointer address of the virtual function table pointer. Finally, replacing the first pointer address of the virtual function table pointer by adopting the second pointer address of the virtual function table pointer so as to finish the address replacement of the virtual function table pointer; the replaced virtual function table pointer points to the memory location of the second pointer address in the shared memory, and represents the virtual function corresponding to the function address at the memory location of the second pointer address to be called.
S705: after the communication connection is reestablished between the target process and the shared memory, determining a designated area in the shared memory.
S706: and acquiring virtual function table data corresponding to the target process from a process address space of the target process.
S707: and copying the acquired virtual function table data to a designated area in the shared memory.
It should be noted that, the specific implementation process shown in steps S705 to S707 may be referred to the description of the specific implementation process shown in steps S401 to S403 in the embodiment shown in fig. 4, which is not repeated herein.
In this embodiment, a specified area is defined in the shared memory to cache virtual function table data, and each virtual function table pointer that needs to call the virtual function table data is bound at one time, that is, each virtual function table pointer is preset to point to the specified area in the shared memory, specifically to the memory location where the function address of the virtual function to be called in the specified area is located. In this way, after the target process is restarted (i.e. the communication connection is reestablished between the target process and the shared memory) at any time, only the updated virtual function table data in the process address space is required to be copied to the designated area, namely, new virtual function table data is adopted to cover the virtual function table data before the restart of the target process in the shared memory; the target process can call the function address of the virtual function required by the target process operation from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, so that the one-time restoration of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports dividing the appointed area in the shared memory to cache the virtual function table data, so that after the non-POD type data containing the virtual function table pointer is stored in the shared memory, the virtual function table pointer can directly read the correct function address of the virtual function to be called from the shared memory, and the validity of the virtual function table pointer is always maintained. In addition, the developer is not limited by the selection of the data type any more, and any custom object data can be stored in the shared memory.
The foregoing details of the memory processing method according to the embodiments of the present application are set forth in the foregoing description, and in order to better implement the foregoing aspects of the embodiments of the present application, correspondingly, the following provides an apparatus according to the embodiments of the present application.
FIG. 9 is a schematic diagram of a memory processing device according to an exemplary embodiment of the present application; the memory processing apparatus may be a computer program (including program code) running in a computer device; the memory processing device may be used to perform some or all of the steps of the method embodiments shown in fig. 4 or fig. 7. Referring to fig. 9, the memory processing device includes the following units:
the processing unit 901 is configured to determine an appointed area in the shared memory after reestablishing communication connection between the target process and the shared memory, where the appointed area is used to store virtual function table data corresponding to the target process; the shared memory stores non-POD type data, the non-POD type data comprises virtual function table pointers corresponding to the target process, and the virtual function table pointers are preset to point to the designated area;
an obtaining unit 902, configured to obtain virtual function table data corresponding to a target process from a process address space of the target process;
the processing unit 901 is further configured to copy the obtained virtual function table data to a designated area in the shared memory, so that the target process calls, through the virtual function table pointer, a virtual function required by the target process to operate from the virtual function table data stored in the designated area.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object, where the function addresses of the virtual functions are used to indicate: address space location of the virtual function in the process address space;
the virtual function table pointer is preset to point to a target memory location in the designated area, the target memory location being: and the function address of the virtual function to be called by the virtual function pointer in the virtual function table data is stored in a designated area.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; the processing unit 901 is further configured to:
obtaining an objective function address of each virtual function in one or more virtual functions, wherein the objective function address of the virtual function is used for indicating: after the communication connection is rebuilt between the target process and the shared memory, the address space position of the virtual function updated in the process address space of the target process;
updating the corresponding reference function address in the virtual function table data by adopting the target function address of each virtual function to obtain updated virtual function table data; the reference function address of the dummy function is used to indicate: before the communication connection is reestablished between the target process and the shared memory, the virtual function is located in an address space of the process address space of the target process.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; the processing unit 901 is further configured to:
after a target object of a target process is created in a shared memory, virtual function table data corresponding to the target process is obtained from a process address space of the target process;
copying the obtained virtual function table data to a designated area in the shared memory;
obtaining address offset of virtual function table pointers of one or more base classes of the target object; the address offset of the virtual function table pointer of the base class is used to indicate: an offset between an address space location pointed by the virtual function table pointer of the base class in the process address space and a starting address space location of the virtual function table data in the process address space;
the target memory location pointed to in the specified region is determined for the virtual function table pointer of each base class based on the address offset of the virtual function table pointer of one or more base classes and the memory address of the virtual function table data in shared memory.
In one implementation, the processing unit 901 is configured to, when obtaining address offsets of virtual function table pointers of one or more base classes of a target object, specifically:
Obtaining virtual function table pointers of each base class; the first pointer address of the virtual function table pointer of the base class is used to indicate: the function address of the virtual function to be called by the base class is at the address space position in the process address space;
and subtracting the first pointer address of the virtual function table pointer of each base class from the initial address of the virtual function table data in the process address space to obtain the address offset of the virtual function table pointer of each base class.
In one implementation, the processing unit 901 is configured to, when obtaining the virtual function table pointer of each base class, specifically:
acquiring a base class pointer of each base class, wherein the base class pointer of the base class is used for pointing to a target object;
and performing pointer type conversion on the base class pointers of each base class to obtain virtual function table pointers of each base class.
In one implementation, the processing unit 901 is configured to determine, for each base class of virtual function table pointers, a target memory location pointed to in a specified area based on an address offset of the virtual function table pointers of one or more base classes and a memory address of the virtual function table data in the shared memory, where the target memory location is specifically configured to:
acquiring the initial address of the copied virtual function table data in the shared memory;
The initial address of the virtual function table data in the shared memory is respectively added with the address offset of the virtual function table pointer of each base class to obtain a second pointer address of the virtual function table pointer of each base class; the second pointer address of the virtual function table pointer of the base class is used to indicate: the function address of the virtual function to be called by the base class is at the target memory position in the shared memory;
and replacing the first pointer address of the virtual function table pointer of the corresponding base class by adopting the second pointer address of the virtual function table pointer of each base class.
In one implementation, a processing unit 901 is configured to obtain virtual function table data corresponding to a target process from a process address space of the target process; when the obtained virtual function table data is copied to the appointed area in the shared memory, the method is specifically used for:
acquiring a starting address and an ending address of virtual function table data in a process address space of a target process;
copying data between a start address and an end address in a process address space to a designated area in a shared memory; in the process address space, the data between the starting address and the ending address are virtual function table data.
In one implementation, virtual function table data of the target object is stored in a read-only reentrant section in a process address space, and an address of the read-only reentrant section in the process address space is determined by a program loader; when the read-only reentrant segment only includes the virtual function table data of the target object, the processing unit 901 is configured to obtain a start address and an end address of the virtual function table data in the process address space, specifically configured to:
acquiring a first address variable and a second address variable, wherein the first address variable is used for acquiring a start address of a read-only reentrant section, and the second address variable is used for acquiring an end address of the read-only reentrant section;
generating a target link script based on the first address variable and the second address variable, and attaching the target link script to a default script to obtain an attached default script;
and loading the attached default script by adopting a program loader, and outputting the start address and the end address of the read-only reentrant segment.
In one implementation, virtual function table data of a target object is stored in a read-only reentrant section in a process address space of a target process; when the read-only reentrant segment contains one or more virtual function table data of different objects and the one or more virtual function table data contains virtual function table data of the target object, the processing unit 901 is configured to obtain virtual function table data corresponding to the target process from a process address space of the target process; when the obtained virtual function table data is copied to the appointed area in the shared memory, the method is specifically used for:
Acquiring one or more virtual function table data in a read-only reentrant section from a process address space of a target process;
and copying the acquired one or more virtual function table data to a designated area in the shared memory.
According to an embodiment of the present application, each unit in the memory processing apparatus shown in fig. 9 may be separately or completely combined into one or several other units to form a structure, or some unit(s) thereof may be further split into a plurality of units with smaller functions to form a structure, which may achieve the same operation without affecting the implementation of the technical effects of the embodiments of the present application. The above units are divided based on logic functions, and in practical applications, the functions of one unit may be implemented by a plurality of units, or the functions of a plurality of units may be implemented by one unit. In other embodiments of the present application, the memory processing device may also include other units, and in practical applications, these functions may also be implemented with assistance from other units, and may be implemented by cooperation of multiple units. According to another embodiment of the present application, a memory processing apparatus as shown in fig. 9 may be constructed by running a computer program (including program code) capable of executing the steps involved in the respective methods as shown in fig. 4 or fig. 7 on a general-purpose computing device such as a computer including a processing element such as a Central Processing Unit (CPU), a random access storage medium (RAM), a read only storage medium (ROM), and the like, and a storage element, and the memory processing method of the embodiment of the present application is implemented. The computer program may be recorded on, for example, a computer-readable recording medium, and loaded into and run in the above-described computing device through the computer-readable recording medium.
In this embodiment, a specified area is defined in the shared memory to cache virtual function table data, and each virtual function table pointer that needs to call the virtual function table data is bound at one time, that is, each virtual function table pointer is preset to point to the specified area in the shared memory, specifically to the memory location where the function address of the virtual function to be called in the specified area is located. In this way, after the target process is restarted (i.e. the communication connection is reestablished between the target process and the shared memory) at any time, only the updated virtual function table data in the process address space is required to be copied into the designated area, namely, the new virtual function table data is adopted to cover the virtual function table data before the restart of the target process; the target process can call the function address of the virtual function required by the target process operation from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, so that the one-time restoration of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports dividing the appointed area in the shared memory to cache the virtual function table data, so that after the non-POD type data containing the virtual function table pointer is stored in the shared memory, the virtual function table pointer can directly read the correct function address of the virtual function to be called from the shared memory, and the validity of the virtual function table pointer is always maintained. In addition, the developer is not limited by the selection of the data type any more, and any custom object data can be stored in the shared memory.
Fig. 10 shows a schematic structural diagram of a computer device according to an exemplary embodiment of the present application. Referring to fig. 10, the computer device includes a processor 1001, a communication interface 1002, and a computer readable storage medium 1003. Wherein the processor 1001, the communication interface 1002, and the computer-readable storage medium 1003 may be connected by a bus or other means. Wherein the communication interface 1002 is for receiving and transmitting data. The computer readable storage medium 1003 may be stored in a memory of a computer device, the computer readable storage medium 1003 storing a computer program comprising program instructions, the processor 1001 being configured to execute the program instructions stored by the computer readable storage medium 1003. The processor 1001, or CPU (Central Processing Unit ), is a computing core and a control core of a computer device, which is adapted to implement one or more instructions, in particular to load and execute one or more instructions to implement a corresponding method flow or a corresponding function.
The embodiments of the present application also provide a computer-readable storage medium (Memory), which is a Memory device in a computer device, for storing programs and data. It is understood that the computer readable storage medium herein may include both built-in storage media in a computer device and extended storage media supported by the computer device. The computer readable storage medium provides storage space that stores a processing system of a computer device. Also stored in this memory space are one or more instructions, which may be one or more computer programs (including program code), adapted to be loaded and executed by the processor 1001. Note that the computer readable storage medium can be either a high-speed RAM memory or a non-volatile memory (non-volatile memory), such as at least one magnetic disk memory; alternatively, it may be at least one computer-readable storage medium located remotely from the aforementioned processor.
In one embodiment, the computer device may be a device including a memory as mentioned in the previous embodiment; the computer-readable storage medium having one or more instructions stored therein; the processor 1001 loads and executes one or more instructions stored in the computer-readable storage medium to implement the corresponding steps in the memory processing method embodiment described above; in particular implementations, one or more instructions in a computer-readable storage medium are loaded by the processor 1001 and perform the steps of:
after reestablishing communication connection between the target process and the shared memory, determining a designated area in the shared memory, wherein the designated area is used for storing virtual function table data corresponding to the target process; the shared memory stores non-POD type data, the non-POD type data comprises virtual function table pointers corresponding to the target process, and the virtual function table pointers are preset to point to the designated area;
obtaining virtual function table data corresponding to a target process from a process address space of the target process;
and copying the acquired virtual function table data to a designated area in the shared memory, so that the target process calls the virtual function required by the target process from the virtual function table data stored in the designated area through the virtual function table pointer.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object, where the function addresses of the virtual functions are used to indicate: address space location of the virtual function in the process address space;
the virtual function table pointer is preset to point to a target memory location in the designated area, the target memory location being: and the function address of the virtual function to be called by the virtual function pointer in the virtual function table data is stored in a designated area.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and further perform the steps of:
obtaining an objective function address of each virtual function in one or more virtual functions, wherein the objective function address of the virtual function is used for indicating: after the communication connection is rebuilt between the target process and the shared memory, the address space position of the virtual function updated in the process address space of the target process;
updating the corresponding reference function address in the virtual function table data by adopting the target function address of each virtual function to obtain updated virtual function table data; the reference function address of the dummy function is used to indicate: before the communication connection is reestablished between the target process and the shared memory, the virtual function is located in an address space of the process address space of the target process.
In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and further perform the steps of:
after a target object of a target process is created in a shared memory, virtual function table data corresponding to the target process is obtained from a process address space of the target process;
copying the obtained virtual function table data to a designated area in the shared memory;
obtaining address offset of virtual function table pointers of one or more base classes of the target object; the address offset of the virtual function table pointer of the base class is used to indicate: an offset between an address space location pointed by the virtual function table pointer of the base class in the process address space and a starting address space location of the virtual function table data in the process address space;
the target memory location pointed to in the specified region is determined for the virtual function table pointer of each base class based on the address offset of the virtual function table pointer of one or more base classes and the memory address of the virtual function table data in shared memory.
In one implementation, one or more instructions in a computer-readable storage medium are loaded by the processor 1001 and, when executing the address offset of the virtual function table pointer of the one or more base classes of the acquisition target object, perform the steps of:
Obtaining virtual function table pointers of each base class; the first pointer address of the virtual function table pointer of the base class is used to indicate: the function address of the virtual function to be called by the base class is at the address space position in the process address space;
and subtracting the first pointer address of the virtual function table pointer of each base class from the initial address of the virtual function table data in the process address space to obtain the address offset of the virtual function table pointer of each base class.
In one implementation, one or more instructions in a computer-readable storage medium are loaded by the processor 1001 and, when executed, perform the steps of:
acquiring a base class pointer of each base class, wherein the base class pointer of the base class is used for pointing to a target object;
and performing pointer type conversion on the base class pointers of each base class to obtain virtual function table pointers of each base class.
In one implementation, one or more instructions in a computer-readable storage medium are loaded by the processor 1001 and when executing virtual function table pointers based on one or more base classes, address offsets, and memory addresses of virtual function table data in shared memory, determine for each base class's virtual function table pointer a target memory location pointed to in a specified region, specifically perform the steps of:
Acquiring the initial address of the copied virtual function table data in the shared memory;
the initial address of the virtual function table data in the shared memory is respectively added with the address offset of the virtual function table pointer of each base class to obtain a second pointer address of the virtual function table pointer of each base class; the second pointer address of the virtual function table pointer of the base class is used to indicate: the function address of the virtual function to be called by the base class is at the target memory position in the shared memory;
and replacing the first pointer address of the virtual function table pointer of the corresponding base class by adopting the second pointer address of the virtual function table pointer of each base class.
In one implementation, one or more instructions in a computer-readable storage medium are loaded by the processor 1001 and are executed to obtain virtual function table data corresponding to a target process from a process address space of the target process; when the obtained virtual function table data is copied to a designated area in the shared memory, the following steps are specifically executed:
acquiring a starting address and an ending address of virtual function table data in a process address space of a target process;
copying data between a start address and an end address in a process address space to a designated area in a shared memory; in the process address space, the data between the starting address and the ending address are virtual function table data.
In one implementation, virtual function table data of the target object is stored in a read-only reentrant section in a process address space, and an address of the read-only reentrant section in the process address space is determined by a program loader; when only virtual function table data of the target object is included in the read-only reentrant section, one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and when executing the acquisition of the start address and the end address of the virtual function table data in the process address space, specifically perform the following steps:
acquiring a first address variable and a second address variable, wherein the first address variable is used for acquiring a start address of a read-only reentrant section, and the second address variable is used for acquiring an end address of the read-only reentrant section;
generating a target link script based on the first address variable and the second address variable, and attaching the target link script to a default script to obtain an attached default script;
and loading the attached default script by adopting a program loader, and outputting the start address and the end address of the read-only reentrant segment.
In one implementation, virtual function table data of a target object is stored in a read-only reentrant section in a process address space of a target process; when the read-only reentrant section contains one or more virtual function table data of different objects and the one or more virtual function table data contains virtual function table data of a target object, one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and acquire virtual function table data corresponding to the target process from a process address space of the target process when executing the execution; when the obtained virtual function table data is copied to a designated area in the shared memory, the following steps are specifically executed:
Acquiring one or more virtual function table data in a read-only reentrant section from a process address space of a target process;
and copying the acquired one or more virtual function table data to a designated area in the shared memory.
In this embodiment, a specified area is defined in the shared memory to cache virtual function table data, and each virtual function table pointer that needs to call the virtual function table data is bound at one time, that is, each virtual function table pointer is preset to point to the specified area in the shared memory, specifically to the memory location where the function address of the virtual function to be called in the specified area is located. In this way, after the target process is restarted (i.e. the communication connection is reestablished between the target process and the shared memory) at any time, only the updated virtual function table data in the process address space is required to be copied into the designated area, namely, the new virtual function table data is adopted to cover the virtual function table data before the restart of the target process; the target process can call the function address of the virtual function required by the target process operation from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, so that the one-time restoration of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports dividing the appointed area in the shared memory to cache the virtual function table data, so that after the non-POD type data containing the virtual function table pointer is stored in the shared memory, the virtual function table pointer can directly read the correct function address of the virtual function to be called from the shared memory, and the validity of the virtual function table pointer is always maintained. In addition, the developer is not limited by the selection of the data type any more, and any custom object data can be stored in the shared memory.
Embodiments of the present application also provide a computer readable storage medium storing a computer program adapted to be loaded by a processor and to perform a memory processing method as described above.
Those of ordinary skill in the art will appreciate that the various illustrative elements and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, or combinations of computer software and electronic hardware. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the solution. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present application.
In the above embodiments, it may be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented in software, may be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions in accordance with embodiments of the present application are produced in whole or in part. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable devices. The computer instructions may be stored in or transmitted across a computer-readable storage medium. The computer instructions may be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by a wired (e.g., coaxial cable, fiber optic, digital subscriber line (Digital Subscriber Line, DSL)) or wireless (e.g., infrared, wireless, microwave, etc.). Computer readable storage media can be any available media that can be accessed by a computer or data storage devices, such as servers, data centers, etc., that contain an integration of one or more available media. The usable medium may be a magnetic medium (e.g., a floppy Disk, a hard Disk, a magnetic tape), an optical medium, or a semiconductor medium (e.g., a Solid State Disk (SSD)), or the like.
The foregoing is merely a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think about changes or substitutions within the technical scope of the present application, and the changes and substitutions should be covered in the protection scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.
Claims (12)
1. A memory processing method, comprising:
after reestablishing communication connection between a target process and a shared memory, determining a designated area in the shared memory, wherein the designated area is used for storing virtual function table data corresponding to the target process; the shared memory stores non-POD type data, wherein the non-POD type data comprises virtual function table pointers corresponding to the target process, and the virtual function table pointers are preset to point to the appointed area; wherein the virtual function table pointer being preset to point to the specified region comprises: after a target object of the target process is created in the shared memory, replacing a first pointer address of a virtual function table pointer pointing to virtual function table data in a process address space of the target process with a second pointer address pointing to virtual function table data stored in the designated area in the shared memory; the virtual function table data is stored in a read-only reentrant section of a process address space of the target process, and the read-only reentrant section contains one or more virtual function table data of different objects;
Acquiring the one or more virtual function table data in the read-only reentrant section from a process address space of the target process;
copying the obtained one or more virtual function table data to a designated area in the shared memory, so that the target process calls a virtual function required by the operation of the target process from the virtual function table data stored in the designated area through the virtual function table pointer.
2. The method of claim 1, wherein the virtual function table data includes function addresses of one or more virtual functions of the target object, the function addresses of the virtual functions being used to indicate: address space locations of the virtual functions in the process address space;
the virtual function table pointer is preset to point to a target memory location in the specified area, where the target memory location refers to: and the function address of the virtual function to be called by the virtual function table pointer in the virtual function table data is stored in the designated area.
3. The method of claim 1, wherein the virtual function table data includes function addresses of one or more virtual functions of a target object; before the obtaining the one or more virtual function table data in the read-only reentrant section from the process address space of the target process, the method further includes:
Obtaining an objective function address of each virtual function in the one or more virtual functions, wherein the objective function address of the virtual function is used for indicating: after the communication connection is rebuilt between the target process and the shared memory, the virtual function is at the address space position updated in the process address space of the target process;
updating the corresponding reference function address in the virtual function table data by adopting the target function address of each virtual function to obtain updated virtual function table data; the reference function address of the virtual function is used for indicating: before the communication connection is reestablished between the target process and the shared memory, the virtual function is located in an address space in a process address space of the target process.
4. The method of claim 1, wherein the virtual function table data includes function addresses of one or more virtual functions of a target object; the method further comprises the steps of:
after a target object of a target process is created in a shared memory, virtual function table data corresponding to the target process is obtained from a process address space of the target process;
copying the obtained virtual function table data to a designated area in the shared memory;
Acquiring address offset of virtual function table pointers of one or more base classes of the target object; the address offset of the virtual function table pointer of the base class is used to indicate: an offset between an address space location pointed by a virtual function table pointer of the base class in the process address space and a starting address space location of the virtual function table data in the process address space;
and determining a target memory location pointed to in the designated area for the virtual function table pointer of each base class based on the address offset of the virtual function table pointer of the one or more base classes and the memory address of the virtual function table data in the shared memory.
5. The method of claim 4, wherein the obtaining the address offset of the virtual function table pointer of the one or more base classes of the target object comprises:
obtaining virtual function table pointers of each base class; the first pointer address of the virtual function table pointer of the base class is used to indicate: the function address of the virtual function to be called by the base class is at the address space position in the process address space;
and subtracting the first pointer address of the virtual function table pointer of each base class from the initial address of the virtual function table data in the process address space to obtain the address offset of the virtual function table pointer of each base class.
6. The method of claim 5, wherein the obtaining the virtual function table pointer for each base class comprises:
acquiring a base class pointer of each base class, wherein the base class pointer of each base class is used for pointing to the target object;
and performing pointer type conversion on the base class pointers of each base class to obtain virtual function table pointers of each base class.
7. The method of claim 5, wherein the determining the target memory location pointed to in the designated area for the virtual function table pointer for each base class based on the address offset of the virtual function table pointer for the one or more base classes and the memory address of the virtual function table data in the shared memory, comprises:
acquiring the initial address of the copied virtual function table data in the shared memory;
the initial address of the virtual function table data in the shared memory is respectively added with the address offset of the virtual function table pointer of each base class to obtain a second pointer address of the virtual function table pointer of each base class; the second pointer address of the virtual function table pointer of the base class is used for indicating: the function address of the virtual function to be called by the base class is at a target memory location in the shared memory;
And replacing the first pointer address of the virtual function table pointer of the corresponding base class by adopting the second pointer address of the virtual function table pointer of each base class.
8. The method of claim 1 or 4, wherein the obtaining the one or more virtual function table data in the read-only reentrant section from a process address space of the target process; copying the acquired one or more virtual function table data to a designated area in the shared memory, including:
acquiring a starting address and an ending address of the virtual function table data in a process address space of the target process;
copying data between the starting address and the ending address in the process address space to a designated area in the shared memory; wherein, in the process address space, the data between the start address and the end address is the one or more virtual function table data.
9. The method of claim 8, wherein virtual function table data of a target object is stored in a read-only reentrant section in the process address space, an address of the read-only reentrant section in the process address space being determined by a program loader; when the read-only reentrant segment only contains the virtual function table data of the target object, the obtaining the starting address and the ending address of the virtual function table data in the process address space of the target process includes:
Acquiring a first address variable and a second address variable, wherein the first address variable is used for acquiring a start address of the read-only reentrant section, and the second address variable is used for acquiring an end address of the read-only reentrant section;
generating a target link script based on the first address variable and the second address variable, and attaching the target link script to a default script to obtain an attached default script;
and loading the attached default script by adopting the program loader, and outputting the starting address and the ending address of the read-only reentrant section.
10. A memory processing apparatus, comprising:
the processing unit is used for determining a designated area in the shared memory after the communication connection is rebuilt between the target process and the shared memory, wherein the designated area is used for storing virtual function table data corresponding to the target process; the shared memory stores non-POD type data, wherein the non-POD type data comprises virtual function table pointers corresponding to the target process, and the virtual function table pointers are preset to point to the appointed area; wherein the virtual function table pointer being preset to point to the specified region comprises: after a target object of the target process is created in the shared memory, replacing a first pointer address of a virtual function table pointer pointing to virtual function table data in a process address space of the target process with a second pointer address pointing to virtual function table data stored in the designated area in the shared memory; the virtual function table data is stored in a read-only reentrant section of a process address space of the target process, and the read-only reentrant section contains one or more virtual function table data of different objects;
An obtaining unit, configured to obtain the one or more virtual function table data in the read-only reentrant section from a process address space of the target process;
and the processing unit is further used for copying the acquired one or more virtual function table data to a designated area in the shared memory, so that the target process calls a virtual function required by the operation of the target process from the virtual function table data stored in the designated area through the virtual function table pointer.
11. A computer device, comprising:
a processor adapted to execute a computer program;
a computer readable storage medium having a computer program stored therein, which when executed by the processor, implements the memory processing method according to any of claims 1-9.
12. A computer readable storage medium, characterized in that the computer readable storage medium stores a computer program adapted to be loaded by a processor and to perform the memory processing method according to any of claims 1-9.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310221060.5A CN115952017B (en) | 2023-03-09 | 2023-03-09 | Memory processing method, device, equipment and medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202310221060.5A CN115952017B (en) | 2023-03-09 | 2023-03-09 | Memory processing method, device, equipment and medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN115952017A CN115952017A (en) | 2023-04-11 |
| CN115952017B true CN115952017B (en) | 2023-05-23 |
Family
ID=85903241
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202310221060.5A Active CN115952017B (en) | 2023-03-09 | 2023-03-09 | Memory processing method, device, equipment and medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN115952017B (en) |
Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105808251A (en) * | 2016-03-03 | 2016-07-27 | 武汉斗鱼网络科技有限公司 | Virtual function table based method and system for bypassing security detection by hijack |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6915392B2 (en) * | 2002-07-12 | 2005-07-05 | Intel Corporation | Optimizing memory usage by vtable cloning |
| CN108446149B (en) * | 2018-02-28 | 2021-07-20 | 北京凌宇智控科技有限公司 | Third-party dynamic library interface interception method and system |
| EP3861469B1 (en) * | 2018-10-23 | 2023-05-31 | Huawei Technologies Co., Ltd. | Device and method for validation of virtual function pointers |
| CN112559094B (en) * | 2020-12-15 | 2024-04-02 | 浙江中控技术股份有限公司 | Calling method and device of C++ module interface |
| CN113590091A (en) * | 2021-06-30 | 2021-11-02 | 五八有限公司 | Data processing method and device, electronic equipment and storage medium |
-
2023
- 2023-03-09 CN CN202310221060.5A patent/CN115952017B/en active Active
Patent Citations (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN105808251A (en) * | 2016-03-03 | 2016-07-27 | 武汉斗鱼网络科技有限公司 | Virtual function table based method and system for bypassing security detection by hijack |
Also Published As
| Publication number | Publication date |
|---|---|
| CN115952017A (en) | 2023-04-11 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7882198B2 (en) | Shared JAVA JAR files | |
| US8453015B2 (en) | Memory allocation for crash dump | |
| US7203941B2 (en) | Associating a native resource with an application | |
| US20030093401A1 (en) | Method and apparatus for using a shared library mechanism to facilitate sharing of metadata | |
| US9507613B2 (en) | Methods and apparatus for dynamically preloading classes | |
| CN110162306B (en) | Advanced compiling method and device of system | |
| CN108628765B (en) | Method and device for realizing Cache in open-source distributed storage software Ceph | |
| CN108228077B (en) | Storage area management method, operation method, device, equipment and readable medium | |
| KR20090029798A (en) | Heap organization for a multitasking virtual machine | |
| EP2504759A1 (en) | Method and system for enabling access to functionality provided by resources outside of an operating system environment | |
| US20060101410A1 (en) | Abstracted managed code execution | |
| CN110781016A (en) | Data processing method, device, equipment and medium | |
| CN115952017B (en) | Memory processing method, device, equipment and medium | |
| EP1444572B1 (en) | Method and apparatus for facilitating compact object headers | |
| WO2017142525A1 (en) | Allocating a zone of a shared memory region | |
| CN116680233A (en) | File access method, system, electronic equipment and machine-readable storage medium | |
| CN115712500A (en) | Memory release method, memory recovery method, memory release device, memory recovery device, computer equipment and storage medium | |
| CN115756838A (en) | Memory release method, memory recovery method, memory release device, memory recovery device, computer equipment and storage medium | |
| KR101140522B1 (en) | System and Method for Managing Object | |
| WO2008083187A2 (en) | Dynamically updateable and moveable memory zones | |
| CN115168837B (en) | Software operation control method, microprocessor, computer device and storage medium | |
| CN116700841B (en) | Method and device for calling native API (application program interface) | |
| US11513970B2 (en) | Split virtual memory address loading mechanism | |
| CN109324809B (en) | Data processing method and device | |
| US11340915B2 (en) | Encaching and sharing transformed libraries |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |