Method and apparatus for processing memory leak in vehicle-mounted terminal, device, and medium

Abstract

A method and apparatus for processing a memory leak in a vehicle-mounted terminal, a device, and a medium. The method comprises: during operation of a vehicle-mounted terminal system, if a kernel-mode memory leak is detected in the vehicle-mounted terminal system, determining whether a memory leak rate and a memory leak amount satisfy a preset leak condition; if the preset leak condition is satisfied, enabling a kernel-mode memory debugging node, restarting the vehicle-mounted terminal system, and then capturing process information by means of a probe embedded into a kernel-mode memory allocation call stack; and tracking an abnormal application process on the basis of the process information, printing the process information in a kernel-mode page allocation log, disabling the kernel-mode memory debugging node, and restarting the vehicle-mounted terminal system.

Description

Methods, devices, equipment and media for handling memory leaks in vehicle-mounted terminals

[0001] Citation of relevant applications

[0002] This disclosure claims the entire benefits of Chinese Patent Application No. 202411834747.7, filed on December 12, 2024 with the State Intellectual Property Office of the People's Republic of China, entitled "A Method, Apparatus, Device and Medium for Handling Memory Leakage in a Vehicle Terminal", the entire contents of which are incorporated herein by reference.

[0003] field

[0004] This disclosure generally relates to the field of vehicle testing technology, and more specifically to methods, apparatus, equipment and media for handling memory leaks in vehicle terminals.

[0005] background

[0006] During real vehicle road tests and early mass production, the vehicle terminal (TBOX, Telematics Box) frequently reports system memory leaks. Such problems require the addition of a memory leak localization mechanism in the software and long-term log capture. Keeping the memory debugging mechanism running for a long time will consume system memory and CPU (Central Processing Unit) resources, affecting the system performance of the TBOX.

[0007] For system performance reasons, later mass-production software versions will omit memory debugging tools. If a memory leak occurs in TBOX, it is often necessary to add targeted debugging mechanisms based on the initial analysis results, recompile the version, and conduct extensive retesting. This consumes a lot of time and manpower, affecting debugging efficiency and project progress. If the kernel-level memory leak is caused by an application process, it is often necessary to work with the customer to investigate, using a reverse investigation approach by shutting down the application process, and continuously compiling and verifying the version, which is inefficient.

[0008] Overview

[0009] Firstly, this disclosure provides a method for handling memory leaks in vehicle-mounted terminals, which includes:

[0010] During the operation of the vehicle terminal system, if a kernel-mode memory leak is detected in the vehicle terminal system, it is determined whether the memory leak rate and memory leak amount meet the preset leak conditions.

[0011] If the preset leakage conditions are met, the kernel-mode memory debugging node is opened, and the vehicle terminal system is restarted. Then, process information is captured by requesting a probe in the call stack from the kernel-mode memory; and

[0012] The abnormal application process is tracked based on the process information, and the process information is printed in the kernel-mode page request log. The kernel-mode memory debugging node is then closed and the vehicle terminal system is restarted.

[0013] In some implementations, determining whether the memory leak rate and memory leak amount meet preset leak conditions includes:

[0014] Determine whether the time difference between the vehicle's power-on time and the current time is less than a preset time difference, and determine whether the memory difference between the initial available memory and the current available memory is greater than a preset memory threshold;

[0015] If the time difference between the vehicle power-on time and the current time is less than the preset time difference, and the memory difference between the initial available memory and the current available memory is greater than the preset memory threshold, then the memory leak rate and memory leak amount are determined to meet the preset leak conditions.

[0016] In some implementations, after determining whether the memory leak rate and memory leak amount meet the preset leak conditions, the method further includes:

[0017] If the memory leak rate and memory leak amount do not meet the preset leak conditions, then the kernel-mode memory debug node is disabled, and the vehicle terminal system is restarted through a timed restart operation.

[0018] In some implementations, opening the kernel-mode memory debug node includes:

[0019] The startup loader is determined, and the memory debugging command corresponding to the kernel mode is determined. Then, the startup command sequence variable is modified based on the memory debugging command to open the kernel mode memory debugging node.

[0020] In some implementations, the kernel-mode memory allocation call stack includes a call stack related to network data, a call stack related to serial port data, and a call stack related to GPS data.

