A method, system, device and storage medium for handling wild pointers

Abstract

Embodiments of the present application disclose a wild pointer processing method, system, device and storage medium. According to the type information of each memory object, the technical solution provided by the embodiments of the present application determines the memory object of a specified type as a target memory object; then in the case of releasing the target memory object, a target zombie object is created, the instruction set architecture pointer of the target memory object is modified, and the instruction set architecture pointer is pointed to the target zombie object; and then the target zombie object is saved to the application memory, so that when the calling party uses the instruction set architecture pointer to call the target memory object, the calling party is intercepted based on the target zombie object through a message forwarding mechanism, and the calling logic is processed. By using the above technical means, the wild pointer processing of the online running environment of the application program can be realized, the application program can be prevented from crashing, the running effect of the application program is optimized, and the user experience is improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system, device and storage medium for handling wild pointers. Background Technology

[0002] When various computational units within an application run on the terminal, they typically allocate memory to store variables and other data. After use, this allocated memory is released. If, during the use of allocated memory, the corresponding memory is released and then re-accessed, it can cause the program to crash when accessing the released memory. This type of problem is commonly known as the dangling pointer problem. Currently, dangling pointers can only be prevented in offline development environments. These environments provide mechanisms to handle dangling pointers, ensuring that memory objects requiring dangling pointer protection are not released even when no pointers are pointing to them, thus resolving dangling pointer crashes that occur during application development.

[0003] However, existing dangling pointer handling mechanisms are only suitable for offline testing scenarios. When applications are deployed online, the operating system's memory management mechanism limits memory consumption and releases unused memory objects promptly to improve system memory resource utilization. Continuing to use the dangling pointer handling mechanism from offline testing scenarios would negatively impact system memory management. Furthermore, in online environments lacking a corresponding dangling pointer handling mechanism, dangling pointer issues can lead to application crashes, freezes, and other runtime malfunctions, ultimately affecting the user experience. Summary of the Invention

[0004] This application provides a method, system, device, and storage medium for handling wild pointers, which can prevent memory objects from crashing due to wild pointers, avoid application crashes, and solve the problem of wild pointer crashes in the online operating environment of applications.

[0005] In a first aspect, embodiments of this application provide a method for handling wild pointers, including:

[0006] Based on the type information of each memory object, the memory object of the specified type is determined as the target memory object;

[0007] If the target memory object is released, a target zombie object is created, and the instruction set architecture pointer of the target memory object is modified so that the instruction set architecture pointer points to the target zombie object.

[0008] The target zombie object is saved to the application memory so that when the caller uses the instruction set architecture pointer to call the target memory object, the caller can be intercepted through the message forwarding mechanism based on the target zombie object, and the call logic can be processed.

[0009] In a second aspect, embodiments of this application provide a wild pointer processing system, comprising:

[0010] The module is configured to determine the target memory object based on the type information of each memory object;

[0011] Create a module configured to create a target zombie object when the target memory object is released, and modify the instruction set architecture pointer of the target memory object to point to the target zombie object;

[0012] The save module is configured to save the target zombie object to the application memory so that when the caller uses the instruction set architecture pointer to call the target memory object, the caller can be intercepted through the message forwarding mechanism based on the target zombie object, and the call logic can be processed.

[0013] In a third aspect, embodiments of this application provide a wild pointer processing device, comprising:

[0014] Memory and one or more processors;

[0015] The memory is configured to store one or more programs;

[0016] When the one or more programs are executed by the one or more processors, the one or more processors implement the wild pointer handling method as described in the first aspect.

[0017] In a fourth aspect, embodiments of this application provide a storage medium containing computer-executable instructions configured, when executed by a computer processor, to perform the wild pointer handling method as described in the first aspect.

[0018] In a fifth aspect, embodiments of this application provide a computer program product containing instructions that, when executed on a computer or processor, cause the computer or processor to perform the wild pointer handling method described in the first aspect.

