CN115952017A

CN115952017A - Memory processing method, device, equipment and medium

Info

Publication number: CN115952017A
Application number: CN202310221060.5A
Authority: CN
Inventors: 钱海江
Original assignee: Tencent Technology Shenzhen Co Ltd
Current assignee: Tencent Technology Shenzhen Co Ltd
Priority date: 2023-03-09
Filing date: 2023-03-09
Publication date: 2023-04-11
Anticipated expiration: 2043-03-09
Also published as: CN115952017B

Abstract

The embodiment of the application provides a memory processing method, a memory processing device, memory processing equipment and a memory processing medium, wherein the method comprises the following steps: after communication connection is reestablished between the target process and the shared memory, determining a designated area in the shared memory; acquiring 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 a shared memory, and calling a virtual function required by the running of the target process from the virtual function table data stored in the designated area by the target process through a virtual function table pointer. By adopting the embodiment of the application, 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

Memory processing method, device, equipment and medium

Technical Field

The present application 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, allows multiple processes to access the same memory space, and is an effective way for sharing and transferring data among multiple processes.

Practice shows that when Data management of a shared memory is realized, a virtual function table pointer contained in non-POD (Plain Old Data) type Data is invalid when a process is restarted; this results in non-POD type data not being stored in the shared memory, not only limiting the types of data stored in the shared memory, but also greatly limiting the development capabilities of developers.

Disclosure of Invention

Embodiments of the present application provide a memory processing method, apparatus, device, and medium, which can ensure validity of a virtual function table pointer when storing non-POD type data including the virtual function table pointer in a shared memory.

In one aspect, an embodiment of the present application provides a memory processing method, where the method includes:

after communication connection is reestablished 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; non-POD type data are stored in the shared memory, the non-POD type data comprise virtual function table pointers corresponding to a target process, and the virtual function table pointers are preset to point to a designated area;

acquiring 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 a shared memory, and calling a virtual function required by the running of the target process from the virtual function table data stored in the designated area by the target process through a virtual function table pointer.

In another aspect, an embodiment of the present application provides a memory processing apparatus, where the apparatus includes:

the processing unit is used for determining a designated area in the shared memory after communication connection is reestablished between the target process and the shared memory, and the designated area is used for storing virtual function table data corresponding to the target process; non-POD type data are stored in the shared memory, and a virtual function table pointer corresponding to a target process is contained in the non-POD type data and is preset to point to a designated area;

the acquiring unit is used for acquiring virtual function table data corresponding to the target process from the process address space of the target process;

and the processing unit is further used for copying the acquired virtual function table data to a designated area in the shared memory, so that the target process calls a virtual function required by the running of 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, and 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.

In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; a processing unit further configured to:

acquiring a target function address of each virtual function in one or more virtual functions, wherein the target function address of the virtual function is used for indicating: after communication connection is reestablished between the target process and the shared memory, the virtual function is in the updated address space position in the process address space of the target process;

updating corresponding reference function addresses in the virtual function table data by adopting the target function addresses of all the virtual functions to obtain updated virtual function table data; the reference function address of the dummy function is used to indicate: and before the communication connection is reestablished between the target process and the shared memory, the virtual function is located in the 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; a processing unit further to:

after a target object of a target process is created in a shared memory, virtual function table data corresponding to the target process are obtained from a process address space of the target process;

copying the acquired virtual function table data to a designated area in a 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 base class's virtual function table pointer is used to indicate: the offset between the address space position pointed by the virtual function table pointer of the base class in the process address space and the initial address space position of the virtual function table data in the process address space;

and determining the target memory position pointed by the virtual function table pointer 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 one or more base classes and the memory address of the virtual function table data in the shared memory.

In an implementation manner, the processing unit, when acquiring address offsets of virtual function table pointers of one or more base classes of the target object, is specifically configured to:

acquiring a virtual function table pointer 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 of the base class is the address space position in the process address space;

and carrying out subtraction operation on the first pointer address of the virtual function table pointer of each base class and 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 an implementation manner, the processing unit, when being configured to obtain the virtual function table pointer of each base class, is specifically configured to:

acquiring a base class pointer of each base class, wherein the base class pointer of each base class is used for pointing to a target object;

and performing pointer type conversion on the base class pointer of each base class to obtain the virtual function table pointer of each base class.

In one implementation, the processing unit, configured to determine, for each base class vm pointer, a target memory location pointed in the designated area based on address offsets of the vm pointer of one or more base classes and a memory address of vm data in the shared memory, is specifically configured to:

acquiring an initial address of the copied virtual function table data in the shared memory;

adding the initial address of the virtual function table data in the shared memory and the address offset of the virtual function table pointer of each base class respectively 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 of the base class is in 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 using the second pointer address of the virtual function table pointer of each base class.

In one implementation, the 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 acquired virtual function table data is copied to a specified area in the shared memory, the method is specifically configured to:

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 starting address and an ending address in a process address space to a designated area in a shared memory; in the process address space, data between the start address and the end address is virtual function table data.

In one implementation, virtual function table data of a target object is stored in a read-only reentrant section in a process address space, and the 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 virtual function table data of the target object, the processing unit is specifically configured to, when acquiring a start address and an end address of the virtual function table data in the process address space:

acquiring a first address variable and a second address variable, wherein the first address variable is used for acquiring a starting address of the read-only reentrant section, and the second address variable is used for acquiring an ending address of the read-only reentrant section;

generating a target link script based on the first address variable and the second address variable, and adding the target link script to the default script to obtain an added default script;

and loading the attached default script by adopting a program loader, and outputting the starting address and the ending address of the read-only reentrant section.

In one implementation, virtual function table data of a target object is stored in a read-only reentrant segment 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 contain virtual function table data of a target object, the processing unit is used for acquiring virtual function table data corresponding to a target process from a process address space of the target process; when copying the acquired virtual function table data to a designated area in the shared memory, the method is specifically configured to:

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 data of the one or more virtual function tables to a specified area in the shared memory.