[0021] In some implementation schemes, during the operation of the vehicle-mounted terminal system, the following is also included:

[0022] The graphical interface displays the memory usage of each application process and the impact of each application process on kernel memory, and updates the content of the graphical interface at preset intervals.

[0023] In some implementations, the process information includes a process sequence number and a process name.

[0024] Secondly, this disclosure provides an in-vehicle terminal memory leak handling device, which includes:

[0025] The leakage detection module is configured to, during the operation of the vehicle terminal system, if a kernel-mode memory leak is detected in the vehicle terminal system, determine whether the memory leak rate and memory leak amount meet the preset leakage conditions.

[0026] The process information capture module is configured to, if the preset leakage conditions are met, open the kernel-mode memory debugging node, restart the vehicle terminal system, and then capture process information by requesting a probe in the call stack embedded in the kernel-mode memory; and

[0027] The abnormal process location module is configured to track abnormal application processes based on the process information, print the process information in the kernel-mode page request log, close the kernel-mode memory debugging node, and restart the vehicle terminal system.

[0028] Thirdly, this disclosure provides electronic devices, including:

[0029] Memory, configured to store computer programs;

[0030] A processor configured to execute the computer program to implement the vehicle terminal memory leak handling method described in this disclosure.

[0031] Fourthly, this disclosure provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the vehicle terminal memory leak handling method described in this disclosure.

[0032] In some implementations, the kernel-mode memory debug node is only opened when a kernel-mode memory leak is detected in the vehicle terminal system, and the leak rate and amount meet preset leak conditions. This avoids the consumption of system memory and CPU resources by keeping the kernel-mode memory debug node open for extended periods, thus preventing impact on the vehicle terminal's system performance. In other implementations, process information is captured by embedding probes in the kernel-mode memory request call stack, and abnormal application processes are directly traced based on this information. This eliminates the need for joint investigation with the customer and lengthy retesting of recompiled versions, saving significant time and manpower and improving debugging efficiency.

[0033] Brief description of the attached figures

[0034] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only embodiments of this disclosure. For those skilled in the art, other drawings can be obtained based on the provided drawings without creative effort.

[0035] Figure 1 is a flowchart of a vehicle terminal memory leak handling method according to an embodiment of the present disclosure;

[0036] Figure 2 is a flowchart of a vehicle terminal memory leak handling method according to an embodiment of the present disclosure;

[0037] Figure 3 is a schematic diagram of the structure of a vehicle-mounted terminal memory leak handling device according to an embodiment of the present disclosure; and

[0038] Figure 4 is a structural diagram of an electronic device according to an embodiment of the present disclosure.

[0039] Detailed Explanation

[0040] The technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this disclosure, and not all embodiments. Based on the embodiments of this disclosure, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the scope of protection of this disclosure.

[0041] For system performance reasons, later mass-production software versions will omit memory debugging tools. If a memory leak occurs in the vehicle terminal, it is often necessary to add targeted debugging mechanisms based on the initial analysis results, recompile the version, and conduct long-term retesting. This consumes a lot of time and manpower, affecting debugging efficiency and project progress. If the kernel-level memory leak is caused by the application process, it is often necessary to work with the customer to investigate and continuously compile the version for verification, which is inefficient.

[0042] Therefore, one embodiment of this disclosure provides a method for handling memory leaks in vehicle terminals, as shown in Figure 1, including:

[0043] Step S11: During the operation of the vehicle terminal system, if a kernel-mode memory leak is detected in the vehicle terminal system, determine whether the memory leak rate and memory leak amount meet the preset leak conditions.

[0044] Step S12: If the preset leakage conditions are met, open the kernel-mode memory debugging node, restart the vehicle terminal system, and then capture process information by requesting a probe in the call stack embedded in the kernel-mode memory; and

[0045] Step S13: Track the abnormal application process according to the process information, print the process information in the kernel-mode page request log, close the kernel-mode memory debug node and restart the vehicle terminal system.