[0019] This application embodiment determines a specified type of memory object as the target memory object based on the type information of each memory object. Then, upon releasing the target memory object, a target zombie object is created, and the instruction set architecture pointer of the target memory object is modified to point to the target zombie object. The target zombie object is then saved to the application memory. When a caller uses the instruction set architecture pointer to access the target memory object, the caller is intercepted via a message forwarding mechanism based on the target zombie object, and the call logic is processed. By employing the above technical means, creating a target zombie object in the application memory, pointing the instruction set architecture pointer to the target zombie object, and handling the application's dangling pointer problem based on a message forwarding mechanism, dangling pointer handling in the application's online runtime environment can be achieved, preventing application crashes, optimizing application performance, and improving the user experience. Attached Figure Description

[0020] Figure 1 This is a flowchart of a wild pointer handling method provided in an embodiment of this application;

[0021] Figure 2 This is a flowchart illustrating the process of creating a memory object in an embodiment of this application;

[0022] Figure 3 This is a flowchart illustrating the process of releasing memory objects in an embodiment of this application;

[0023] Figure 4 This is a flowchart of the application memory management process in an embodiment of this application;

[0024] Figure 5 This is a schematic diagram of the structure of a wild pointer processing system provided in an embodiment of this application;

[0025] Figure 6 This is a schematic diagram of the structure of a wild pointer processing device provided in an embodiment of this application. Detailed Implementation

[0026] To make the objectives, technical solutions, and advantages of this application clearer, specific embodiments of this application will be described in further detail below with reference to the accompanying drawings. It should be understood that the specific embodiments described herein are merely for explaining this application and not for limiting it. It should also be noted that, for ease of description, only the parts relevant to this application are shown in the drawings, not all of them. Before discussing exemplary embodiments in more detail, it should be mentioned that some exemplary embodiments are described as processes or methods depicted as flowcharts. Although the flowcharts describe operations (or steps) as sequential processes, many of these operations can be performed in parallel, concurrently, or simultaneously. Furthermore, the order of the operations can be rearranged. The process can be terminated when its operation is completed, but may also have additional steps not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0027] The dangling pointer handling method provided in this application aims to prevent application crashes during online deployment and optimize user experience by creating a target zombie object in application memory, pointing the instruction set architecture pointer to the target zombie object, and handling the dangling pointer problem based on a message forwarding mechanism. This is in contrast to traditional dangling pointer handling mechanisms, which are typically used in offline testing scenarios. Because memory consumption is less restricted in offline testing scenarios, memory objects that are not pointed to by pointers after a call can remain stored in memory without being released. This prevents dangling pointer issues when the pointer calls the memory object, thus achieving dangling pointer protection. However, when the application is deployed online, the operating system's memory management mechanism limits memory consumption and releases unused memory objects promptly to improve system memory resource utilization. In this case, the dangling pointer handling mechanism used in offline testing scenarios cannot be used. Without a corresponding dangling pointer handling mechanism, dangling pointer problems can lead to application crashes and other operational failures, thus affecting user experience. Therefore, this application provides a dangling pointer handling method to solve the dangling pointer crash problem in the online operating environment of applications.

[0028] Example:

[0029] Figure 1 A flowchart of a wild pointer processing method provided in an embodiment of this application is given. The wild pointer processing method provided in this embodiment can be executed by a wild pointer processing device, which can be implemented by software and / or hardware. The wild pointer processing device can be composed of two or more physical entities, or it can be composed of a single physical entity. Generally, the wild pointer processing device can be a terminal device running an application such as a computer, mobile phone, or tablet.

[0030] The following description uses the wild pointer processing device as an example to illustrate the wild pointer processing method. (Refer to...) Figure 1 The specific methods for handling wild pointers include:

[0031] S110. Based on the type information of each memory object, determine the memory object of the specified type as the target memory object.

[0032] In handling the dangling pointer problem, this embodiment creates a zombie object of the memory object and uses it to receive all call information of the memory object. By intercepting this call information and then reporting the pointer based on a message forwarding mechanism, relevant processing logic is used to handle the call logic of the zombie object. This achieves the handling of dangling pointers and avoids the problem of system pointers failing to find memory objects, which leads to dangling pointer crashes.