In the embodiment of the application, a designated area is defined in the shared memory to cache the data of the virtual function table, and each virtual function table pointer needing to call the data of the virtual function table is bound at one time, that is, each virtual function table pointer is preset to point to the designated area in the shared memory, specifically to point to the memory location where the function address of the virtual function to be called in the designated area is located. In this way, after any target process is restarted (it can be understood that communication connection is reestablished between the target process and the shared memory, or the target process remaps the shared memory 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 needs to be copied into the designated area, that is, the new virtual function table data is adopted to cover the virtual function table data before the target process is restarted in the shared memory; the target process can call the function address of the virtual function required by the target process to run from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, and the one-time repair of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports the division of the designated area in the shared memory to cache the data of the virtual function table, so that after the non-POD type data containing the pointer of the virtual function table is stored in the shared memory, the pointer of the virtual function table can be directly read from the shared memory to the correct function address of the virtual function to be called, and the validity of the pointer of the virtual function table is always kept. In addition, for the developer, the data type selection is no longer limited, and any customized 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 used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

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 illustrating a mapping between physical memory and virtual memory according to an exemplary embodiment of the present application;

FIG. 3a is a schematic diagram of a memory processing scheme provided by an exemplary embodiment of the present application;

FIG. 3b is a schematic diagram of another memory processing scheme provided by an exemplary embodiment of the present application;

fig. 4 is a schematic flowchart of a memory processing method according to an exemplary embodiment of the present application;

fig. 5 is a schematic flowchart illustrating a process of copying data of a virtual function table 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 illustrating updating of a function address in virtual function table data after a communication connection is reestablished between a target process and a shared memory according to an exemplary embodiment of the present application;

fig. 7 is a schematic flow chart diagram illustrating another memory processing method according to an exemplary embodiment of the present application;

FIG. 8 is a block diagram illustrating a determination of a second pointer address for a virtual function table pointer in accordance with an illustrative embodiment of the present application;

fig. 9 is a schematic structural 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 technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the drawings in the embodiments of the present application, and it is obvious that the described embodiments are only a part of the embodiments of the present application, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present application.

The technical terms and related concepts related to the embodiments of the present application will be briefly described below, wherein:

1. memory (Memory).

The memory may be referred to as an internal memory and a main memory, and temporarily stores operation data in a Central Processing Unit (CPU), data exchanged with an external memory such as a hard disk, and the like. The memory in the operating system may be roughly divided into: physical Memory (Physical Memory) and Virtual Memory (Virtual Memory); the following briefly introduces the relevant contents of the physical memory and the virtual memory, respectively, where:

(1) Physical memory (Physical memory). Physical memory refers to the memory space obtained by physical memory banks deployed in computer equipment; if the memory size of the physical memory bank disposed in the computer device is 4 Megabytes (MB), the memory size of the physical memory of the operating system disposed in the computer device is determined to be 4 megabytes.

When a process in an operating system has a requirement of creating a shared region from a physical memory to implement data sharing and transfer among a plurality of processes, any process can apply for creating a shared memory (shared memory) to the operating system. Shared memory is a common data caching scheme, which allows multiple processes to access the same memory space, so as to share and transfer data among multiple processes. Specifically, when an operating system detects that a process has a shared memory creation requirement (for example, the process initiates a shared memory creation request), the operating system arranges a same memory area (i.e., a shared memory) for different processes in a physical memory, so that a plurality of processes can connect the shared memory to their own process address spaces to realize data sharing in the shared memory; in other words, a communication connection is established between each process and the shared memory, and each process can access an address in the shared memory to obtain data stored in the shared memory. Further, if a process modifies data in the shared memory, the data read from the shared memory by other processes may also change. That is to say, the shared memory is a memory space that is partitioned by the operating system from the physical memory for a plurality of processes, and supports the plurality of processes to perform data reading and writing (reading and writing) operations in the shared memory, so as to implement data sharing and data transmission by the plurality of processes through the shared memory.

Besides the above mentioned features of supporting multi-process access, the shared memory has the following features, which are different from the ordinary memory: when the process exits (for example, the connection between the process and the shared memory fails), if the data in the shared memory is not actively released by the process, the data in the shared memory cannot be recycled by the operating system; after the process has remapped the shared memory, the process data can be recovered. The shared memory supports mapping of data in the memory to a local file, so that data are not lost when the process is finished; and, after the process is restarted (i.e. communication connection is reestablished between the process and the shared memory), the memory data can be recovered according to the local file. Therefore, depending on the data caching feature of the shared memory, the shared memory is often used for short-term persistence of data (for example, when non-POD type data is stored in the shared memory, short-term persistence of the non-POD type data in the shared memory may be implemented) and for fast recovery of data after a process crash.

(2) Virtual Memory (Virtual Memory). Different from a physical memory, a virtual memory is a memory space virtualized by an operating system for a process, and provides an independent and private memory space for the process; through a virtual memory mechanism, the process considers itself to occupy all the physical memory. The above-mentioned Process (Process) is a running activity of a program in a computer on a certain data set, is a basic unit for a system to perform resource allocation and scheduling, and is the basis of an operating system structure. In short, 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, so that the successful running of the game is realized through the process.

Taking an operating system with 48 bits of virtual memory as an example, the range of the virtual address space (i.e. the process address space of a process) is

TeraByte (TB), divided according to the ratio of 1; 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 the process address space is roughly distributed as follows: program segment (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 codes in the memory and storing the binary codes of the function body (namely, the whole body formed by all codes defining one function in the programming language). The initialized data refers to data that has initialized variables at the beginning of program execution. The uninitialized data refers to data in which a variable is not initialized at the beginning of program operation. The stack is used to store local and temporary variables; when the function is called, storing a return pointer of the function, and controlling the calling and returning of the function; memory is automatically allocated at the beginning of a block and released at the end of the block, operating in a manner similar to a stack in a data structure. Heap for dynamic memory allocation requires manual allocation and manual operation by developersReleasing; the heap in the process address space and the heap in the data structure are two things and are allocated in a manner similar to a linked list. In addition, 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 + paging", that is, the process address space of the process is implemented in the form of "segment + paging". Segmentation refers to dividing the memory into sections (e.g., code section, data section, \8230;), each of which may be different in length.

In order to improve the security of a process Address Space, an Address Space Layout Randomization (ASLR) mechanism is added to an operating system; the ASLR mechanism prevents attackers from jumping to specific locations of the memory to utilize functions by randomly placing address spaces of critical data areas of processes to prevent malicious programs from attacking known memory addresses. The above-mentioned key data areas may include, but are not limited to, a code segment (. Text), a data segment (. Data or. Bss), a stack area (. Heap), a stack area (. Stack), a mmap (memory mapped segment), a dynamic library, and the like in a 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 to the process, but data and code of the process must be put on the physical memory, and then a mechanism must be provided to remember which physical memory address a certain data in the process address space is put on, which is called address space mapping; i.e., the mapping of virtual memory addresses to physical memory addresses. In practical application, the mapping relation of virtual memory addresses to physical memory addresses is recorded through a page table. The page table may be configured to store a mapping relationship between a virtual memory address and a physical memory address; each process has its own page table, so that each process can determine the mapping relation between its data in virtual memory address and physical memory address through its own page table.

An exemplary schematic diagram of the mapping between physical memory and virtual memory can be seen in fig. 2; as shown in fig. 2, there is a physical memory in the operating system, a process address space of process 1 (alternatively referred to as a virtual address space, i.e., the virtual memory mentioned above), and a process address space of process 2. For processes (such as process 1 and process 2), the corresponding process address space is similar to a lookup table, and the process reads data from the physical memory through the lookup table; for example, when the process 1 wants to obtain data in the virtual space a in the process address space, it should translate the virtual memory address of the virtual memory a into the physical memory address a, and then read the data from the physical memory address a in the physical memory. It is worth noting that the unused address space in the process address space is not mapped into the physical memory, so that the operating system does not need to allocate the physical memory for the address space; in this way, the kernel can allocate a small amount of physical memory for the process just created, and as the process runs and uses the memory continuously, the kernel allocates the physical memory for the process as required.

2. And (4) data.

The data related to the embodiment of the application mainly comprises: POD (Plain Old Data) type Data and non-POD type Data. At the data level, the biggest difference between POD-type data and non-POD-type data is that: whether a virtual function table pointer is included; the virtual function table pointer is a key data structure for realizing virtual functions and virtual base classes. The above-mentioned POD type data, non-POD type data, virtual functions, virtual base classes, virtual function table pointers, and the like will be described below.

In practical application, the bottom layer of the operating system is basically written in C (a programming language), and after the basic data types (such as int (integer), char (pointer), float (floating point number), enumeration, pointer, array, structure, and the like) defined in C language are copied through binary, the data can still be kept unchanged, that is, the compiler can correctly parse the data under the basic data types through binary data. However, classes in the computer high-level programming language C + + (C plus plus) generated by the extension upgrade of the C language (which is a process-oriented, abstract, general programming language and widely used in underlying development) introduce new concepts such as inheritance and derivation, and a compiler cannot parse these complex data structures; therefore, the C + + language proposes the concept of the POD data structure in order to be compatible with the C language. That is, POD type data is defined by C + + language, and a data structure compatible with C language.

Specifically, POD type data may refer to class (class), structure (struct) that can be operated using a function such as memcpy () of C language; since data types basically built in C + + language are all POD types, it is generally discussed whether a class (class), a structure (struct), and a variable (union) 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 creating objects) and destructors (methods for cleaning data (such as freeing memory space allocated when objects are created) after the objects end a generation period), default copy constructors (methods for completing the construction and initialization of objects based on the same class) and mobile constructors (methods for realizing resource transfer of objects), default copy assignment operators and mobile assignment operators; etc., these POD-type data cannot contain virtual functions and/or virtual base classes.

It should be noted that (1) the above mentioned classes are a collection of different objects (or called instances, for example, the objects belonging to the vehicle class may include bicycles, cars, trucks, etc.) sharing the same features in the programming language C + +. Member functions of each object can be defined in the class; after a class is created, it 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 inner space in a shared memory for the instance of the class, so that an instance method of the object can be called to implement some functions. In the C + + language, classes have inheritance; inheritance is the establishment of a new class on the basis of an existing class; the original program code can be repeatedly used by utilizing the inheritance of the class, so that the redundancy of the program code is reduced, the function of a programming language is enhanced, and the software development efficiency is improved. In the inheritance relationship, the inherited class is called a base class (or a parent class), and a new class created through the inheritance relationship is called a derived class (or a subclass); the derived class inherits the data and functions of the base class, and the base class can point to the derived class object (i.e. the data obtained by instantiating the derived class) through the base class pointer.

(2) The virtual function refers to a member function of the class modified by a key word, wherein the key word 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 running, a compiler adds a virtual function table pointer vtptr to an object on the memory layout of generated object data; 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., the address space locations (i.e., storage 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 respective virtual function table pointer, so that the virtual function is read in 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 simple generalization is that a base class pointer of the base class points to an object of the subclass, and then a member function (such as a virtual function) of the object is called through the object pointer of the base class. That is, a polymorphism is a virtual function that is called by a base class, and depends on which type of object the pointer object of the base class points to. The above-mentioned polymorphic and imaginary functions are briefly introduced below by exemplary code, which is as follows:

#include

// header File

using namespace std// declaring variables

class A// class A

{

public:// public member

virtual void Print() { cout

endl;// imaginary function

H } a/inheritance A class

class B public A// class B

{

public:// public Member

virtual void Print() { cout

endl;// rewrite the imaginary function

H } a/inheritance A class

class C, public A// C

{

public:// public member

virtual void Print() { cout

endl;// overwrite the imaginary function >>

H// inherit A class

int main ()// Main function returning integer data

{

B b; C c;

A

pa =&b// base class pointer pa points to the derived class object b

pa- > Print (),/polymorphic, b.print () is called, output: b, print

pa = & c// base class pointer pa points to derived class object c

pa- > Print (),/polymorphic, c.print () is called, output: c, print

return 0;/return 0

}

As can be seen from the above codes, when a virtual key is added before the member function Print () of base class a, the member function Print () is determined to be a virtual function. The base class A specifically calls a virtual function of which derived class object (such as a derived class object B inheriting the base class A or a derived class object C inheriting the base class A), and the virtual function depends on the object type pointed by the base class pointer of the base class A; that is, when a base class pointer call of the base class is used, it is trueThe interface being called is dynamically determined based on the object to which its pointer points. For example, rewriting the member function in the derived class object B (or the derived class object C) (e.g., rewriting the member function in the derived class object B is: print () { cout

endl }); when the program runs, 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, then B: print is output. If the base class pointer pa of the base class A points to the derived class object C, then it is determined that the base class A calls the member function (Print () { cout ^ based on)>

endl, then outputting C:: print.

Based on the above description of the shared memory, the shared memory not only supports multi-process access, but also can implement short-term data persistence and data recovery; due to the advantages of the shared memory, storing data in the shared memory becomes an indispensable development step for developers in development engineering. However, when data management of the shared memory is implemented, only POD type data, not non-POD type data, can be stored in the shared memory. This is because object data containing a virtual function or virtual base class introduces a virtual function table pointer and virtual function table data in order to realize polymorphism. The virtual function table pointer is used for pointing virtual function table data, the virtual function table pointer and object data of a target object are stored together, virtual function table data of different objects belonging to the same class are uniformly placed in a progress virtual space called a read-only reentry section (. Data.rel.ro), and the read-only reentry section is located in a code segment (. Text) of a progress address space; for convenience of illustration, the data of the virtual function table containing only the target object in the read-only reentrant segment is taken as an example and is described herein. As shown in fig. 3a, a code segment (. Text) 301 in the process address space includes a read-only reentrant segment in which virtual function table data of a target object is stored. The virtual function table data is a continuous memory, similar to an array, and includes function addresses of one or more virtual functions declared for a target object (such as any object), where the function address of any virtual function is used to indicate: the address space position of any virtual function in the process address space, that is, 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, and the function address 303 can be regarded as a function pointer (ptr) pointing to the virtual function 302, and the function pointer points to the address space location in the code segment where the virtual function 302 is stored, so that the virtual function can be read from the function address 303 (such as obj:: fun 1).

And due to an ALSR mechanism in the operating system, after the target process is restarted each time, 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 start address and the end 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 further 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. Based on the virtual function table pointer before the restart of the process, which is stored in the shared memory, the virtual function table data after the restart of the process cannot be read from the process address space, so that the virtual function table pointer can be invalid after the restart of the target process. Therefore, the data of the virtual function table cannot be reused by the pointer of the virtual function table after the target process is restarted, so that the selection of data stored in the shared memory in the actual development process is greatly limited, namely only those POD type data can be stored, but non-POD type data containing the pointer of the virtual function table cannot be stored, the data types supported and stored by the shared memory are limited, and the data stored in the shared memory by a developer in a user-defined mode is greatly limited.

Based on this, an embodiment of the present application provides a memory processing scheme, which is specifically a scheme for persisting non-POD type data in a shared memory. That is to say, the memory processing scheme does not limit the type of data stored in the shared memory, that is, the shared memory may not only hold and store POD type data, but also persistently store non-POD type data, where the non-POD type data includes a virtual function table pointer corresponding to a target process, and the validity of the virtual function table pointer in the non-POD type data is maintained, thereby helping a developer store any self-defined type of data in the shared memory. The memory processing scheme provided by the embodiment of the present application can be seen in fig. 3a and 3b, and the memory processing scheme can be roughly divided into: a preset phase and a restart phase. Wherein:

(1) in the preset stage, when the target process needs to be started for the first time, copying the virtual function table data in the process address space of the target process to a designated area in the shared memory (as shown in fig. 3 a), so as to determine the memory location pointed by the 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 designated 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 presetting phase, the virtual function table pointer is preset to point to a target memory location in the designated 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. As shown in fig. 3b, assuming that after the data of the virtual function table is copied to the designated area in the shared memory, the function address of the virtual function table pointer to be called is 0x4568445, 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 only needs to be fixedly pointed to a target memory position in a designated area in the shared memory instead of a process address space, and the failure of the virtual function table pointer caused by the change of the address of each segment in the process address space can be avoided.

(2) In the restart phase (i.e. the target process is restarted (or simply referred to as a restart phase)), the virtual function table data updated by the function address in the process address space needs to be copied 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 by the updated virtual function table data (the virtual function table data is copied to the designated area before the target process is restarted this time). Therefore, the function address contained in the virtual function table data can be updated at one time in the designated area, namely, the function address is replaced by the correct function address, so that all virtual function table pointers pointing to the function addresses are ensured to finish repairing at one time, and the target process can call the virtual function required by the target process to run from the virtual function table data stored in the designated area through the virtual function table pointers.

To sum up, the memory processing scheme provided in the embodiment of the present application only needs to modify the data of the virtual function table pointer of the non-POD type data when the target object is created, and to modify the virtual function table data stored in the shared memory once when the target process is restarted, so that the repair of all the virtual function pointer data can be completed, and the virtual function pointers are ensured to be always effective. For developers, the types of data which can be stored in the shared memory do not need to be considered, for example, the developers can directly store non-POD type data into the shared memory, the developers are 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 worried about, and the data storage flow is optimized.

Based on the above simple description of the memory processing scheme provided in the embodiment of the present application, the following points are worth explaining:

(1) as described above, the concepts of classes, vtable pointers, vtable data, and the like related to the embodiments of the present application are proposed in C + + language; therefore, the memory processing scheme provided by the embodiment of the application has universality and is suitable for all application scenarios which are written by using C + + language and need to perform data recovery of the shared memory. For example, in a scenario where game code is written in C + + language, in order to ensure continuity of a game, it is often necessary to allocate a shared memory to multiple processes required for game execution, and then virtual function table data in the data may be copied to a specified area in the shared memory. Therefore, when the process is restarted (for example, the game player needs to re-enter the game after exiting the game due to network connection failure of the game player, that is, the process is required to be restarted at this time), the updated virtual function table data is copied to the specified area again, and the virtual function table pointer in the shared memory can read the correct function address of the virtual function from the specified 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 a specific application scenario of the memory processing scheme.

(2) The embodiment of the application supports the execution of the memory processing scheme by the computer equipment. The computer device can be any device comprising a memory; optionally, the computer device may be a terminal device, and the terminal device may include but is not limited to: the embodiments of the present disclosure do not limit the types of terminal devices, and the terminal devices are described herein. Optionally, the computer device may be a server, the server may be an independent physical server, or a server cluster or a distributed system formed by a plurality of physical servers, or a cloud server providing basic cloud computing services such as a cloud service, a cloud database, cloud computing, a cloud function, cloud storage, a Network service, cloud communication, a middleware service, a domain name service, a security service, a CDN (Content Delivery Network), a big data and artificial intelligence platform, and the like; the embodiment of the present application does not limit the specific type of the server.

Based on the above-described memory processing scheme, a more detailed memory processing method is provided in the embodiments of the present application, and a detailed description will be given below with reference to fig. 4 of a specific implementation process of a process restart stage in the memory processing method provided in the embodiments of the present application. Fig. 4 is a schematic flowchart illustrating a memory processing method according to an exemplary embodiment of the present application; the memory processing method may be executed by the aforementioned computer device, and the memory processing method may include, but is not limited to, steps S401 to S403:

s401: and 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, that is, the target process cannot read data from the shared memory. The embodiment of the present application does not limit the reason for the target process to exit. For example, when a game player exits a game room due to a network failure in a game scene, it is determined that a target process allocated for the game exits. And the following steps: in a game scenario, a target process exits due to a game player wanting to switch processes (e.g., in the process of playing a game in a game room, wanting to switch to a social application program to view social information, at which time the target process allocated for the game exits). Further, when the target process is restarted, the target process needs to reestablish a communication connection with the shared memory at this time, so that the target process can read data from the shared memory after the communication connection is successfully established. 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 relation 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 described herein again.

Furthermore, after the communication connection is reestablished between the target process and the shared memory, that is, after the target process is restarted successfully, it is also necessary to determine a designated area in the shared memory 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 area in the shared memory may be specifically located in a shared memory mapping segment (mmap segment) in the shared memory, as shown in fig. 3a, a specific position of the specific area in the shared memory mapping segment is not limited in the embodiment of the present application. The designated area in the shared memory can be designated when the target object is created; specifically, when the target object is created, it is supported that an area is defined as a designated area for storing the virtual function table data of the target object by default in the shared memory, so that the virtual function table data of the target object (i.e. the virtual function table data corresponding to the above-mentioned target process) can be copied into the designated area in the subsequent process.

It is noted that the number of classes in a target process is often quite large, and instantiating a class may result in one or more objects. In order to facilitate management of virtual function table data of objects of different classes in a shared memory, the embodiments of the present application support dividing a designated area for one or more objects of the same class in the shared memory, and dividing different designated areas for objects of different classes in the shared memory. By dividing a designated area for one or more objects of the same class, we can refer to: the vm table data of one or more objects belonging to the same class may be stored in the same designated area in the shared memory. The division of different designated areas for different classes of objects may refer to: and storing the virtual function table data of the objects belonging to different classes to 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, it is supported that a designated area 1 is divided in the shared memory to store the vtable data of object 1 and the vtable data of object 2 in class 1, and a designated area 2 is divided in the shared memory to store the vtable data of object 3 in class 2. For convenience of description, the embodiment of the present application takes a specific area in the shared memory, and the specific area is used to store virtual function table data of a target object (such as any object) after class instantiation, and is described herein specifically.

S402: and acquiring virtual function table data corresponding to the target process from the process address space of the target process.

S403: and copying the acquired virtual function table data to a specified area in the shared memory.

In steps S402-S403, after the shared memory and the target process are remapped based on the foregoing steps, in the embodiment of the present application, virtual function table data corresponding to the target process, specifically, virtual function table data of a target object in the target process, needs to be obtained from a process address space of 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 a designated area in the shared memory. Therefore, the virtual function table pointer for calling the virtual function in the shared memory 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 one hand, the virtual function table data of the target object is stored in the read-only reentrant segment in the process address space; the read-only reentrant segment may be used to store virtual function table data of 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 shared memory is divided into the same designated area for the virtual function table data of different objects in the same class, that is, the virtual function table data of different objects belonging to the same class can be stored in the same designated area in the shared memory. Therefore, when the virtual function table data is copied to the designated area in the shared memory from the process address space, all data included in the read-only reentrant section where the virtual function table data is located in the process address space are specifically copied to the designated area in the shared memory together. For example, it is assumed that the read-only reentrant segment includes one or more virtual function table data of different objects belonging to the same class, and the one or more virtual function table data includes virtual function data of the target object; 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 specified area in the shared memory. By the mode of copying all the data in the read-only reentrant segment, 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 segment, the data copying speed and efficiency are greatly improved.

For convenience of explanation, taking the case that the read-only reentrant segment in the process address space only contains the virtual function table data of the target object, a specific implementation process of copying the virtual function table data from the process address space to the execution area in the shared memory is introduced; the implementation process may refer to fig. 5, which includes, but is not limited to, steps s11-s12:

s11: and acquiring a starting address and an ending address of the virtual function table data in the process address space. 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 as follows: a continuous region starting from a start address in the memory present process address space to an end address in the memory present process address space; 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 the read-only reentrant segment only contains the virtual function table data of the target object, the starting address of the virtual function table data in the process address space may be considered as: the starting address of the read-only re-entry segment in the process address space; the end address of the virtual function table data in the process address space is as follows: the starting address of the read-only reentrant section 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 section in the process address space. Then, the start address and the end address of the virtual function table data in the process address space can be determined by acquiring the start address and the end address of the read-only reentrant section, so that the virtual function table data can be copied based on the start address and the end address of the virtual function table data in the process address space.

It is considered that the address of the read-only reentrant segment in the process address space is determined by a program loader (or referred to as a process loader) each time the target process is loaded, and the behavior of the program loader is controlled by a linker (linker) of the program through a linker 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 are determined. Wherein, (1) the above-mentioned program loader is responsible for program loading, specifically, the program is placed into the memory, and the program is started to run in the memory; the above mentioned linker supports resolving undefined symbolic references, replacing placeholders in the file with addresses of the symbols. (2) The above-mentioned link script is an executable file that supports loading into the process address space by the process loader to start performing certain functions; for example, the link script, after being loaded into the process address space, can be used to specify that various data in the program are placed in different sections of the process address space, and can also be used to control the program loader to assign some variables (such as a _ executable _ start program start position and a _ etext code segment end position) at the runtime of the target process.

As can be seen from the above description, the program loader determines the address for the read-only reentrant segment by loading the link script; therefore, the embodiment of the application supports that the program loader derives the start address and the end address of the read-only reentrant segment by generating the link script. The method for leading out the starting address and the ending address of the read-only re-read segment by the program loader through 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 using the original loading mode of the program loader, and has the advantages of small occupied memory of the link script for obtaining the read-only re-read segment and no large memory overhead.

In the specific implementation, a first address variable and a second address variable are obtained first, wherein the first address variable is used for obtaining a starting address of a read-only reentrant section, and the second address variable is used for obtaining an ending 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 derive a starting address and an ending address of the read-only reentrant section; then, the target link script is added to the default script (that is, the script that includes the original logic when the program is loaded), and after the added default script is obtained, the added default script can be loaded by using the program loader, and at this time, the program loader can output the start address and the end address of the read-only re-entry segment. An exemplary target link script is illustrated as follows:

/

get vtable section start address./>

/

v table start = ADDR (. Data. Rel. Ro);/obtaining start address of read-only reentrant segment

/

get vtable section end address./>

/

<xnotran> __ vtable _ end __ = __ vtable _ start __ + SIZEOF (. Data.rel.ro);// </xnotran>

Wherein "subscriber" in the code

get vtable section start address./>

The function of "\\u vtable _ start _ = ADDR (. Data. The start address of the read-only re-entry segment is obtained. Similarly, "/" in the code>

get vtable section end address./>

<xnotran>/" " __ vtable _ end __ = __ vtable _ start __ + SIZEOF (. Data.rel.ro); " : </xnotran> And acquiring the end address of the read-only reentrant section. The aforementioned first address variable is "\_ vtable _ start _" in the 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 segment in a process address space to a specified area in a shared memory; and the data between the start address and the end address of the read-only re-entry segment 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 by 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 specified area in the shared memory directly according to the start address, the end address and the memory size. Illustratively, copying the code in the data in the read-only reentrant segment based on the start address, the end address, and the memory size is as follows:

// custom Special symbol X

Extern char _ vtable _ start _ [ ]// the start address of the read-only reentrant section where the virtual function table data is located

Extern char _ vtable _ end _ [ ];// end address of read-only reentrant section where virtual function table data is located

long size = (long) _ vtable _ end \\\\\\\\\ \ vtable _ start _;// memory size of read-only reentrant segment

memcpy (dest, \\ vtable _ start _, size)// copying the data in the read-only reentrant section to a designated area (e.g., the address of the designated area is dest address)

According to the codes, after the start address and the end address of the read-only reentrant section are obtained, the amount of memory occupied by the read-only reentrant section in the process address space can be determined according to the start address and the end address of the read-only reentrant section; specifically, the amount of memory occupied by the read-only reentrant section in the process address space is obtained by subtracting the start address from the end address. It should be noted that the customized special symbol X needs to be linked to the shm.lds file loaded by the linker, so that when the linker loads shm.lds, the code of the linked special symbol X can be loaded together to implement the function achieved by the code (i.e., the code of the special symbol X) (i.e., the data of the virtual function table in the read-only reentrant segment is copied to the specified area in the shared memory).

As can be seen from steps s11 and s12, on one hand, after the start address and the end address of the read-only reentrant segment are derived by the target link script, in the embodiment of the present application, the 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 by using 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 reentrant segment is only used for storing the virtual function table data, that is, the read-only reentrant segment does not contain other data except the virtual function table data, which makes the embodiment of the present application do not care about the specific data content in the read-only reentrant segment, and only needs to copy all the data contained in the read-only reentrant segment, so that the embodiment of the present 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 reentrant 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 segment 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 derive variables (such as the start address and the end address of the program) during running; this makes the process of deriving the start address and the end of the read-only reentrant segment by letting the program loader load the target link script, consistent with the original loading logic of the program loader, ensuring the feasibility of address derivation.

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 of the target process; for example, the address of the code segment in the process address space changes, and the code segment stores the virtual function and the virtual function table data, which also causes the function address of the virtual function in the process address space to change. Therefore, after the target process is restarted every time, the function address contained in the virtual function table data in the read-only reentry segment needs to be 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 thus the virtual function table pointer can 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 virtual function is in the address space position (or storage position) after being updated in the process address space; then, updating corresponding reference function addresses in the virtual function table data by adopting the target function addresses of all the virtual functions to obtain updated virtual function table data; wherein, the reference function address of the virtual function is used to indicate: the virtual function is at an address space location (or storage location) in the process address space prior to reestablishing the communication link 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 a contained in the virtual function table data is 0x1234, which indicates that the storage location of the virtual function a in the process address space is the location of the function address 0x 1234; after the communication connection is reestablished between the target process and the shared memory, the address space position of the virtual function a in the process address space changes, and if the storage position of the virtual function a in the process address space changes to be a function address of 0x2234, the function address of 0x2234 of the virtual function is adopted to replace the function address of 0x1234 in the virtual function table data, so as to update the function address of the virtual function a in the virtual function table data. Further, the above replacement process is performed on each function address in the virtual function table data, so that the updated virtual function table data can be obtained.

Furthermore, the updated virtual function table data is copied to the designated area in the shared memory, so that one-time updating or batch updating of the function addresses of the virtual functions stored in the designated area can be realized, and the virtual function table pointers pointing to the function addresses of the virtual functions can be repaired at one time.

To sum up, the embodiment of the present application supports that after a target process is restarted (that is, a communication connection is reestablished between the target process and a shared memory) at any time, only the updated virtual function table data in the process address space needs to be copied into the designated area, that is, the new virtual function table data is used to cover the virtual function table data before the target process is restarted; the target process can call the function address of the virtual function required by the target process to run from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, and the one-time repair of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports the division of the designated area in the shared memory to cache the data of the virtual function table, so that after the non-POD type data containing the pointer of the virtual function table is stored in the shared memory, the pointer of the virtual function table can be directly read from the shared memory to the correct function address of the virtual function to be called, and the validity of the pointer of the virtual function table is always kept. In addition, for developers, the selection of data types is not limited, and any customized object data can be stored in the shared memory.

The embodiment shown in fig. 4 mainly describes a specific implementation process of a process restart phase in the memory processing method in detail, and a specific implementation process of a preset phase in the memory processing method is described in detail below with reference to fig. 7. Fig. 7 is a flowchart illustrating a memory processing method according to an exemplary embodiment of the present application; the memory processing method may be executed by the aforementioned computer device including a memory, and the memory processing method may include, but is not limited to, steps S701 to S707:

s701: after a target object of a target process is created in a shared memory, virtual function table data corresponding to the target process are obtained from a process address space of the target process.

S702: and copying the acquired virtual function table data to a specified area in the shared memory.

In steps S701 to S702, when the target process is started for the first time, it is supported to copy the virtual function table data of the target object in the process address space of the target process to a designated area in the shared memory, so that when the target object is created (for example, a class is loaded to the shared memory, and a target object of the class is created in the shared memory), based on the memory address of the virtual function table data in the shared memory, a pointer address (referred to as a first pointer address in this embodiment) pointed by each virtual function table pointer pointing to the virtual function table data is replaced with the memory address of the virtual function table data in the shared memory; therefore, the pointer address (referred to as the second pointer address in the embodiment of the present application) of the virtual function table pointer does not need to be updated any more regardless of whether the target process is restarted subsequently, and the validity of the virtual function table pointer can be maintained.

It should be noted that the specific implementation process shown in steps S701 to S702 to obtain the virtual function table data corresponding to the target process from the process address space and copy the obtained virtual function table data to the designated area in the shared memory is similar to the specific implementation process shown in steps S402 to S402 in the foregoing embodiment shown in fig. 4, and reference may be made to the relevant description in steps S402 to S402, which is not described herein again.

S703: and acquiring the address offset of the virtual function table pointer of one or more base classes of the target object.

After non-POD type data is successfully created in the shared memory (for example, the non-POD type data containing the virtual function table pointer is stored in the shared memory, and the virtual function table data pointed by the virtual function table pointer is copied to a designated area in the shared memory), the embodiment of the application supports modifying the data of the virtual function table pointer of the non-POD type data, namely, all the virtual function table pointers of the virtual function table data pointed to a target object are subjected to address replacement; specifically, first pointer addresses of all virtual function table pointers pointing to virtual function table data in a process address space are replaced by addresses of the virtual function table data stored in a designated area in a shared memory. Therefore, 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 (i.e. the parent class inherited by the class of the target object) can call any virtual function of the target object through a virtual function table pointer; any of the virtual functions may include: the target object inherits the obtained virtual function from the base class or the virtual function specific to the target object. Thus, all of the above mentioned vtable pointers to vtable data of the target object may include: virtual function table pointers to one or more base classes of the target object.

The embodiment of the application supports the address offset of the virtual function table pointer of the base class, and determines the pointed address in the designated area in the shared memory for the virtual function table pointer so as to realize the repair of the virtual function table pointer. The address offset of the virtual function table pointer of any base class can be used to indicate: the offset between the address space position pointed by the virtual function table pointer of the base class in the process address space and the initial address space position 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 stored in order, and the address offset of the virtual function table pointer of any base class indicates: and in the process address space, the virtual function table data is the arrangement position of the function address of the virtual function to be called by the virtual function table pointer in the virtual function table data. For example, function address 1 of the virtual function 1, function address 2 of the virtual function 2, and function address 3 of the virtual function 3 are arranged in the virtual function table data 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, then 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 from the start address of the virtual function table data is 3.

In a specific implementation, the implementation process of determining, for the virtual function table pointer, an 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 the target object are obtained. Virtual functions of the target object can be called by considering the base class of the target object; therefore, all base classes of the target object are collected first, so that address replacement is performed on the virtual function table pointer of the virtual function for calling the target object for each base class. Specifically, all base classes of the target object are collected through std:: tr2:: bases class; the base classes can automatically return to a base class list of the target object through the std:: tr2:: the base classes are supported by a compiler and used for automatically acquiring base classes of types in the class hierarchy, and 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 part of the virtual function inherited by the derived class object from the base class can be called through the base class pointer. In a specific implementation, an object pointer (i.e., a pointer pointing to a target object) may be converted through a dynamic _ cast function, and a result after the conversion is used as a base class pointer of a base class; wherein, the dynamic _ cast function is a function for realizing the conversion of the pointer type.

Further, acquiring a virtual function table pointer of each base class; specifically, a pointer address (which may be referred to as a first pointer address in this embodiment) of a virtual function table pointer of each base class is obtained, and 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 of any base class is the address space position in the process address space; namely, the function address of the virtual function to be called by the virtual function table pointer in the virtual function table data, and the storage position in the process address space. As can be seen from the foregoing description, the derived class may additionally add some dummy functions that the base class does not have, in addition to inheriting the dummy functions from the base class; after the base class pointer is converted downwards into the virtual function table pointer, the base class can call the part of member functions specific to the target object through the virtual function table pointer. In 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 virtual function table pointer address is stored in 8 bytes of the head of the base class pointer, a reinterpret _ cast function is adopted to realize the forced conversion of the base class pointer into the virtual function table pointer so as to obtain a first pointer address of the virtual function table pointer; the reinterret _ cast function is a mandatory type converter, and can convert the base class pointer downwards to obtain the virtual function table pointer. In this way, 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 by the first pointer address of the virtual function table pointer of the base class.

And 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 the address space position in the process address space. Further, the first pointer address of the virtual function table pointer of each base class and the initial address of the virtual function table data in the process address space are subjected to subtraction operation, 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: and determining the target memory position pointed by the virtual function table pointer of each base class in the designated area 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 the shared memory.

Based on the specific implementation process shown in 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 location 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. It is considered that after the virtual function table data is copied from the process address space to the designated area in the shared memory, the start address of the virtual function table data changes (i.e. the start address of the virtual function table data in the process address space is different from the start address in the shared memory), but the internal structure of the virtual function table data does not change, i.e. the distance between the function addresses contained in the virtual function table data (i.e. the address offset) is the same. Then, the address offset of the virtual function table pointer of each base class is added to the initial address of the virtual function table data in the shared memory after the virtual function table data is copied to the designated area in the shared memory, so as to obtain the storage address (i.e. 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 may be obtained 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 in any base class is in a target memory location (or called 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 by the address pointed by the virtual function table pointer in the shared memory.

In summary, based on the above steps S703-S705, the second pointer address of the virtual function table pointer of the base class, which is actually in the shared memory, can be obtained based on the address offset of the virtual function table pointer of the base class and the start address of the copied virtual function table data in the shared memory. The flow shown in the above steps S703-S704 may be implemented by the following codes:

Base

base_ptr = dynamic_cast/>

(&instance)// obtaining the address of the object Base class (Base) pointer

long vptr =

reinterpret_cast/>

(base _ ptr);/force-convert to the address pointed to by the VIP table pointer, i.e. convert to the first pointer address of the VIP table pointer

long vptr _ offset = vptr- (long) _ vtable _ start _;/relative. Data

long new _ vptr = (long) dest + vptr _ offset,// dest shared memory segment address, calculating the address relative to the shared memory segment, i.e. calculating the second pointer address of the virtual function table pointer

long

cast_pointer = reinterpret_cast/>

(base _ ptr);/numerical conversion

case _ pointer = new _ vptr, covering the first pointer address of the virtual function table pointer of the base class as the second pointer address in the shared memory

Further, to facilitate a better understanding of the implementation of the address replacement given above, an exemplary process for determining an address offset of a vtable pointer of a base class and determining a second pointer address of the vtable pointer is described below in conjunction with fig. 8. As shown in fig. 8, it is assumed that when the target object is created, the starting address of the virtual function table data in the process address space is 0x2344E; the first pointer address of the virtual function table pointer is 0x23456, which indicates that the virtual function table pointer points to the address 0x23456 in the process address space, the function address 0x2234 is stored at the first pointer address 0x23456, which indicates that the virtual function table pointer is used for calling the virtual function with the address 0x2234 in the process address space; determining the address offset of the virtual function table pointer in the process address space as: the first pointer address 0x23456 of the virtual function table pointer subtracts the starting address 0x2344E of the virtual function table data in the process address space, 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 allow the virtual function table pointer to 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 start 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 vtable data in the shared memory is 0x456843D, then knowing that the address offset of the vtable pointer is 8, it can be determined that the second pointer address of the vtable pointer in the shared memory is: the initial address of the virtual function table data in the shared memory is 0x456843D, the address offset of the virtual function table pointer is 8, and the addition result is 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 complete address replacement of the virtual function table pointer; and pointing the replaced virtual function table pointer to the memory position where the second pointer address is located in the shared memory, and indicating that a virtual function corresponding to the function address at the memory position where the second pointer address is located is required to be called.

S705: and 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 the process address space of the target process.

S707: and copying the acquired virtual function table data to a specified area in the shared memory.

It should be noted that, for the specific implementation process shown in steps S705 to S707, reference may be made to the related description of the specific implementation process shown in steps S401 to S403 in the embodiment shown in fig. 4, and details are not repeated herein.

In the embodiment of the application, a designated area is defined in the shared memory to cache the data of the virtual function table, and each virtual function table pointer needing to call the data of the virtual function table is bound at one time, that is, each virtual function table pointer is preset to point to the designated area in the shared memory, specifically to point to the memory location where the function address of the virtual function to be called in the designated area is located. In this way, after any target process is restarted (i.e. communication connection is established between the target process and the shared memory by reestablishment), only the updated virtual function table data in the process address space needs to be copied into the designated area, i.e. the new virtual function table data is adopted to cover the virtual function table data before the target process is restarted in the shared memory; the target process can call the function address of the virtual function required by the target process to run from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, and the one-time repair of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports the division of the designated area in the shared memory to cache the data of the virtual function table, so that after the non-POD type data containing the pointer of the virtual function table is stored in the shared memory, the pointer of the virtual function table can be directly read from the shared memory to the correct function address of the virtual function to be called, and the validity of the pointer of the virtual function table is always kept. In addition, for developers, the selection of data types is not limited, and any customized object data can be stored in the shared memory.

The foregoing describes the memory processing method in detail, and accordingly, the following provides an apparatus in this embodiment in order to better implement the foregoing scheme in this embodiment.

Fig. 9 is a schematic structural diagram illustrating a memory processing apparatus according to an exemplary embodiment of the present application; the memory processing means may be a computer program (comprising program code) running on a computer device; the memory processing device may be configured to perform some or all of the steps in the method embodiments shown in fig. 4 or fig. 7. Referring to fig. 9, the memory processing apparatus includes the following units:

a processing unit 901, configured to determine a designated area in the shared memory after a communication connection is reestablished between the target process and the shared memory, where the designated area is used to store virtual function table data corresponding to the target process; non-POD type data are stored in the shared memory, the non-POD type data comprise virtual function table pointers corresponding to a target process, and the virtual function table pointers are preset to point to a 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 specified area in the shared memory, so that the target process calls a virtual function required by the target process to run from the virtual function table data stored in the specified area through the virtual function table pointer.

In one implementation mode, the virtual function table data comprises function addresses of one or more virtual functions of the target object; a processing unit 901, further configured to:

In one implementation, the virtual function table data includes function addresses of one or more virtual functions of the target object; a processing unit 901, 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;

and determining the target memory position pointed by the virtual function table pointer of each base class in the designated area 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 the shared memory.

In an implementation manner, the processing unit 901, when acquiring address offsets of virtual function table pointers of one or more base classes of a target object, is specifically configured to:

In an implementation manner, the processing unit 901, when being configured to obtain the virtual function table pointer of each base class, is specifically configured to:

and carrying out pointer type conversion on the base class pointer of each base class to obtain the virtual function table pointer of each base class.

In an implementation manner, the processing unit 901, when determining, for a virtual function table pointer of each base class, a target memory location pointed in a specified area based on address offsets of virtual function table pointers of one or more base classes and a memory address of virtual function table data in a shared memory, is specifically configured to:

acquiring an initial address of copied virtual function table data in a shared memory;

In one implementation, the 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 copying the acquired virtual function table data to a designated area in the shared memory, the method is specifically configured to:

In one implementation, the virtual function table data of the target object is stored in a read-only reentrant section in the process address space, and the 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 virtual function table data of the target object, the processing unit 901 is specifically configured to, when acquiring a start address and an end address of the virtual function table data in a process address space:

In one implementation, virtual function table data of a target object is stored in a read-only reentrant segment in a process address space of a target process; when the read-only reentrant segment includes one or more pieces of virtual function table data of different objects, and the one or more pieces of virtual function table data include virtual function table data of a target object, the 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 copying the acquired virtual function table data to a designated area in the shared memory, the method is specifically configured to:

According to an embodiment of the present application, the units in the memory processing apparatus shown in fig. 9 may be respectively or completely combined into one or several other units to form the memory processing apparatus, or some of the unit(s) may be further split into multiple functionally smaller units to form the memory processing apparatus, which may implement the same operation without affecting implementation of technical effects of the embodiment of the present application. The units are divided based on logic functions, and in practical application, the functions of one unit can be realized by a plurality of units, or the functions of a plurality of units can be realized by one unit. In other embodiments of the present application, the memory processing apparatus may also include other units, and in practical applications, the functions may also be implemented by being assisted by other units, and may be implemented by cooperation of multiple units. According to another embodiment of the present application, the memory processing apparatus shown in fig. 9 may be constructed by running a computer program (including program codes) capable of executing the steps involved in the corresponding method shown in fig. 4 or fig. 7 on a general-purpose computing device such as a computer including 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 implementing the memory processing method of the embodiment of the present application. The computer program may be recorded on a computer-readable recording medium, for example, and loaded and executed in the above-described computing apparatus via the computer-readable recording medium.

In the embodiment of the application, a designated area is defined in the shared memory to cache the data of the virtual function table, and each virtual function table pointer needing to call the data of the virtual function table is bound at one time, that is, each virtual function table pointer is preset to point to the designated area in the shared memory, specifically to point to the memory location where the function address of the virtual function to be called in the designated area is located. In this way, after any target process is restarted (i.e. communication connection is reestablished between the target process and the shared memory), only the updated virtual function table data in the process address space needs to be copied into the designated area, i.e. the new virtual function table data is adopted to cover the virtual function table data before the target process is restarted; the target process can call the function address of the virtual function required by the target process to run from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, and the one-time repair of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports the division of the designated area in the shared memory to cache the data of the virtual function table, so that after the non-POD type data containing the pointer of the virtual function table is stored in the shared memory, the pointer of the virtual function table can be directly read from the shared memory to the correct function address of the virtual function to be called, and the validity of the pointer of the virtual function table is always kept. In addition, for a developer, the selection of the data type is not limited, and any customized 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. The processor 1001, the communication interface 1002, and the computer-readable storage medium 1003 may be connected by a bus or other means. The communication interface 1002 is used, among other things, to receive and transmit data. The computer-readable storage medium 1003 may be stored in a memory of the computer device, the computer-readable storage medium 1003 being used to store a computer program comprising program instructions, the processor 1001 being used to execute the program instructions stored by the computer-readable storage medium 1003. The processor 1001 (or CPU) is a computing core and a control core of the computer device, and is adapted to implement one or more instructions, and in particular, adapted to load and execute the one or more instructions so as to implement a corresponding method flow or a corresponding function.

Embodiments of the present application also provide a computer-readable storage medium (Memory), which is a Memory device in a computer device and is used for storing programs and data. It is understood that the computer readable storage medium herein can include both built-in storage media in the computer device and, of course, extended storage media supported by the computer device. The computer readable storage medium provides a memory space that stores a processing system of the computer device. Also stored in this memory space are one or more instructions, which may be one or more computer programs (including program code), suitable for loading and execution by processor 1001. It should be noted that the computer-readable storage medium may be a high-speed RAM memory, or may be a non-volatile memory (non-volatile memory), such as at least one disk memory; optionally, at least one computer readable storage medium located remotely from the aforementioned processor is also possible.

In one embodiment, the computer device may be the device including the memory mentioned in the previous embodiment; the computer-readable storage medium has 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 corresponding steps in the memory processing method embodiment; in particular implementations, one or more instructions in the computer-readable storage medium are loaded and executed by the processor 1001 as follows:

In one implementation mode, the virtual function table data comprises 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:

acquiring a target function address of each virtual function in one or more virtual functions, wherein the target function address of the virtual function is used for indicating: after communication connection is reestablished between the target process and the shared memory, the virtual function is located at the updated address space position in the process address space of the target process;

updating corresponding reference function addresses in the virtual function table data by adopting the target function addresses of all the virtual functions to obtain updated virtual function table data; the reference function address of the dummy function is used to indicate: and before the communication connection is reestablished between the target process and the shared memory, the virtual function is in the address space position in 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:

In one implementation, one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and when executing the step of obtaining an address offset of a virtual function table pointer of one or more base classes of a target object, the following steps are specifically performed:

In one implementation, one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and when the step of obtaining the virtual function table pointer of each base class is executed, the following steps are specifically performed:

In one implementation, one or more instructions in the computer-readable storage medium are loaded by the processor 1001 and when executing the step of determining, for the virtual function table pointer of each base class, a target memory location pointed to in the designated area based on an address offset of the virtual function table pointer of one or more base classes and a memory address of the virtual function table data in the shared memory, the following steps are specifically performed:

In one implementation, one or more instructions in a computer-readable storage medium are loaded by processor 1001 and upon execution obtain virtual function table data corresponding to a target process from a process address space of the target process; when the acquired virtual function table data is copied to a specified area in a shared memory, the following steps are executed:

In one implementation, the virtual function table data of the target object is stored in a read-only reentrant section in the process address space, and the 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 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 when executing the step of acquiring a start address and an end address of the virtual function table data in the process address space, the following steps are specifically executed:

In one implementation, virtual function table data of a target object is stored in a read-only reentrant segment in a process address space of a target process; when the read-only reentrant segment contains one or more pieces of virtual function table data of different objects, and the one or more pieces of virtual function table data contain 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 executed to obtain virtual function table data corresponding to a target process from a process address space of the target process; when the acquired virtual function table data is copied to a designated area in the shared memory, the following steps are specifically executed:

In the embodiment of the application, a designated area is defined in the shared memory to cache the data of the virtual function table, and each virtual function table pointer needing to call the data of the virtual function table is bound at one time, that is, each virtual function table pointer is preset to point to the designated area in the shared memory, specifically to point to the memory location where the function address of the virtual function to be called in the designated area is located. In this way, after any target process is restarted (i.e. communication connection is reestablished between the target process and the shared memory), only the updated virtual function table data in the process address space needs to be copied into the designated area, i.e. the new virtual function table data is adopted to cover the virtual function table data before the target process is restarted; the target process can call the function address of the virtual function required by the operation of the target process from the virtual function table data stored in the appointed area of the shared memory through the virtual function table pointer, and the one-time repair of the virtual function table pointer is realized. Therefore, the memory processing method provided by the embodiment of the application supports the division of the designated area in the shared memory to cache the data of the virtual function table, so that after the non-POD type data containing the pointer of the virtual function table is stored in the shared memory, the pointer of the virtual function table can be directly read from the shared memory to the correct function address of the virtual function to be called, and the validity of the pointer of the virtual function table is always kept. In addition, for developers, the selection of data types is not limited, and any customized object data can be stored in the shared memory.

An embodiment of the present application further provides a computer-readable storage medium, where a computer program is stored, and the computer program is suitable for being loaded by a processor and executing the memory processing method.

Those of ordinary skill in the art would 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 implementation. 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, the implementation may be wholly or partially realized 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. The procedures or functions according to the embodiments of the present application are all or partially generated when the computer program instructions are loaded and executed on a computer. The computer may be a general purpose computer, a special purpose computer, a network of computers, or other programmable device. The computer instructions may be stored on or transmitted over 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 wire (e.g., coaxial cable, fiber optic, digital Subscriber Line (DSL)), or wirelessly (e.g., infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device, such as a server, a data center, etc., that incorporates one or more of the available media. The available media may be magnetic media (e.g., floppy disks, hard disks, tapes), optical media), or semiconductor media (e.g., solid State Disks (SSDs)), among others.

The foregoing is only a specific embodiment of the present application, but the scope of the present application is not limited thereto, and any person skilled in the art can easily conceive of changes or substitutions within the technical scope disclosed in the present application, and shall be covered by the scope of the present application. Therefore, the protection scope of the present application shall be subject to the protection scope of the claims.

Claims

1. A memory processing method, comprising:

after communication connection is reestablished 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; non-POD type data are stored in the shared memory, the non-POD type data comprise a virtual function table pointer corresponding to the target process, and the virtual function table pointer is preset to point to the designated area;

acquiring virtual function table data corresponding to the target process from the process address space of the target process;

copying the acquired virtual function table data to a designated area in the shared memory, and calling a virtual function required by the running of the target process from the virtual function table data stored in the designated area by the target process 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 indicating: an 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, and 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 in the storage position of the specified area.

3. The method of claim 1, wherein the vtable data includes function addresses of one or more vtables of the target object; before the obtaining the virtual function table data corresponding to the target process from the process address space of the target process, the method further includes:

obtaining a target function address of each virtual function in the one or more virtual functions, where the target function address of the virtual function is used to indicate: after communication connection is reestablished between a target process and a shared memory, the virtual function is in the updated address space position in the process address space of the target process;

updating corresponding reference function addresses in the virtual function table data by adopting the target function addresses of the virtual functions to obtain updated virtual function table data; the reference function address of the dummy function is used to indicate: and before the communication connection is reestablished between the target process and the shared memory, the virtual function is in the address space position in the process address space of the target process.

4. The method of claim 1, wherein the vtable data includes function addresses of one or more vtables of the target object; the method further comprises the following steps:

copying the acquired 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 for indicating that: the offset between the address space position pointed by the virtual function table pointer of the base class in the process address space and the initial address space position of the virtual function table data in the process address space;

and determining the target memory position pointed by the virtual function table pointer of each base class in the designated area 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 an address offset of a VIEW table pointer of one or more base classes of the target object comprises:

acquiring a virtual function table pointer of each base class; the first 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 of the base class is the address space position in the process address space;

and performing subtraction operation on the first pointer address of the virtual function table pointer of each base class and 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 obtaining the vtable pointer for each base class comprises:

obtaining 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;

7. The method of claim 4, wherein determining a target memory location pointed to in the designated region for the vtable pointer of each base class based on an address offset of the vtable pointer of the one or more base classes and a memory address of the vtable data in the shared memory comprises:

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 according to claim 1 or 4, wherein the virtual function table data corresponding to the target process is obtained from the process address space of the target process; copying the acquired virtual function table data to a specified 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; and in the process address space, the data between the starting address and the ending address is the 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 segment in the process address space whose address in the process address space is determined by a program loader; when the read-only reentrant segment only contains virtual function table data of the target object, the acquiring a start address and an end address of the virtual function table data in a process address space of the target process includes:

generating a target link script based on the first address variable and the second address variable, and adding the target link script to a default script to obtain an added 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. The method of claim 1 or 4, wherein the virtual function table data of the target object is stored in a read-only reentrant segment in the process address space of the 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 contain the virtual function table data of the target object, acquiring the virtual function table data corresponding to the target process from the process address space of the target process; copying the acquired virtual function table data to a designated area in the shared memory, including:

acquiring one or more virtual function table data in the read-only reentrant section from the process address space of the target process;

11. A memory processing apparatus, comprising:

the processing unit is used for determining a designated area in the shared memory after communication connection is reestablished between a target process and the shared memory, wherein the designated area is used for storing virtual function table data corresponding to the target process; non-POD type data are stored in the shared memory, the non-POD type data comprise a virtual function table pointer corresponding to the target process, and the virtual function table pointer is preset to point to the designated area;

the processing unit is further configured to copy the acquired virtual function table data to the designated area in the shared memory, so that the target process calls a virtual function required by the target process to run from the virtual function table data stored in the designated area through the virtual function table pointer.

12. A computer device, comprising:

a processor adapted to execute a computer program;

computer-readable storage medium, in which a computer program is stored which, when being executed by the processor, carries out the memory processing method according to any one of claims 1 to 10.

13. A computer-readable storage medium, characterized in that it stores a computer program adapted to be loaded by a processor and to execute the memory processing method according to any of claims 1-10.