[0046] In some implementations, in-vehicle terminal memory leaks include application-level memory leaks and kernel-level memory leaks. Application-level memory leaks refer to situations where, during application execution, due to defects in the program code or improper design, dynamically allocated memory space is not properly released when no longer needed, resulting in memory waste. Kernel-level memory leaks refer to situations within the operating system kernel where memory resources are incorrectly occupied and cannot be properly reclaimed due to driver issues or improper resource management. To address the issue of kernel-level memory leaks, this embodiment uses dynamic opening and closing of kernel-level memory debugging nodes and embedding probes in the kernel-level memory allocation call stack to locate abnormal applications. This solves the problems of low efficiency in locating memory leaks and limited log analysis during real-vehicle road testing and early mass production.

[0047] In some implementations, if a kernel-mode memory leak is detected in the vehicle terminal system, a comprehensive assessment process for the memory leak is initiated to accurately determine whether the memory leak rate and amount meet preset leak conditions. Specifically, firstly, the time difference between the vehicle's power-on time and the current time is calculated; obtaining this time difference is crucial for measuring the speed of the memory leak. Simultaneously, a detailed comparison is made between the initial available memory and the current available memory to obtain the memory difference, which directly reflects the amount of memory leak that has occurred. Further, if the time difference between the vehicle's power-on time and the current time is less than a preset time difference, and the memory difference between the available memory and the current available memory is greater than a preset memory threshold, then the memory leak rate and amount are determined to meet the preset leak conditions. For example, if the initial available memory is 200MB, the current available memory is 50MB, and the time difference between the vehicle's power-on time and the current time does not reach the daily restart time, then the memory leak rate and amount are determined to meet the preset leak conditions.

[0048] In some implementations, if preset leakage conditions are met, a kernel-mode memory debugging node is opened, and the vehicle terminal system is restarted. Then, a probe embedded in the kernel-mode memory request call stack is used to capture process information, including the process sequence number and process name. It should be noted that the specific method for opening the kernel-mode memory debugging node is as follows: determine the bootloader and the corresponding kernel-mode memory debugging command, and then modify the boot command sequence variable based on the memory debugging command to open the kernel-mode memory debugging node.

[0049] To reduce unnecessary performance loss, this embodiment can embed probes in the call stack related to network data, the call stack related to serial port data, and the call stack related to GPS data.

[0050] In some implementations, if the memory leak rate and amount do not meet the preset leak conditions, this embodiment prohibits opening the kernel-mode memory debug node to avoid consuming system memory and CPU resources when the kernel-mode memory debug node is open for an extended period. Instead, the vehicle terminal system is restarted via a timed restart operation. This timed restart operation could be, for example, the daily restart operation of the vehicle terminal system, meaning a restart is performed once a day. This restart method can typically be configured through the vehicle terminal's system settings. This restores the system's memory usage state and ensures stable system operation.

[0051] In some implementations, the abnormal application process is tracked based on the process information, and the process information is printed in the kernel-mode page allocation log. The kernel-mode memory debug node is then shut down, and the vehicle terminal system is restarted. In some implementations, this embodiment prints the process information in the kernel-mode page allocation log, which has detailed timestamps and a clear categorized recording format for easy subsequent tracing and review. In some implementations, the kernel-mode memory debug node is shut down, and the vehicle terminal system is restarted. During the restart, the system can efficiently restore the normal operation of each module. Because the process information is clearly recorded in the log, technicians can directly analyze the anomaly based on the process information in the log. Therefore, there is no need for customer participation in joint troubleshooting, nor is it necessary to recompile complexly or retest for extended periods, greatly improving problem-solving efficiency.

[0052] In some implementations, this embodiment can display the memory usage of each application process and the impact of each application process on kernel-mode memory through a graphical interface, and update the displayed content of the graphical interface at preset intervals. For example, the graphical interface uses intuitive and easy-to-understand charts or data lists to list in detail the memory capacity occupied by each running application process, including key information such as the usage of physical memory and virtual memory. At the same time, the impact of each application process on kernel-mode memory is also accurately presented. For example, how much memory space a certain application process requests in kernel mode for specific data interaction, system calls, and other operations, as well as the changes that the process's operation brings to kernel-mode memory resource allocation and scheduling, can all be clearly shown in the graphical interface. To ensure that the displayed information remains up-to-date and accurate, the system automatically updates the content displayed on the graphical interface at preset time intervals. This preset interval can be flexibly set according to actual monitoring needs and system resources, such as updating every 5 seconds. This allows users to monitor the memory usage of each application process and its dynamic changes in impact on kernel memory in real time. Consequently, when memory-related anomalies occur, users can quickly analyze and troubleshoot problems based on the latest displayed information and take effective countermeasures.