[0033] As is understandable, a zombie object is an object used to detect memory errors (EXC_BAD_ACCESS). It can capture any calls that attempt to access bad memory. When a message is sent to a zombie object, it outputs an error log, which can be used to locate the method and class name called by the dangling pointer object. Furthermore, through a message forwarding mechanism, the zombie object can report the caller and handle the call according to pre-defined processing logic, thus resolving the dangling pointer issue.

[0034] Specifically, before proceeding, it is necessary to determine which memory objects in the system require dangling pointer protection, and to create corresponding zombie objects for these memory objects. These memory objects requiring dangling pointer protection are defined as target memory objects. Correspondingly, the zombie objects created from these target memory objects are called target zombie objects.

[0035] In this embodiment, the memory object requiring dangling pointer protection is selected based on its type information, and thus determined as the target memory object. When determining whether a memory object needs dangling pointer protection, this embodiment triggers a judgment process at two points: during memory object creation and memory object release, to identify the corresponding target memory object.

[0036] The process for determining the target memory object in the case of creating a memory object includes:

[0037] S1101. When creating a memory object, determine the type information of the current memory object and determine whether the type information of the current memory object is the specified type information;

[0038] S1102. If the type information of the current memory object is the specified type information, determine the current memory object as the target memory object.

[0039] Reference Figure 2This application provides a flowchart of the process for creating memory objects (a1-a4). In this embodiment, a hook function is used to obtain the original memory object creation methods (allocwithzone) of all base classes (nsobject) in the system, marking memory objects requiring wild pointer protection as target memory objects. The hook function captures the call message of the corresponding object before the system calls it. The hook function gains control of the object, allowing it to modify the execution behavior of the call message or forcibly terminate message delivery. In other words, the hook function can extract the system's program and modify it into the code snippet required for the corresponding scenario.

[0040] After obtaining the original memory object creation method (allocwithzone) based on the hook function, this application modifies the obtained memory object creation method through the hook function, so that when creating a memory object, it marks a memory object of a specified type as the target memory object. Based on the modified memory object creation method, when creating a memory object, it first determines whether the type information of the current memory object is the specified type. If the type information of the current memory object is the specified type, this memory object is marked as the target memory object for dangling pointer protection. Otherwise, the original memory object creation method is used for memory object creation.

[0041] It should be noted that for frequently created and released memory objects (such as NSString and UIView), these memory objects are added to the dangling pointer protection list. This is to prevent subsequently created zombie objects from consuming excessive memory, affecting system memory management. Furthermore, because these memory objects are created frequently, there is a small chance of dangling pointer issues. Therefore, this embodiment marks these types of memory objects as target memory objects. Based on this, by setting the specified type information that requires dangling pointer protection, the appropriate type of memory object can be adaptively selected for dangling pointer protection.

[0042] On the other hand, the process for determining the target memory object in the case of releasing a memory object includes:

[0043] S1103. When releasing a memory object, determine whether the current memory object is in the pre-built object list;

[0044] S1104. If the current memory object is not in the object list, determine the current memory object as the target memory object.

[0045] Reference Figure 3This application provides a flowchart of the process when creating memory objects (b1-b9). Similarly, this embodiment uses a hook function to obtain the original memory object release methods (dealloc) of all base classes (nsobject) in the system, marking memory objects requiring wild pointer protection as target memory objects.

[0046] When releasing memory objects, this embodiment constructs an object list, which serves as a blacklist for dangling pointer protection. This object list also includes memory objects that are frequently created and released. Furthermore, certain specific memory objects that cannot have zombie objects added to them (such as NSBundle) are also added to the object list. Based on this object list, if a memory object is determined to be on the list, the original memory object release method is used. Otherwise, dangling pointer protection is applied to these memory objects.

[0047] Optionally, since some memory objects of a specified type are frequently created and released at specific time points, and these memory objects of a specified type are marked as target memory objects when they are created. However, because these memory objects are frequently created and released at specific time points, they will be added to the object list and do not need to be protected against dangling pointers. Therefore, this embodiment of the application improves the accuracy of the dangling pointer method by filtering memory objects based on the object list when releasing memory objects, and avoids some memory objects that are not suitable for dangling pointer protection being marked as target memory objects. The object list can be filtered according to the creation and release frequency of memory objects within a set time period. The object list is set according to the actual dangling pointer protection requirements and is not subject to any fixed restrictions here.

[0048] S120. If the target memory object is released, create a target zombie object, modify the instruction set architecture pointer of the target memory object, and point the instruction set architecture pointer to the target zombie object.

[0049] Furthermore, based on the target memory object determined in step S110 above, in the case of releasing the target memory object, this embodiment of the application will create a corresponding target zombie object for a portion of the target memory object, so as to protect the target memory object from wild pointers through the target zombie object.

[0050] like Figure 3 As shown, when releasing a target memory object and creating a target zombie object, it is necessary to modify the instruction set architecture pointer of the target memory object so that it points to the target zombie object. Specifically, the wild pointer handling device processes the target memory object by calling the object release logic, deleting the associated information of the target memory object to perform the target memory object release operation.

[0051] Specifically, when performing the deallocation operation on the target memory object, the dangling pointer handling device releases the attributes referenced by the target memory object by calling the pre-destruct method (objc_destructInstance), and then modifies the instruction set architecture pointer (isa pointer) of the target memory object to the target zombie object currently created by the instruction set architecture pointer. This allows all subsequent call information for the target memory object to be sent to the target zombie object, thereby utilizing the target zombie object to process the call logic and avoiding dangling pointer crashes.

[0052] Specifically, the pre-destruct method (objc_destructInstance) for memory object release is called. This pre-destruct method is used to clear the associated information of the target memory object, such as clearing associated objects, clearing weak references, and clearing the reference counting table. When the memory object release method (dealloc) is executed, the pre-destruct method (objc_destructInstance) is called through a function call (objc_dispose) to delete the associated information of the target memory object.