[0053] Figure 2 illustrates the flowchart of the vehicle terminal memory leak handling method. During system operation, if a kernel-level memory leak is detected and the preset leak conditions are met, the system opens a kernel-level memory debugging node via instructions and restarts the vehicle terminal system. Then, it captures process information by embedding probes in the kernel-level memory request call stack and performs statistical analysis to track the processes used by this call stack, synchronously printing the process ID and process name to the log. Furthermore, for application-level memory leaks, abnormal processes can be directly located by capturing process memory information (see ① in Figure 2); for memory leaks caused by the kernel itself, they can be directly located through the debugging node logs (see ②); and for kernel-level memory leaks caused by application processes, the cause of the anomaly can be directly located (see ③). The improvement of this disclosure compared to related technologies lies in optimizing the software using the concept of ftrace (a tracing tool within Linux). It embeds points in the kernel memory request interface to track the called application process information and prints relevant process information. Secondly, it does not directly cut back the debugging mechanism of the software version functionality; instead, it dynamically opens the memory debugging mechanism by passing parameters through bootcmd (a startup command sequence variable). In other words, this disclosure, based on the ideas of dynamic configuration and function stack tracing during Linux system startup, relies on the judgment of memory leak scenarios and captures complete log information when a memory leak occurs. This achieves the function of complete location of memory leak problems in mass production versions, improving the efficiency of locating memory leaks. It is understandable that, to ensure the performance of the vehicle terminal system and the availability of system resources, the memory debugging mechanism is normally disabled. When a memory leak is detected and the leak point occurs in the kernel and meets preset leak conditions, the memory leak debugging node is enabled, and the vehicle terminal system is restarted. Furthermore, this disclosure embeds probes in the code corresponding to the debugging information, enabling the kernel memory allocation part to trace the called application process and print the process's sequence number and name.

[0054] In some implementations, suppose that a kernel-mode driver in the audio processing module of a car's in-vehicle entertainment system has a vulnerability when the vehicle is in sleep mode. When the vehicle enters sleep mode, this driver should release some temporarily occupied kernel-mode memory resources. However, due to a logical error in the code, the memory release operation is not performed correctly during sleep. When the vehicle wakes up and the in-vehicle entertainment system restarts its audio-related functions, this driver will continue to request new kernel-mode memory to process new audio tasks, while the previously unreleased memory remains occupied. With repeated sleep-wake cycles, more and more kernel-mode memory is unnecessarily occupied by this audio processing driver. For example, after the first sleep-wake cycle, the driver occupies an additional 5MB of kernel-mode memory without releasing it; after the second sleep-wake cycle, the cumulative occupation reaches 12MB, and so on. Over time, the available kernel-mode memory gradually decreases, which may eventually lead to slow system operation, resulting in phenomena such as audio playback stuttering, abnormalities in other kernel-mode memory-related functions (such as some security monitoring functions that rely on kernel-mode memory to store temporary data), or even system crashes, seriously affecting the normal use of the vehicle and the driving experience. To address the aforementioned issues, this solution is implemented. Specifically, when the memory leak rate and amount meet preset leak conditions, a kernel-mode memory debugging node is activated, and the in-vehicle entertainment system is restarted. Then, a probe embedded in the kernel-mode memory allocation call stack is used to capture process information. Based on this information, the abnormal application process is traced, and the process information is printed in the kernel-mode page allocation log. Finally, the kernel-mode memory debugging node is closed, and the in-vehicle entertainment system is restarted. In this way, technicians can analyze the abnormal application process based on the process information in the log, eliminating the need for joint investigation with the customer and the need for lengthy re-compilation and retesting, saving significant time and manpower.