[0053] The memory object deallocation method executes different memory object deallocation logic based on different object types. For certain memory objects (such as NONPointer_ISA, Weakly_reference, Has_assoc, Has_cxx_dtor, and Has_sidetable_rc), it calls the pre-destruction method (objc_destructInstance) of the memory object through the function (objc_dispose), and then calls the C function free(). When the pre-destruction method (objc_destructInstance) of the memory object runs, it first checks whether the memory object has any C++ related content. If so, it calls the variable deallocation function object_cxxDestruct() to destroy the C++ related content. Then it checks whether the target memory object has any associated objects. If so, it destroys the associated objects. Finally, it calls the pointer handling function clearDeallocating() to set the weak reference pointer pointing to the target memory object to nil and erase the reference count of the target object from the reference counting table, thus completing the deallocation of the target memory object. If the target memory object is a taggedPointer (a special type of object that is created as a pointer, not pointing to a memory location; the pointer stores the object's value), then it is returned directly. For other memory objects, simply release them by calling the free function.

[0054] After deleting the associated information of the target memory object, this embodiment creates a target zombie object by calling class creation logic based on a dynamic mechanism, and configures hook functions for the specified information received by the target zombie object. First, the instruction set architecture pointer (isa pointer) of the target memory object is set to point to the target zombie object, enabling the target zombie object to accept arbitrary method calls. Then, the name of the target memory object is used as the name prefix of the zombie object. Based on the name prefix and the set suffix information, the class name of the zombie object is created. The corresponding target zombie object is created using the system's object creation method (objc_allocateClassPair), and the class of the target zombie object is dynamically registered. At this point, the creation of the target zombie object is complete.

[0055] S130. Save the target zombie object to the application memory so that when the caller uses the instruction set architecture pointer to call the target memory object, the caller can be intercepted through the message forwarding mechanism based on the target zombie object, and the call logic can be processed.

[0056] Furthermore, for the target zombie object that has been created, this embodiment of the application saves it to the application memory and performs memory management on the zombie object in the application memory in real time. Specifically, before saving the target zombie object to the application memory, a corresponding management process needs to be executed on the application memory to ensure that the application memory space is sufficient to meet the storage requirements of the target zombie object.

[0057] Reference Figure 4 The application memory management process includes:

[0058] S1301. Determine the first memory usage data of the target zombie object, and based on the first memory usage data, determine whether the storage amount of the application memory exceeds the first set memory threshold after storing the target zombie object.

[0059] S1302. After determining the target zombie object to be stored, if the amount of storage in the application memory exceeds the first set memory threshold, select and delete the stored zombie object from the application memory.

[0060] The wild pointer processing device first determines the memory usage information of the current target zombie object, defining this memory usage information as the first memory usage data. It is understandable that if the application memory storage exceeds a limit after adding this first memory usage data to the current application memory, then the application memory space needs to be cleaned up. Based on this, a memory threshold is set and defined as the first memory threshold. If the storage volume reaches the first set memory threshold after adding the first memory usage data of the target zombie object to the application memory, then the stored zombie objects need to be selected and deleted from the application memory. Generally, a portion of zombie objects can be randomly selected for deletion, or zombie objects can be adaptively selected for deletion based on relevant algorithms. This application embodiment does not impose fixed limitations on the specific zombie object selection and deletion method, and will not elaborate further here.

[0061] After saving the target zombie object, the instruction set architecture pointer (isa pointer) of the target memory object is modified in advance. Therefore, when the system sends messages to the target memory object subsequently, it will look for the class pointed to by the instruction set architecture pointer (isa pointer). These messages will then be sent to the target zombie object, and the caller of these messages can be intercepted through the message forwarding mechanism, and the call logic can be processed according to the pre-defined processing logic. This avoids application crashes, and by reporting to the caller, the system can also locate the code causing the dangling pointer, thus implementing the dangling pointer handling method of this application embodiment.

[0062] Optionally, the wild pointer processing device will also accumulate the amount of application memory stored in real time, and when the amount of application memory stored reaches a second set memory threshold, select and delete the stored zombie objects from the application memory based on the least recently used algorithm.

[0063] After a target zombie object is created, it is stored in the application memory for a period of time. However, the system's memory management mechanism will terminate the application process occupying excessive memory if application memory consumption becomes too high. Therefore, it is necessary to periodically clean up zombie objects in the application memory to avoid excessive application memory consumption. This application embodiment establishes a threshold for the amount of application memory stored, defining it as a second set memory threshold. When the amount of application memory stored reaches the second set memory threshold, the stored zombie objects are selected and deleted from the application memory based on the Least Recently Used (LRU) algorithm. The Least Recently Used (LRU) algorithm adaptively selects zombie objects for deletion based on the call history of each zombie object within a set time period, thereby completing the management of application memory, optimizing the storage and management of zombie objects, avoiding application process termination due to excessive application memory consumption, and optimizing the application's running performance.

[0064] It should be noted that the first and second memory thresholds can be set adaptively according to the memory space of the wild pointer processing device. Generally speaking, the larger the memory space of the wild pointer processing device, the larger the memory threshold can be set.

[0065] As described above, based on the type information of each memory object, a memory object of a specified type is identified as the target memory object. Then, upon releasing the target memory object, a target zombie object is created, and the instruction set architecture pointer of the target memory object is modified to point to the target zombie object. The target zombie object is then saved to the application's memory. When a caller uses the instruction set architecture pointer to access the target memory object, the caller is intercepted via a message forwarding mechanism based on the target zombie object, and the call logic is processed. By employing this technique, creating a target zombie object in the application's memory, pointing the instruction set architecture pointer to the target zombie object, and handling the application's dangling pointer problem based on a message forwarding mechanism, dangling pointer handling can be achieved in the application's online runtime environment. This prevents application crashes, optimizes application performance, and improves the user experience.

[0066] Based on the above embodiments, Figure 5 This is a schematic diagram of a wild pointer processing system provided in this application. (Reference) Figure 5 The wild pointer processing system provided in this embodiment specifically includes: a determination module 21, a creation module 22, and a saving module 23.

[0067] The determination module 21 is configured to determine the target memory object of a specified type based on the type information of each memory object.

[0068] Module 22 is configured to create a target zombie object when the target memory object is released, and modify the instruction set architecture pointer of the target memory object to point to the target zombie object.

[0069] The storage module 23 is configured to save the target zombie object to the application memory so that when the caller uses the instruction set architecture pointer to call the target memory object, the caller can be intercepted through the message forwarding mechanism based on the target zombie object, and the call logic can be processed.

[0070] Specifically, module 21 is configured as follows: when creating a memory object, determine the type information of the current memory object and determine whether the type information of the current memory object is the specified type information; when the type information of the current memory object is the specified type information, determine that the current memory object is the target memory object; when releasing a memory object, determine whether the current memory object is in the pre-built object list; when the current memory object is not in the object list, determine that the current memory object is the target memory object.

[0071] Specifically, module 22 is configured to invoke object release logic to process the target memory object, delete the associated information of the target memory object, invoke class creation logic based on dynamic mechanism to create the target zombie object, and configure hook functions for the specified information received by the target zombie object. The name of the target memory object is used as the name prefix of the target zombie object, and the class name of the target zombie object is created based on the name prefix and the set suffix information.

[0072] Specifically, the storage module is configured to determine the first memory usage data of the target zombie object, and based on the first memory usage data, determine whether the application memory storage amount exceeds a first set memory threshold after storing the target zombie object. If the application memory storage amount exceeds the first set memory threshold after determining the target zombie object, the stored zombie object is selected and deleted from the application memory. Furthermore, the application memory storage amount is accumulated in real time, and if the application memory storage amount reaches a second set memory threshold, the stored zombie object is selected and deleted from the application memory based on the Least Recently Used algorithm.

[0073] As described above, based on the type information of each memory object, a memory object of a specified type is identified as the target memory object. Then, upon releasing the target memory object, a target zombie object is created, and the instruction set architecture pointer of the target memory object is modified to point to the target zombie object. The target zombie object is then saved to the application's memory. When a caller uses the instruction set architecture pointer to access the target memory object, the caller is intercepted via a message forwarding mechanism based on the target zombie object, and the call logic is processed. By employing this technique, creating a target zombie object in the application's memory, pointing the instruction set architecture pointer to the target zombie object, and handling the application's dangling pointer problem based on a message forwarding mechanism, dangling pointer handling can be achieved in the application's online runtime environment. This prevents application crashes, optimizes application performance, and improves the user experience.

[0074] The wild pointer processing system provided in this application embodiment can be configured to execute the wild pointer processing method provided in the above embodiment, and has corresponding functions and beneficial effects.

[0075] Based on the above practical examples, this application also provides a wild pointer processing device, referring to... Figure 6The wild pointer processing device includes a processor 31, a memory 32, a communication module 33, an input device 34, and an output device 35. The memory 32, as a computer-readable storage medium, can be configured to store software programs, computer-executable programs, and modules, such as program instructions / modules corresponding to the wild pointer processing method described in any embodiment of this application (e.g., a determination module, a creation module, and a saving module in a wild pointer processing system). The communication module 33 is configured to perform data transmission. The processor 31 executes various functional applications and data processing of the device by running the software programs, instructions, and modules stored in the memory, thereby implementing the aforementioned wild pointer processing method. The input device 34 can be configured to receive input digital or character information and generate key signal inputs related to user settings and function control of the device. The output device 35 may include a display screen or other display device. The wild pointer processing device provided above can be configured to execute the wild pointer processing method provided in the above embodiments, possessing corresponding functions and beneficial effects.

[0076] Based on the above embodiments, this application also provides a storage medium containing computer-executable instructions. When executed by a computer processor, the computer-executable instructions are configured to perform a wild pointer handling method. The storage medium can be any type of memory device or storage device. Of course, the computer-executable instructions provided in this application are not limited to the wild pointer handling method described above; they can also execute related operations in the wild pointer handling method provided in any embodiment of this application.

[0077] Based on the above embodiments, this application also provides a computer program product. The technical solution of this application, in essence or in other words, the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. The computer program product is stored in a storage medium and includes several instructions to cause a computer device, mobile terminal, or processor therein to execute all or part of the steps of the wild pointer processing method described in the various embodiments of this application.

Claims

1. A method for handling wild pointers, the method comprising: The method comprises the following steps: In the case of creating a memory object, determining the type information of the current memory object, and judging whether the type information of the current memory object is the specified type information; In the case that the type information of the current memory object is the specified type information, determining that the current memory object is a target memory object; In the case of releasing a memory object, judging whether the current memory object is in a pre-constructed object list; In the case that the current memory object is not in the object list, determining that the current memory object is the target memory object; In the case of releasing the target memory object, creating a target zombie object, calling object release logic to process the target memory object, deleting the associated information of the target memory object, modifying the instruction set architecture pointer of the target memory object, and pointing the instruction set architecture pointer to the target zombie object; Determining the first memory occupation data of the target zombie object, and judging whether the storage amount of the application memory exceeds the first set memory threshold after storing the target zombie object based on the first memory occupation data; In the case that the storage amount of the application memory exceeds the first set memory threshold after determining to store the target zombie object, selecting and deleting the stored zombie object from the application memory; saving the target zombie object to the application memory, so that when the calling party uses the instruction set architecture pointer to call the target memory object, the calling party is intercepted based on the target zombie object through a message forwarding mechanism and the calling logic is processed.

2. The wild pointer handling method of claim 1, wherein, The method comprises the following steps: Calling the class creation logic based on the dynamic mechanism to create the target zombie object, and configuring a hook function for the specified information received by the target zombie object.

3. The wild pointer handling method of claim 2, wherein, The method comprises the following steps: Using the name of the target memory object as the name prefix of the target zombie object, and creating the class name of the target zombie object based on the name prefix and the set suffix information.

4. The wild pointer handling method of claim 1, wherein, After saving the target zombie object to the application memory, the method further comprises the following steps: Accumulating the storage amount of the application memory in real time, and in the case that the storage amount of the application memory reaches the second set memory threshold, selecting and deleting the stored zombie object from the application memory based on the least recently used algorithm.

5. A wild pointer handling system characterized by The method comprises the following steps: A determining module is configured to, in the case of creating a memory object, determine the type information of the current memory object, and judge whether the type information of the current memory object is the specified type information; In the case that the type information of the current memory object is the specified type information, determining that the current memory object is a target memory object; In the case of releasing a memory object, judging whether the current memory object is in a pre-constructed object list; In the case that the current memory object is not in the object list, determining that the current memory object is the target memory object; A creating module is configured to, in the case of releasing the target memory object, create a target zombie object, call object release logic to process the target memory object, delete the associated information of the target memory object, modify the instruction set architecture pointer of the target memory object, and point the instruction set architecture pointer to the target zombie object; The saving module is configured to determine first memory occupation data of the target zombie object, and determine whether a storage amount of the application memory exceeds a first set memory threshold based on the first memory occupation data after the target zombie object is stored. In a case where the storage amount of the application memory exceeds the first set memory threshold after the target zombie object is determined to be stored, a stored zombie object is selected to be deleted from the application memory; and the target zombie object is saved to the application memory, so that the calling party is intercepted based on the target zombie object through a message forwarding mechanism and the calling logic is processed when the calling party uses the instruction set architecture pointer to call the target memory object.

6. A wild pointer handling device characterized by Comprise: a memory and one or more processors; the memory is configured to store one or more programs; when the one or more programs are executed by the one or more processors, the one or more processors implement the wild pointer processing method as claimed in any one of claims 1-4.

7. A storage medium containing computer-executable instructions, wherein: The computer executable instructions are configured to execute the wild pointer processing method as claimed in any one of claims 1-4 when executed by a computer processor.

8. A computer program product, characterised in that, The computer program product contains instructions, which, when executed on a computer or processor, cause the computer or processor to execute the wild pointer processing method as claimed in any one of claims 1-4.

Images