[0055] In some implementations, the kernel-mode memory debug node is only opened when a kernel-mode memory leak is detected in the vehicle terminal system, and the leak rate and amount meet preset leak conditions. This avoids the consumption of system memory and CPU resources by keeping the kernel-mode memory debug node open for extended periods, thus preventing impact on the vehicle terminal's system performance. In other implementations, process information is captured by embedding probes in the kernel-mode memory request call stack, and abnormal application processes are directly traced based on this information. This eliminates the need for joint investigation with the customer and lengthy retesting of recompiled versions, saving significant time and manpower and improving debugging efficiency.

[0056] An embodiment of this disclosure also provides a vehicle-mounted terminal memory leak handling device, as shown in Figure 3. The device includes:

[0057] The leakage judgment module 11 is configured to, during the operation of the vehicle terminal system, if a kernel-mode memory leak is detected in the vehicle terminal system, determine whether the memory leak rate and memory leak amount meet the preset leakage conditions.

[0058] The process information capture module 12 is configured to, if the preset leakage conditions are met, open the kernel-mode memory debugging node, restart the vehicle terminal system, and then capture process information by requesting a probe in the call stack embedded in the kernel-mode memory; and

[0059] The abnormal process location module 13 is configured to track abnormal application processes based on the process information, print the process information in the kernel-mode page request log, close the kernel-mode memory debugging node, and restart the vehicle terminal system.

[0060] For more detailed information on the working process of each of the above modules, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0061] In some implementations, the kernel-mode memory debug node is only opened when a kernel-mode memory leak is detected in the vehicle terminal system, and the leak rate and amount meet preset leak conditions. This avoids the consumption of system memory and CPU resources by keeping the kernel-mode memory debug node open for extended periods, thus preventing impact on the vehicle terminal's system performance. In other implementations, process information is captured by embedding probes in the kernel-mode memory request call stack, and abnormal application processes are directly traced based on this information. This eliminates the need for joint investigation with the customer and lengthy retesting of recompiled versions, saving significant time and manpower and improving debugging efficiency.

[0062] This disclosure also provides an electronic device according to one embodiment. FIG4 is a structural diagram of an electronic device 20 according to an exemplary embodiment, and the content of the figure should not be construed as limiting the scope of use of this disclosure.

[0063] Figure 4 is a schematic diagram of the structure of an electronic device 20 provided in an embodiment of this disclosure. The electronic device 20 may include: at least one processor 21, at least one memory 22, a display screen 23, an input / output interface 24, a communication interface 25, a power supply 26, and a communication bus 27. The memory 22 is configured to store a computer program, which is loaded and executed by the processor 21 to implement the vehicle-mounted terminal memory leak handling method described in this disclosure. In some embodiments, the electronic device 20 in this embodiment may specifically be an electronic computer.

[0064] In some implementations, power supply 26 is configured to provide operating voltage to various hardware devices on electronic device 20; communication interface 25 can create a data transmission channel between electronic device 20 and external devices, and the communication protocol it follows can be any communication protocol applicable to the technical solution of this disclosure, and is not specifically limited here; input / output interface 24 is configured to acquire external input data or output data to the outside world, and its specific interface type can be selected according to specific application needs, and is not specifically limited here.

[0065] In some embodiments, the memory 22 serves as a carrier for resource storage and may be a read-only memory, random access memory, disk, or optical disk, etc. The resources stored thereon may include computer programs 221, and the storage method may be temporary storage or permanent storage. In some embodiments, in addition to including computer programs capable of performing the vehicle terminal memory leak handling method executed by the electronic device 20 as described in this disclosure, the computer program 221 may further include computer programs capable of performing other specific tasks.

[0066] An embodiment of this disclosure also provides a computer-readable storage medium for storing a computer program; wherein, when the computer program is executed by a processor, it implements the vehicle terminal memory leak handling method described in this disclosure.

[0067] For the specific steps of this method, please refer to the relevant content disclosed in the foregoing embodiments, which will not be repeated here.

[0068] The various embodiments in this disclosure are described in a progressive manner, with each embodiment focusing on the differences from other embodiments. The same or similar parts between the various embodiments can be referred to each other. As for the apparatus disclosed in the embodiments, since it corresponds to the method disclosed in the embodiments, the description is relatively simple, and the relevant parts can be referred to the method section.

[0069] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this disclosure.

[0070] The steps of the methods or algorithms described in conjunction with the embodiments disclosed herein can be implemented directly by hardware, a software module executed by a processor, or a combination of both. The software module can be located in random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, hard disk, removable disk, CD-ROM, or any other form of storage medium known in the art.

[0071] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or apparatus that includes said element.

[0072] The foregoing has provided a detailed description of the vehicle terminal memory leak handling method, apparatus, device, and storage medium provided in this disclosure. Specific examples have been used to illustrate the principles and implementation methods of this disclosure. The descriptions of the above embodiments are only for the purpose of helping to understand the methods and core ideas of this disclosure. At the same time, for those skilled in the art, there will be changes in the specific implementation methods and application scope based on the ideas of this disclosure. Therefore, the content of this specification should not be construed as a limitation of this disclosure.

Claims

1. A method for handling memory leaks in vehicle-mounted terminals, which includes: During the operation of the vehicle terminal system, if a kernel-mode memory leak is detected in the vehicle terminal system, it is determined whether the memory leak rate and memory leak amount meet the preset leak conditions. If the preset leakage conditions are met, the kernel-mode memory debugging node is opened and the vehicle terminal system is restarted. Then, the process information is captured by the probe in the call stack requested by the kernel-mode memory. as well as The abnormal application process is tracked based on the process information, and the process information is printed in the kernel-mode page request log. The kernel-mode memory debugging node is then closed and the vehicle terminal system is restarted.

2. The method for handling memory leaks in vehicle terminals as described in claim 1, wherein determining whether the memory leak rate and memory leak amount meet preset leak conditions includes: Determine whether the time difference between the vehicle's power-on time and the current time is less than a preset time difference, and determine whether the memory difference between the initial available memory and the current available memory is greater than a preset memory threshold; If the time difference between the vehicle power-on time and the current time is less than the preset time difference, and the memory difference between the initial available memory and the current available memory is greater than the preset memory threshold, then the memory leak rate and memory leak amount are determined to meet the preset leak conditions.

3. The vehicle terminal memory leak handling method as described in claim 1 or 2, wherein after determining whether the memory leak rate and memory leak amount meet the preset leak conditions, it further includes: If the memory leak rate and memory leak amount do not meet the preset leak conditions, then the kernel-mode memory debug node is disabled, and the vehicle terminal system is restarted through a timed restart operation.

4. The method for handling memory leaks in a vehicle terminal as described in any one of claims 1 to 3, wherein opening the kernel-mode memory debugging node includes: The startup loader is determined, and the memory debugging command corresponding to the kernel mode is determined. Then, the startup command sequence variable is modified based on the memory debugging command to open the kernel mode memory debugging node.

5. The vehicle terminal memory leak handling method according to any one of claims 1 to 4, wherein the kernel-mode memory allocation call stack includes a call stack related to network data, a call stack related to serial port data, and a call stack related to global positioning system data.

6. The method for handling memory leaks in a vehicle-mounted terminal as described in any one of claims 1 to 5, wherein during the operation of the vehicle-mounted terminal system, it further includes: The graphical interface displays the memory usage of each application process and the impact of each application process on kernel memory, and updates the content of the graphical interface at preset intervals.

7. The method for handling memory leaks in a vehicle terminal as described in any one of claims 1 to 6, wherein the process information includes a process serial number and a process name.

8. A vehicle-mounted terminal memory leak handling device, comprising: The leakage detection module is configured to, during the operation of the vehicle terminal system, if a kernel-mode memory leak is detected in the vehicle terminal system, determine whether the memory leak rate and memory leak amount meet the preset leakage conditions. The process information capture module is configured to open the kernel-mode memory debugging node and restart the vehicle terminal system if the preset leakage conditions are met, and then capture process information by requesting a probe in the call stack through the kernel-mode memory. as well as The abnormal process location module is configured to track abnormal application processes based on the process information, print the process information in the kernel-mode page request log, close the kernel-mode memory debugging node, and restart the vehicle terminal system.

9. Electronic equipment, including: Memory, configured to store computer programs; A processor configured to execute the computer program to implement the vehicle terminal memory leak handling method according to any one of claims 1 to 7.

10. A computer-readable storage medium for storing computer programs; wherein, When the computer program is executed by the processor, it implements the vehicle terminal memory leak handling method according to any one of claims 1 to 7.

Images