QNX system-oriented memory leak real-time detection method and system

Abstract

The invention discloses a QNX system-oriented memory leak real-time detection method and system, and relates to the technical field of computer software monitoring and embedded system security, and the method comprises the steps: collecting a comprehensive memory index of a monitoring target process, maintaining a dynamic baseline by using an exponentially weighted moving average algorithm, and calculating a dynamic growth threshold; parallelly calculating memory growth rates and leakage accelerations under short-term, medium-term and long-term time spans; and identifying leakage levels including normal, suspected, confirmed and serious leakage in combination with a system memory pressure state and multi-level judgment logic. When serious leakage is judged, a triple verification mechanism including absolute increment, continuity and system relevance verification is introduced; the method also includes adaptive response and precise sleep control based on system pressure. According to the method, the problem that a fixed threshold value cannot adapt to process dynamic change is solved through the self-adaptive threshold value and multi-dimensional verification, the false alarm rate is effectively reduced, and high-precision real-time monitoring under low resource occupation is realized.

Description

Technical Field

[0001] This application relates to the fields of computer software monitoring and embedded system security technology, and in particular to a method and system for real-time detection of memory leaks for QNX systems. Background Technology

[0002] The QNX operating system, due to its high real-time performance and reliability thanks to its microkernel architecture, is widely used in critical fields such as in-vehicle entertainment systems, industrial control, and medical equipment. In these scenarios, the memory stability of applications is directly related to the safe operation of the entire system. If memory leaks are not detected and blocked in time, they can easily lead to system resource exhaustion (OOM), resulting in system crashes or service restarts.

[0003] Current memory leak detection technologies primarily rely on offline static code analysis or runtime dynamic monitoring tools. While offline analysis can uncover some coding defects during the development phase, it struggles to capture logical leaks arising from complex runtime interactions. Existing runtime monitoring solutions commonly employ fixed threshold-based judgment logic, triggering alarms when process memory usage exceeds a preset absolute value or growth rate. However, this singular and rigid detection method is ill-suited to the vastly different memory usage patterns of different processes in embedded systems, and it fails to keep pace with the dynamic changes of processes at different operational phases (such as startup, stable, and periods of sudden business activity). This leads to slow leak detection or misjudging normal business-related sudden memory requests as leaks.

[0004] Furthermore, existing technologies typically lack in-depth analysis of the time dimension, often relying solely on instantaneous sampled data for judgment. This fails to effectively distinguish between brief memory fluctuations and persistent leakage trends, and most do not consider the impact of overall operating system load on the judgment strategy. Under high-frequency sampling monitoring, traditional monitoring tools often incur significant resource overhead, easily generating numerous false alarms that disrupt system operations and maintenance, and even preempting valuable CPU time slices, thereby affecting the real-time performance of the host embedded system. Therefore, there is an urgent need for a real-time memory leak detection solution that can adapt to process behavior characteristics, possesses anti-interference capabilities, and has low resource consumption. Summary of the Invention

[0005] The purpose of this invention is to provide a real-time memory leak detection method and system for QNX systems, which at least solves one of the technical problems in the prior art: the use of fixed threshold judgment logic makes it unable to adapt to the dynamic changes of different process running stages, making it difficult to distinguish between normal memory fluctuations and real leaks, resulting in a high false alarm rate, and the monitoring system itself has difficulty controlling resource consumption.

[0006] This invention provides the following solution:

[0007] According to one aspect of the present invention, a method for real-time detection of memory leaks in a QNX system is provided, comprising:

[0008] Establish a list of monitoring targets and set a global sampling time interval. At the beginning of each sampling period, update the system memory pressure status of the current operating system and collect the virtual memory size and resident memory size of each monitoring target process in the list. Calculate the comprehensive memory index for the current moment through weighted averages. Update the dynamic baseline of the monitoring target processes based on the comprehensive memory index and calculate the dynamic growth threshold for the current moment by combining historical deviations. Based on the historical sequence of the comprehensive memory index, calculate the memory growth rate of the monitoring target processes in the short, medium, and long term, respectively, and calculate the memory leak acceleration. Compare the memory growth rates in the short, medium, and long term with the dynamic growth threshold, and determine the current leak level of the monitoring target processes by combining the memory leak acceleration and system memory pressure status. Leak levels include at least normal, suspected leak, confirmed leak, and severe leak. When the determined leak level changes, generate a log containing the process identifier, leak level, and timestamp, or trigger a callback interface for response output.

[0009] In one implementation, calculating the comprehensive memory index at the current moment specifically includes: obtaining the virtual memory size and resident memory size of the monitored target process at the current moment; assigning preset weight coefficients to the virtual memory size and resident memory size respectively; adding the weighted virtual memory value and the weighted resident memory value to obtain the comprehensive memory index; and storing the calculated comprehensive memory index into the historical data queue corresponding to the monitored target process.

[0010] In one implementation, calculating the dynamic growth threshold at the current moment includes: after the baseline learning period ends, using an exponentially weighted moving average algorithm, calculating the updated baseline value at the current moment based on the baseline value at the previous moment and the comprehensive memory index at the current moment; obtaining the historical maximum absolute deviation since monitoring started, calculating the sum of the updated baseline value and the weighted historical maximum absolute deviation, and obtaining the basic dynamic growth threshold.

[0011] Furthermore, the calculation of the dynamic growth threshold also includes correcting the basic dynamic growth threshold to obtain the final dynamic growth threshold. The correction process includes: determining whether the updated baseline value is lower than the preset small memory judgment threshold; if so, the final dynamic growth threshold is calculated using a preset small memory multiplier relaxation strategy; if not, the recent memory volatility is further calculated; when the volatility is less than the preset stable value, the process is determined to be in a stable period, and the basic dynamic growth threshold is amplified using a stability adjustment coefficient to obtain the final dynamic growth threshold; if the above correction is not triggered, the basic dynamic growth threshold is used as the final dynamic growth threshold.

[0012] In one implementation, the three different time spans are a short-term observation window, a medium-term observation window, and a long-term observation window; the calculation of memory leak acceleration specifically involves: calculating the difference between the instantaneous growth rate of the current sampling period and the instantaneous growth rate of the previous sampling period, and dividing the difference in instantaneous growth rates by the sampling interval duration to obtain the acceleration value; when the acceleration value exceeds a preset graded acceleration threshold, an acceleration alarm flag is generated.

[0013] In one implementation, the specific conditions for determining a suspected leak or a confirmed leak are as follows: when the short-term memory growth rate exceeds the product of the dynamic growth threshold and the multiplier for determining a suspected leak, it is determined to be a suspected leak; when the medium-term memory growth rate exceeds the product of the dynamic growth threshold and the multiplier for determining a confirmed leak, and the absolute increase in memory within the medium-term observation window exceeds a preset noise filtering threshold, it is determined to be a confirmed leak.

[0014] In one implementation, determining a serious leak requires simultaneously meeting both an initial screening condition and a triple verification mechanism. The initial screening condition is: the long-term memory growth rate exceeds the product of the dynamic growth threshold and the multiplier for determining a serious leak. The triple verification mechanism requires simultaneously meeting the following conditions: First verification: the absolute memory growth of the monitored target process within the long-term observation window exceeds a preset capacity threshold, and the absolute growth rate as a percentage of the current dynamic baseline exceeds a preset percentage. Second verification: looking back at the most recent sampling periods, the memory values ​​of all historical sampling points are not lower than the preset maintenance percentage of the memory value when the initial screening condition was first triggered. Third verification: the absolute memory growth of the monitored target process as a percentage of the total memory growth of the operating system during the same period exceeds a preset contribution rate threshold.

[0015] In one implementation, the determination process further includes an adaptive adjustment mechanism based on the system memory pressure status: when the system memory pressure status is in a warning state, the multiplier of the serious leak determination is reduced and the time span of the long-term observation window is shortened; when the system memory pressure status is in a critical state, a fast determination path is initiated: the absolute growth of the monitored target process within a preset short window is directly calculated, and if the ratio of the absolute growth to the current total available memory of the system exceeds a preset critical threshold, it is directly determined as a serious leak, skipping the triple verification mechanism.

[0016] In one implementation, the method further includes a cyclic sleep and resource control step: recording the start and end timestamps of the current sampling period, calculating the actual execution time of the current period; calculating the difference between the global sampling time interval and the actual execution time; if the difference is greater than zero, calling the system sleep interface to suspend the current thread for a duration equal to the difference; if the difference is less than or equal to zero, immediately resetting the start timestamp and directly entering the next sampling period.

[0017] A second aspect of the present invention provides a real-time memory leak detection system for QNX systems, comprising:

[0018] The system comprises four layers: a state decision layer for performing system initialization and updating system memory pressure status in each sampling period; a system perception and data acquisition module for collecting virtual memory size and resident memory size of monitored target processes and calculating comprehensive memory metrics; an event analysis layer for maintaining a dynamic baseline based on comprehensive memory metrics, calculating dynamic growth thresholds, and calculating memory growth rate and memory leak acceleration over short, medium, and long-term time spans in parallel; a multi-level judgment module for determining the leakage level of a process according to preset priority logic based on memory growth rate, dynamic growth threshold, and system memory pressure status, and performing triple verification including absolute incremental verification, persistence verification, and system correlation verification when a severe leak is determined; and a response output layer for generating hierarchical logs or triggering process status callback interfaces when the leakage level changes.

[0019] This invention, through the introduction of a dynamic baseline and multi-scale time window analysis mechanism, achieves adaptive detection of memory leak behavior, distinguishing between normal memory fluctuations and abnormal leak trends. In particular, the combination of an adaptive system memory pressure adjustment mechanism and triple verification logic ensures rapid response under high system load while effectively reducing false alarm rates in complex scenarios, thus solving the technical problems of fixed and rigid thresholds, poor anti-interference capabilities, and uncontrollable system resource consumption in existing technologies.

[0020] The above solution achieves the following beneficial technical effects:

[0021] This invention abandons the traditional fixed threshold judgment method and uses an exponentially weighted moving average algorithm to construct a dynamic baseline that follows the process's running trend. It also combines small memory protection and stabilization period correction strategies to calculate the dynamically increasing threshold in real time. This mechanism allows the detection standard to automatically adapt to the memory behavior characteristics of different processes and the fluctuation characteristics of the same process at different stages, effectively solving the problem of missed or false alarms caused by rigid threshold settings, without requiring manual parameter tuning for each process.

[0022] This invention introduces a triple verification mechanism of multi-scale time window analysis and severe leakage. By parallel calculation of short, medium, and long-term memory growth rates, it can accurately distinguish between instantaneous fluctuations and continuous leakage. In particular, in the determination of severe leakage, the mandatory joint verification of absolute increment, persistence, and system correlation can effectively filter out normal sudden memory growth behaviors such as large file loading and cache building, ensuring a high confidence level for alarms.

[0023] This invention establishes an adaptive response mechanism based on system memory pressure and precise cyclic sleep control. When system resources are strained, it automatically switches to high-sensitivity or ultra-fast mode to quickly block risks; during normal operation, it dynamically adjusts the sleep duration by calculating the actual time consumed, minimizing the CPU resource consumption of the monitoring system itself. This design ensures that the monitoring system provides security without becoming a burden that drags down the performance of the embedded QNX system. Attached Figure Description

[0024] Figure 1 This is a mechanism layering diagram of a real-time memory leak detection method and system for QNX systems provided by one or more embodiments of the present invention.

[0025] Figure 2 This is a functional architecture diagram of a real-time memory leak detection method and system for QNX systems provided by one or more embodiments of the present invention.

[0026] Figure 3 This is a flowchart of the core algorithm of a real-time memory leak detection method and system for QNX systems provided by one or more embodiments of the present invention. Detailed Implementation

[0027] The technical solution of the present invention will now be clearly and completely described with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0028] See attached document Figure 1 The present invention provides an embedded system memory leak dynamic detection system, which includes: a data acquisition layer, an event analysis layer, a state decision layer and a response output layer.

[0029] The data acquisition layer is responsible for acquiring memory usage data of the target process in real time. In this embodiment, the data acquisition layer obtains the memory information of the specified process non-intrusively by accessing the / proc virtual file system provided by the embedded real-time operating system (such as QNXNeutrinoRTOS). This method does not require any modification or instrumentation of the target process's source code, nor does it require recompiling the target process.

[0030] Within each preset sampling period, the data acquisition layer reads and acquires two core memory metrics for each target process in the monitoring list: the process's virtual memory size (virtual_size) and the process's resident memory size (resident_size). After acquiring these two core memory metrics, the data acquisition layer performs a weighted calculation on these two metrics to generate a comprehensive memory usage metric. This comprehensive memory usage metric Used for subsequent memory growth analysis. Its calculation method is defined as follows:

[0031] ;

[0032] in, This represents the overall memory usage metric calculated during the current sampling period; This represents the virtual memory size (virtual_size) of the process, obtained from the / proc file system. This represents the resident memory size (resident_size) of the process, obtained from the / proc filesystem. The data acquisition layer will calculate this comprehensive memory usage metric. The corresponding sampling timestamps are output to the event analysis layer for subsequent trend analysis and feature extraction.

[0033] See attached document Figure 1 The event analysis layer receives and processes comprehensive memory usage metrics output by the data acquisition layer. The event analysis layer is the core of data processing and feature extraction. It transforms discrete memory data sequences into structured analysis results that reflect memory change trends and outputs them to the state decision layer.

[0034] In this embodiment, the event analysis layer maintains a time-series data queue for each monitored process. This queue stores comprehensive memory usage metrics generated by the data acquisition layer within continuous sampling periods. and its corresponding timestamp.

[0035] The event analysis layer performs multi-time-window growth rate analysis based on this time-series data queue. Specifically, it calculates the average growth rate of memory over three different time scales to distinguish between short-term memory fluctuations and long-term sustained growth trends in processes. These three growth rates are: short-term growth rate... (Based on a 15-second time window), medium-term growth rate (Based on a 60-second time window) and long-term growth rate (Based on a 300-second time window). Taking any given time window as an example, its growth rate... The calculation method is as follows:

[0036] ;

[0037] in, and These are the overall memory usage metrics and timestamp at the end of the time window, respectively. and These are the comprehensive memory usage metrics and timestamps at the start and end of the time window, respectively. To achieve early warning of memory leaks, the event analysis layer also performs leak acceleration detection. This detection identifies accelerating trends in memory growth by calculating the rate of change of the memory growth rate, i.e., the second derivative of memory usage with respect to time. First, the instantaneous growth rate between two consecutive sampling points is calculated.

[0038] ;

[0039] in, For sampling points The instantaneous growth rate; and These are the current sampling points. and the previous sampling point Comprehensive memory usage metrics; and These are the current sampling points. and the previous sampling point Timestamp.

[0040] Calculate the memory growth acceleration based on continuous instantaneous growth rate. :

[0041] ;

[0042] in, For sampling points The acceleration of memory growth; and These are the instantaneous growth rates of the current sampling point and the previous sampling point, respectively.

[0043] The event analysis layer will calculate the resulting short-term growth rate. Medium-term growth rate Long-term growth rate And the acceleration of memory growth As part of the analysis, the results are also output to the state decision layer for subsequent leakage level determination.

[0044] See attached document Figure 1The state decision layer receives the analysis results from the event analysis layer and, in conjunction with the global system state, makes a final determination of the level of memory leak in the target process. The state decision layer is the core of the leak determination logic, and its determination result is output to the response output layer.

[0045] The analysis results received by the state decision layer include short-term growth rates. Medium-term growth rate Long-term growth rate And the acceleration of memory growth Its execution decision is based on a dynamically adaptive growth threshold. This threshold is not fixed, but is calculated in real time by the state decision layer based on the historical memory usage baseline and fluctuations of each process, thereby adapting to the memory behavior patterns of different processes.

[0046] The state decision layer employs a multi-level leak detection rule, dividing the process's memory state into four levels: Normal (NoRMAL), Suspected Leak (LEVEL_1), Confirmed Leak (LEVEL_2), and Critical Leak (LEVEL_3). The detection process follows a clear hierarchical structure, prioritizing checks that meet the conditions for higher-level leaks.

[0047] Specifically, the state decision layer first determines whether the condition of LEVEL_3 is met. If not, it continues to determine whether the condition of LEVEL_2 is met. If still not met, it continues to determine whether the condition of LEVEL_1 is met. If the conditions of all levels are not met, the process state is determined to be NORMAL. The determination rules are as follows:

[0048] When long-term growth rate Exceeding the dynamic growth threshold If the value is 3.5 times that of the target value and meets the additional triple verification mechanism, it is determined to be LEVEL_3.

[0049] When the LEVEL_3 condition is not met, but the medium-term growth rate is... Exceeding the dynamic growth threshold When the memory size is 3.0 times larger and the absolute increase in memory size during the medium term is greater than 50KB, it is determined to be LEVEL_2.

[0050] When the LEVEL_2 condition is not met, but the short-term growth rate is... Exceeding the dynamic growth threshold When it is 1.5 times, it is determined to be LEVEL_1.

[0051] Furthermore, the state decision layer possesses system stress perception and adaptive adjustment capabilities. It acquires the overall memory usage of the current system and categorizes it into three stress levels: NORMAL, WARNING, and CRITICAL. Based on the different stress levels, the state decision layer adjusts its judgment rules:

[0052] At the WARNING stress level, to improve detection sensitivity, the long-term growth threshold coefficient used for LEVEL_3 determination will be reduced by 40% (i.e., from 3.5 times to 2.1 times), and the time required to confirm a leak will be halved.

[0053] Under CRITICAL stress level, a fast decision path is enabled. In this case, the state decision layer bypasses the standard multi-level decision process and directly checks whether the process's memory growth within 30 seconds exceeds 5% of the current system's total available memory. Once this condition is met, the process is immediately classified as LEVEL_3.

[0054] After the state decision layer completes the determination, it outputs the final leakage level (e.g., LEVEL_1 or LEVEL_3) and the corresponding process ID as the determination result to the response output layer.

[0055] See attached document Figure 1 The response output layer receives the leak assessment results from the state decision layer and executes preset response actions based on these results. The response output layer is triggered when the leak level of a monitored process changes.

[0056] In this embodiment, the response output layer provides at least two response methods. The first response method is log output. When a judgment result is received from the state decision layer, the response output layer generates a system log entry. The priority of this log entry is associated with the detected leakage level. For example, when the judgment result is a severe leakage LEVEL_3, the generated log entry is at the EMERG level. The information contained in this log entry includes at least: the process ID of the process that caused the leakage, the specific leakage level determined (e.g., an enumeration value of LEVEL_1, LEVEL_2, or LEVEL_3), and the timestamp of the event. This log is used by system maintenance personnel for post-event analysis and problem tracing.

[0057] The second response method is the process status callback interface. The system allows users or other management modules to pre-register a callback function. When the response output layer receives a judgment result indicating a change in the leak level, it will call the registered callback function. During the call, the response output layer will pass the process ID of the leaking process and the new leak level as parameters to the callback function. This callback interface provides a programmatic interaction mechanism, enabling other parts of the system to automatically execute customized processing strategies such as process isolation, smooth restart, resource limiting, or reporting to the higher-level management system based on the received leak level.

[0058] See attached document Figure 2 The memory leak detection method provided in this embodiment of the invention begins with the startup and configuration of the monitoring task. When the method starts executing, system initialization is performed first. This includes setting the global sampling time interval, which in this embodiment is set to 5000 milliseconds (i.e., DEFAULT_SAMPLING_INTERVAL_MS=5080). Simultaneously, the system establishes a monitoring list to store information about processes to be monitored. Users can add the process IDs of target processes to this list through the system interface, for example, adding processes with process IDs 1234 and 5678.

[0059] After initialization, the system enters the main monitoring loop startup phase. This loop runs continuously at a set sampling interval. At the beginning of each loop, the system first performs an update operation to assess system memory pressure. This step reads the current system memory status, obtains total and available memory data, and calculates the current system memory utilization rate to determine the current system memory pressure level. This pressure level will serve as an important input parameter for subsequent decision-making.

[0060] Subsequently, the system enters the process traversal phase. The monitoring system sequentially reads each target process in the monitoring list and performs subsequent detection steps for the currently being processed process. During the traversal, the system first performs a validity check. The system verifies whether the process corresponding to the current process ID is still running in the system.

[0061] If the process exists, the system will perform a data collection operation, reading the process's current virtual memory size and resident memory size by accessing the / proc file system, which will serve as the basis for this sampling.

[0062] If the process no longer exists, for example, if the process has exited or been terminated, the system performs a cleanup operation, marking and removing the invalid process ID from the monitoring list to maintain the accuracy of the monitoring list.

[0063] After completing the data acquisition or removal operation for the current process, the process proceeds to the next processing branch based on the process state. For existing processes, the acquired memory snapshot will be used for threshold updates and growth analysis; for processes marked for removal, a unified resource cleanup will be performed after the traversal is complete.

[0064] See attached document Figure 2 The memory leak detection method of this invention begins with system initialization and the establishment of a periodic monitoring loop. Before the monitoring task starts, the system first performs an initialization configuration step. In this step, the global sampling time interval parameter is set. In the preferred configuration of this embodiment, this parameter is set to 5000 milliseconds. This parameter determines the time granularity of memory leak detection, that is, the system performs a complete state assessment of the monitored target process every 5 seconds.

[0065] Simultaneously, the system establishes and maintains a list of monitoring targets. This list stores the unique identifiers (ProcessIDs, or PIDs) of the processes to be monitored. The system provides a dynamic management interface (e.g., addProcess) that allows one or more specified process IDs (e.g., PID1234, PID5678) to be added to this monitoring target list during system initialization or operation. For each added process, the system internally allocates an independent data structure for storing its memory snapshot sequence, baseline data, and status flags.

[0066] After completing the above configuration, the system responds to a startup command (e.g., a `start` call) and enters the main monitoring loop. This loop runs in a separate execution thread. Each iteration of this loop represents a monitoring cycle. At the beginning of each loop, the system first verifies the current running status flag; if the flag is "running," it sequentially triggers subsequent system stress updates, process traversal, data collection, and analysis steps; if the flag is "stopped," it terminates the loop and releases the relevant monitoring resources. This monitoring loop continues to run until an explicit stop command is received.

[0067] After the monitoring cycle starts, the method of this embodiment first performs system status awareness and data acquisition steps. This step ensures that subsequent leak determination is not only based on the memory performance of a single process, but also takes into account the overall load environment of the current operating system, while guaranteeing the validity and real-time nature of the collected data. At the beginning of each sampling cycle, the system first performs an update operation on the system memory pressure status. This operation aims to obtain the current global memory usage of the operating system. The system obtains the current total physical memory size of the system by reading the operating system kernel interface (e.g., reading the system-level / proc / meminfo file or calling the system API). ) and the current available memory size of the system ( Based on these two values, the system calculates the current system memory usage. :

[0068] ;

[0069] Based on the calculated system memory usage The system will update the current pressure status to one of the following three preset levels, which will be used as a global parameter to affect subsequent judgment thresholds:

[0070] like If so, the system pressure status is marked as NORMAL.

[0071] like If so, the system pressure status will be marked as WARNING.

[0072] like If the system pressure state is critical, then the system pressure state is marked as CRITICAL.

[0073] After updating the system stress status, the system begins to traverse the current list of monitored targets. For each target process in the list, the system first performs an existence check. This check confirms whether the process is still running by querying the operating system kernel (e.g., checking if a subdirectory named after the process ID exists in the / proc directory). If the target process is detected as non-existent (e.g., the process has exited or been unexpectedly terminated), the system marks the process ID as invalid and removes it from the monitoring list and memory records in a subsequent cleanup step to free up the monitoring system's resources and prevent invalid data from interfering with the analysis.

[0074] For a target process that has been verified to be running, the system performs a memory snapshot. The system accesses the process's status file under the / proc file system and reads its current memory statistics. This embodiment specifically collects two key indicators: virtual memory size (…). ) and resident memory size ( ), where t represents the current sampling time.

[0075] To simplify multi-dimensional memory data into a single variable suitable for trend analysis, the system calculates the comprehensive memory index for the current moment using collected virtual memory and resident memory data, based on preset weighting coefficients. The calculation formula is as follows:

[0076] ;

[0077] in, The comprehensive memory index calculated at the current sampling time t; This represents the size of the virtual memory collected at the current sampling time t. This represents the size of the resident memory collected at the current sampling time t.

[0078] Calculated comprehensive memory metrics The data is then stored in the historical data queue corresponding to that process, serving as the foundational data source for subsequent baseline updates, growth rate calculations, and leakage acceleration analysis. Through these steps, the system completes the perception of the environmental state and the acquisition and preprocessing of raw data from all target processes within a single sampling period.

[0079] After completing data collection and obtaining the comprehensive memory metrics at the current moment. Next, the method of this embodiment of the invention enters the step of calculating and updating the dynamic baseline and threshold. This step aims to build and maintain a reference baseline that evolves with the process's running state, thereby providing an adaptive judgment basis for subsequent leak determination. The processing flow of this step is divided into two stages based on the process monitoring duration: the baseline learning period stage and the dynamic update stage. When the monitoring task for a certain process has just started, the system enters the baseline learning period. During this period (e.g., the first 60 seconds or the first 15 sampling periods), the system does not perform leak determination, but instead uses the collected comprehensive memory indicators. The samples are sequentially stored in a temporary sample buffer queue. When the baseline learning period ends (i.e., the number of samples reaches a preset value BASE_RECORDS, for example, 15), the system calculates the arithmetic mean of all samples in the buffer queue to obtain the initial baseline value for the process. After the calculation is complete, the system releases the memory resources occupied by the temporary buffer queue used to store the original samples in order to minimize the overhead of monitoring itself.

[0080] After the baseline learning period, the system enters the dynamic update phase. During this phase, the system employs an exponential smoothing algorithm, utilizing the current comprehensive memory metrics. Baseline value of the previous time step Update to generate a new baseline value for the current time. This algorithm uses weighted calculations to suppress transient fluctuations while following memory change trends. The update formula is as follows:

[0081] ;

[0082] in, This is the updated baseline value at the current sampling time; This is the baseline value from the previous sampling time; 0.9 is the comprehensive memory index collected at the current sampling time; 0.9 is the retention weight of the historical baseline value; 0.1 is the update weight of the current measurement value.

[0083] Based on the updated baseline value The system further calculates a dynamic growth threshold used to determine leakage. The calculation of this threshold takes into account the process's historical maximum deviation to accommodate the memory thrashing characteristics of different processes. The formula for calculating the base threshold is as follows:

[0084] ;

[0085] in, Based on the dynamic growth threshold; This is the baseline value at the current moment; This refers to the comprehensive memory metrics monitored since the start of monitoring. Compared with baseline value The historical maximum absolute deviation between the two values; 0.5 is the deviation influence coefficient.

[0086] To further improve the accuracy of detection, the system calculates... Subsequently, the following optimization and adjustment strategies will be applied based on process characteristics to determine the final dynamic growth threshold.

[0087] First, a threshold adjustment strategy for processes with small memory usage. The system determines the baseline value of the current process. Does it fall within the scope of small memory usage (e.g., below the preset memory limit)? If so, to prevent false alarms caused by normal small memory requests, the system will automatically raise the threshold standard, ultimately setting the threshold... Set to 2.5 times the baseline value:

[0088] ;

[0089] Second, the threshold adjustment strategy for the stable period. The system calculates the volatility of memory data in real time. If the memory volatility within the current detection period is less than 3%, the process is determined to be in a stable memory period. During the stable period, the system will amplify the impact of the baseline to adjust the threshold, at which point the final threshold will be determined. Multiply the base threshold or the aforementioned adjustments by a stability coefficient (e.g., 1.2):

[0090] ;

[0091] in This is the intermediate threshold after basic calculations or small memory adjustments. The final dynamic growth threshold is obtained after the above calculations and adjustments. This will be passed to the subsequent time window analysis module as a key reference standard for determining whether a memory leak exists.

[0092] After the system updates the dynamic growth threshold based on the current process status, the method of this embodiment of the invention enters the multi-scale analysis and leak acceleration detection step. This step aims to extract growth features with judgment significance from the instantaneously fluctuating memory data through trend calculations in different time dimensions, and to identify early acceleration signs of memory leaks.

[0093] This step is based on a time-series data queue maintained by the event analysis layer. This queue stores historical records of the process's comprehensive memory metrics over several past sampling periods. The system first calculates based on the current system time. The system retrieves historical sampling data from the historical data queue, looking up data points across different time spans. Specifically, it locates sampling points approximately 15 seconds prior to the current time. Sampling point approximately 60 seconds ago And sampling points approximately 300 seconds ago. .

[0094] Based on the located historical data points, the system calculates the memory growth rate at three different time scales in parallel to construct a multi-dimensional leakage profile. First, it calculates the short-term growth rate. This metric reflects the instantaneous memory usage trend of a process over the past 15 seconds, and is used to detect rapidly occurring abnormal memory requests. The calculation formula is as follows:

[0095] ;

[0096] in, This represents the short-term memory growth rate. This represents the overall memory metrics at the current sampling time. For a historic moment Recorded overall memory metrics; This is the current sampling timestamp; This is a historical sampling timestamp.

[0097] Secondly, calculate the medium-term growth rate. This indicator reflects changes in process memory usage over the past minute and is used to confirm the sustainability of short-term trends. The calculation formula is as follows:

[0098] ;

[0099] in, This represents the medium-term memory growth rate. For a historic moment Recorded comprehensive memory metrics.

[0100] Finally, calculate the long-term growth rate. This metric reflects the cumulative memory changes of a process over the past 5 minutes and is used to determine if a slow but persistent serious leak exists. The calculation formula is as follows:

[0101] ;

[0102] in, This represents the long-term memory growth rate. For a historic moment Recorded comprehensive memory metrics.

[0103] While performing multi-scale growth rate calculations, the system executes leak acceleration detection. This detection aims to identify whether the memory leak rate is showing a deteriorating trend, i.e., calculating the rate of change of the memory growth rate over time (second derivative). The system first obtains the instantaneous growth rate for the current sampling period. Instantaneous growth rate compared to the previous sampling period Then calculate the leakage acceleration. The calculation formula is as follows:

[0104] ;

[0105] in, This represents the acceleration of memory leaks, typically measured in KB / s². The instantaneous memory growth rate calculated for the current sampling period; This is the instantaneous memory growth rate calculated in the previous sampling period; and These are the collection timestamps for the current and previous sampling periods, respectively.

[0106] Acceleration was calculated The system then compares it with preset three-level acceleration thresholds. In this embodiment, the three acceleration thresholds are: Level 1 threshold 10KB / s², Level 2 threshold 30KB / s², and Level 3 threshold 60KB / s². If the calculated... If the value exceeds any of the above thresholds, the system will generate a corresponding acceleration alarm flag.

[0107] The above calculations yielded... , , and acceleration This will be combined with the currently calculated dynamic growth threshold. This serves as input data, which is then passed to the next stage of the multi-level leakage status determination process.

[0108] After the system completes the calculation of the multi-scale growth rate and the update of the dynamic threshold, the method of this embodiment of the invention enters the multi-level leakage state determination and change processing step. This step is the core decision-making link of the entire detection logic, which aims to accurately classify the current memory state of the target process into normal or leakage levels of different severity according to the input feature data and the preset priority logic.

[0109] This step employs a cascading decision logic, strictly verifying the decision criteria in descending order of severity (i.e., severe leakage, confirmed leakage, suspected leakage). The system reads the currently calculated short-term growth rate. Medium-term growth rate Long-term growth rate And the final dynamic growth threshold As an input variable.

[0110] First, the system performs a critical leak (LEVEL_3) check. The system checks the long-term growth rate. Whether it significantly exceeds the threshold, the specific judgment criteria are as follows: (Note: If the system is under WARNING stress, this coefficient of 3.5 will automatically adjust to 2.1). If this initial screening condition is met, the system does not immediately make a diagnosis, but instead initiates a triple verification mechanism to eliminate false alarms. This mechanism includes mandatory verification in three dimensions:

[0111] Absolute and relative incremental verification: Absolute memory growth of the system's computation process over the past 300 seconds. Only when If the value is 50MB and the increase exceeds 15% of the current baseline value, this check passes.

[0112] Persistence Verification: The system backtracks the memory records of the most recent 3 sampling periods. Only if the memory values ​​of these 3 samples are not less than 70% of the memory value at the time of the first suspected increase are the increase considered persistent and the verification is passed.

[0113] System correlation check: The system calculates the total memory growth of the entire operating system during the same period. Only when the process's memory usage increases. account for the total growth of the system The proportion reaches or exceeds 60% (i.e. When this process is identified as the primary source of system memory consumption, this verification is passed.

[0114] The system will only determine the current state of the process as a serious leak (LEVEL_3) when all the conditions of the initial screening and the triple confirmation mechanism are met simultaneously.

[0115] If the process does not meet the LEVEL_3 criteria, the system continues with the leak confirmation (LEVEL_2) check. The system checks the interim growth rate. Does it meet the requirements? To filter out minor fluctuations, the system also checks whether the absolute increase in memory within the 60-second window exceeds 50KB. If both conditions are met, the system determines the current state of the process as a confirmed leak at LEVEL_2.

[0116] If the process does not meet the LEVEL_2 or higher criteria, the system continues to perform the suspected leak (LEVEL_1) assessment. The system checks the short-term growth rate. Does it meet the requirements? This level is primarily used to detect rapidly occurring abnormal trends. If this condition is met, the system classifies the current state of the process as a suspected leak LEVEL_1.

[0117] If none of the above leakage level criteria are met, the system classifies the process's current state as normal. After determining the process's state level for the current sampling period, the system performs state change processing. The system reads the process's state level record stored in the previous sampling period and compares it with the current level. If they match, the system only updates the historical record and does not perform any additional operations. If they do not match (e.g., changing from normal to level 1, or from level 2 to level 3), the system identifies a state change event. At this time, the system immediately writes the new state level to the process control block and triggers the response output layer. The system packages the changed leakage level, the current timestamp, and the process ID as parameters and passes them to the logging module and callback interface module to execute corresponding alarm or control measures.

[0118] After completing the leakage status determination and necessary response processing for the current sampling cycle, the method of this embodiment enters the cycle sleep and resource control step. This step aims to precisely control the timing of the monitoring cycle and ensure that the monitoring system's own consumption of computing resources on the host embedded system is kept at a minimum.

[0119] This step employs a precise sleep mechanism based on execution time compensation, rather than a simple fixed-duration delay. The system first obtains the timestamp at the end of the current sampling period. Combined with the timestamp recorded at the beginning of this period. Calculate the actual execution time of the data acquisition, analysis, and judgment logic within this period. The calculation formula is:

[0120] ;

[0121] in, This represents the actual execution time for the current monitoring period. This is the system timestamp indicating the completion time of the current cycle. This is the system timestamp at the start of the current period.

[0122] Based on a preset global sampling time interval (For example, 5000 milliseconds), the system calculates the sleep time required to wait until the start of the next sampling period. The calculation formula is as follows:

[0123] ;

[0124] The system is based on the calculations obtained Value execution branch control logic:

[0125] like This indicates that the processing of the current cycle will be completed within the predetermined time window. The system calls the blocking sleep interface provided by the operating system (such as the POSIX standard nanosleep or the delay function of RTOS) to suspend the current monitoring thread for the specified duration. During this suspension period, the monitoring thread actively releases its CPU scheduling time slice, without occupying any processor computing resources, thus ensuring the zero-load characteristic of the monitoring system when it is not in operation.

[0126] like This indicates that the processing time for the current cycle has exceeded the preset sampling interval (i.e., a cycle overrun has occurred). In this case, the system does not perform a sleep operation but immediately resets the cycle start timestamp. The system immediately enters the system status awareness and data acquisition steps for the next monitoring cycle, setting the current time. This mechanism ensures that monitoring tasks can keep up with the preset schedule even under high system load, preventing serious breaks in the timeline of monitoring data.

[0127] After hibernation ends or is skipped, the system checks the running status flag again. If the flag is still running, the program flow jumps back to the system status awareness step at the beginning of the loop and begins a new round of checks; if the flag changes to stopped, the system exits the monitoring loop, releases the allocated memory structure and handle resources, and terminates the program.

[0128] See attached document Figure 2In this embodiment of the invention, the real-time detection function is implemented by an independent daemon process or software entity named MemoryLeakMonitor. MemoryLeakMonitor is configured on the QNX system and is responsible for periodically collecting process memory data, performing analysis and judgment, and outputting responses. This embodiment of the invention provides a dynamic adaptive threshold mechanism, configured in the state decision layer and event analysis layer, to address the technical problem that fixed thresholds cannot adapt to the differences in memory behavior of different processes and the differences in memory fluctuations of a single process at different stages of operation.

[0129] The core of this mechanism lies in constructing a dynamic baseline that follows the trend of process memory changes, and calculating a real-time detection threshold based on this baseline and historical fluctuation characteristics. This mechanism includes a baseline iterative update sub-mechanism and a threshold dynamic correction sub-mechanism.

[0130] First, regarding the baseline iterative update sub-mechanism. This mechanism employs an exponentially weighted moving average algorithm to maintain the process's memory baseline. This algorithm tracks and smooths long-term memory trends while filtering out high-frequency transient noise by assigning different weights to the current measurement value and historical baseline values. In each sampling period... The system is based on the currently collected comprehensive memory indicators. Update baseline values The update logic is defined by the following formula:

[0131] ;

[0132] in, Indicates the current sampling period The calculated updated baseline value; Indicates the previous sampling period Preserved historical baseline values; Indicates the current sampling period Collected and calculated comprehensive memory metrics; This represents the updated weighting coefficient for the current measurement value. In this embodiment, Set to 0.1, this means the historical baseline. A weight of 0.9 was retained. This weight configuration ensures that the baseline is highly robust to disturbances and will not drift drastically due to a single memory mutation, thus reflecting the steady-state level of process memory.

[0133] Second, regarding the threshold dynamic correction sub-mechanism. This mechanism is based on the aforementioned baseline value. The basic threshold is calculated by combining the historical fluctuation characteristics of the process, and a secondary correction is performed based on the process type and running status.

[0134] First, the system calculates the basic dynamic growth threshold. This calculation incorporates a historical maximum deviation factor to cover the maximum permissible fluctuation range of the process under normal operating conditions. The calculation formula is as follows:

[0135] ;

[0136] in, This represents the uncorrected baseline dynamic growth threshold; This represents the baseline value at the current moment; This represents the largest absolute deviation in history, which is the deviation among all sampling points since monitoring began. The maximum value; This represents the tolerance coefficient for deviation. In this embodiment, It was set to 0.5.

[0137] Secondly, the system adjusts the conditions accordingly. Execute logic adjustments to generate the final dynamic growth threshold. The correction logic includes small memory protection logic and stable period adaptation logic: protection logic for small memory processes: the system detects the current baseline value. Is the memory usage below a preset small memory threshold (e.g., 10MB)? If it is below this threshold, it indicates that the process is not very sensitive to the absolute value of memory growth, and directly using a proportional threshold will lead to false alarms. In this case, the system will discard the process. Instead, a multiplier relaxation strategy was adopted for calculation.

[0138] ;

[0139] in The small memory threshold multiplier is set to 2.5 in this embodiment.

[0140] For the stable period adaptation logic: The system monitors the volatility of memory data in real time. If the current process does not trigger the small memory protection logic, and the memory volatility over the last N periods is less than a preset stable value (e.g., 3%), the system determines that the process is in a stable period. During the stable period, to prevent extremely small normal fluctuations from triggering the threshold, the system adaptively amplifies the base threshold. At this time, The calculation formula is:

[0141] ;

[0142] in The stability adjustment coefficient is set to 1.2 in this embodiment. If none of the above correction logic is triggered, the final dynamically increasing threshold will be used. Directly equal to the basic dynamic growth threshold Through the above mechanism, the system can generate an independent judgment criterion for each process at any given time, which matches its current operational characteristics. This standard was subsequently used in multi-level leak detection processes.

[0143] See attached document Figure 3 This invention provides a multi-level time window and graded early warning mechanism, configured at the event analysis layer and state decision layer, to address the technical problem that a single time scale cannot simultaneously ensure both detection sensitivity and accuracy. This mechanism maintains three sliding time windows of different spans in parallel, capturing memory growth characteristics at different frequencies, and mapping them to three progressively increasing early warning levels.

[0144] The mechanism first establishes three parallel time observation windows, namely: short-term observation window ( ), medium-term observation window ( ) and long-term observation window ( ).

[0145] Short-term observation window The time span is set to 15 seconds. This window is used to calculate the short-term growth rate Gshort, which physically reflects the instantaneous rate of change in process memory. This window corresponds to the first level warning (LEVEL_1), i.e., a suspected leak state. When the calculated short-term growth rate... This level of alert will be triggered when the following conditions are met:

[0146] ;

[0147] in, This represents the memory growth rate calculated within a 15-second window; This represents the final dynamic growth threshold calculated during the current sampling period; 1.5 represents the multiplier for determining a suspected leak. The triggering logic at this level is designed to capture any rapid memory allocation behavior that exceeds the allowable range of the dynamic threshold with high sensitivity, as an initial anomaly marker.

[0148] Mid-term observation window The time span is set to 60 seconds. This window is used to calculate the medium-term growth rate. Its physical significance lies in verifying the sustainability of memory growth trends to filter out short-term memory fluctuations or temporary bursts of requests. This window corresponds to the second-level warning (LEVEL_2), which confirms the leak status. When the calculated medium-term growth rate... This level of alert will be triggered when the following conditions are met:

[0149] ;

[0150] in, This represents the memory growth rate calculated within a 60-second window; This represents the final dynamic growth threshold calculated during the current sampling period; 3.0 represents the multiplier for confirming a leak. This represents the absolute increase in process memory within the 60-second window; 50KB represents the minimum absolute increase threshold required to filter noise. Represents the logical AND operation.

[0151] Long-term observation window The time span is set to 300 seconds. This window is used to calculate the long-term growth rate. Its physical significance lies in detecting slow but continuously accumulating memory leaks and preventing resource exhaustion. This window corresponds to the third level warning (LEVEL_3), i.e., a severe leak state. When the calculated long-term growth rate... This level of alert will be triggered when the following conditions are met:

[0152] ;

[0153] in, This represents the memory growth rate calculated within a 300-second window. This represents the final dynamic growth threshold calculated during the current sampling period; This indicates the scaling factor affected by system pressure conditions. When the system is in normal operating condition... The value is 3.5; when the system is in a warning state, Automatically adjusted to 2.1 to improve the detection rate under high load.

[0154] This mechanism employs a cascading decision logic with high-priority blocking to comprehensively decide on the analysis results of the three windows mentioned above. In each sampling period, the mechanism first checks the LEVEL_3 condition of the long-term observation window. If satisfied, the current state is directly locked as a severe leak, and other windows are not evaluated. If LEVEL_3 is not satisfied, the mechanism downgrades to checking the LEVEL_2 condition of the medium-term observation window. If satisfied, the state is locked as a confirmed leak. Only when neither of the two more severe conditions is satisfied is the LEVEL_1 condition of the short-term observation window evaluated. If none of the three conditions are satisfied, the state is determined to be normal. This logic ensures that the most severe memory risks are identified and responded to with the highest priority.

[0155] The embodiments of the present invention in the long-term growth rate After the initial determination of a critical leak, a LEVEL_3 critical leak triple verification mechanism is introduced. This mechanism is configured in the state decision layer and aims to solve the problem of high false alarm rate caused by relying solely on the growth rate threshold, especially when the overall system memory fluctuates greatly or when processes are performing normal large-scale resource loading.

[0156] When long-term growth rate Meets the initial screening criteria (i.e.) When a critical leak occurs, the system does not directly output a critical leak alarm, but instead enters a stringent triple verification logic channel. Only when all three verification conditions are met will the system finally confirm and lock the LEVEL_3 state.

[0157] The first layer of verification involves a dual magnitude check of both the absolute increment and the relative percentage. This check aims to confirm that the magnitude of memory growth has substantial destructive power, eliminating statistically misleading cases where the numerical value is small but the fluctuation rate is large. The system calculates the absolute memory growth of this process within the current long-term observation window (300 seconds). For verification to pass, both of the following sub-conditions must be met simultaneously:

[0158] absolute growth The capacity must exceed a preset threshold, which is set to 50MB in this embodiment. This threshold is used to filter out small increases that have a negligible impact on modern embedded systems.

[0159] This absolute growth Represents the current baseline value of the process The proportion must be significant, specifically exceeding 15%. The validation logic formula is as follows:

[0160] ;

[0161] The second layer of verification involves the persistence of historical data. This verification aims to distinguish between instantaneous memory spikes (such as sudden large file loads or cache builds) and genuine, persistent leaks. Genuine leaks have irreversible cumulative characteristics, while instantaneous spikes are usually followed by a decline. The system backtracks the data from the three most recent sampling periods in the buffer queue. The system then compares the combined memory metrics from these three historical moments with the memory values ​​at the time the initial screening condition was first triggered. A comparison is performed. The verification passes if the memory values ​​at all three historical sampling points are not lower than [a certain threshold]. 70%. If the value at any historical point is lower than this percentage, it indicates a significant drop in memory usage, is judged as a non-persistent leak, and the verification fails. The verification logic formula can be expressed as: For (Representing three backtracking cycles):

[0162] ;

[0163] The third layer of verification is a system-level correlation check. This check aims to confirm that the current process is the root cause of the increase in overall system memory pressure, rather than merely a secondary cause fluctuating with the overall system. The system obtains the increase in total memory usage of the entire operating system within the same time period (i.e., the time period corresponding to the long-term observation window). The system calculates the growth of the process. In total system growth The contribution percentage in the process. The verification condition is that the process's growth contribution rate must reach or exceed 60%. The verification logic formula is as follows:

[0164] ;

[0165] This condition ensures that a process is only flagged as having a serious leak when its memory consumption dominates the system's memory usage trend, thus avoiding the wrong accusation of a process with only a slight increase when the overall system load is high.

[0166] In summary, this triple verification mechanism significantly improves the confidence level of severe leakage determination through the joint constraints of three orthogonal dimensions: magnitude, persistence, and correlation.

[0167] This invention goes beyond isolated monitoring of a single process; it also introduces an adaptive response mechanism for system memory pressure. This mechanism, configured in the state decision layer, aims to address the technical problem of system crashes caused by lag in the response of standard detection logic when system resources are strained. This mechanism works by sensing the global system memory pressure status in real time (…). ), dynamically adjust the sensitivity of the judgment model and the detection path.

[0168] This mechanism is based on system memory usage. The operating modes are divided into standard mode, high-sensitivity mode and ultra-fast mode.

[0169] First, dynamic parameter adjustment in high-sensitivity mode. This is achieved when system memory usage... Within the warning range (i.e., 80%) When a memory leak occurs, it indicates that system memory resources are becoming strained, and the tolerance for memory leaks decreases. To intervene before irreversible consequences result, the system automatically enters a high-sensitivity mode and adjusts the following two parameters:

[0170] Threshold ratio reduction: Long-term growth threshold coefficient used to determine severe leakage LEVEL_3 The ratio was adjusted from 3.5 times under standard conditions to 2.1 times. This means that at this point, only the long-term growth rate of the process needs to be adjusted. Exceeding 2.1 times the dynamic baseline triggers the initial screening for a serious leak. The calculation formula is adjusted as follows:

[0171] ;

[0172] Confirmation time halved: To speed up the decision-making process, the system will use time for calculation... Long-term observation window The time span parameter is compressed. In this embodiment, the time span is reduced from the standard 300 seconds to 150 seconds. This means that the system calculates the growth trend based only on data from the most recent 150 seconds, thereby halving the time required to confirm a leak and enabling a faster early warning response.

[0173] Second, the rapid path determination in high-speed mode.

[0174] When system memory usage Reaching the critical interval (i.e.) When the system is about to run out of memory (OOM), it indicates a high risk that the system is about to run out of memory, and standard long-term trend analysis (such as 300-second or 150-second observations) is no longer sufficient to meet the needs of emergency stop-loss. At this time, the system activates a fast decision path, bypassing the standard multi-level decision and triple verification process.

[0175] In the fast decision-making process, the system performs a short-term, absolute burst detection. The system backtracks the process's memory records over the last 30 seconds and calculates its absolute growth. The determination logic is to compare the increase with the total available memory of the current system (…). Compare the results. If the following conditions are met:

[0176] ;

[0177] If a process's memory usage exceeds 5% of the system's remaining available memory within 30 seconds, the system determines that the process is engaging in highly destructive memory consumption. At this point, regardless of the process's historical baseline, the system will immediately classify the process as having a severe memory leak (LEVEL_3) and forcibly trigger the highest priority response output to prevent the risk from occurring within milliseconds before system crashes.

[0178] Through the aforementioned adaptive mechanism, this invention can maintain a low false alarm rate when system resources are abundant, while automatically switching to a high-sensitivity or high-response-speed protection mode when resources are scarce, thus achieving a dynamic balance between detection accuracy and system security.

Claims

1. A real-time memory leak detection method for QNX systems, characterized in that, The real-time memory leak detection method for QNX systems includes: S1. Establish a list of monitoring targets and set a global sampling time interval; S2. At the beginning of each sampling period, update the system memory pressure status of the current operating system, and collect the virtual memory size and resident memory size of each monitoring target process in the monitoring target list, and calculate the comprehensive memory index at the current moment. S3. Update the dynamic baseline of the monitored target process based on the comprehensive memory index, and calculate the dynamic growth threshold at the current moment in combination with historical deviations. S4. Based on the historical sequence of the comprehensive memory index, calculate the memory growth rate of the monitored target process in the three different time spans of short-term, medium-term and long-term, and calculate the memory leak acceleration. S5. Compare the memory growth rate under the three different time spans of short-term, medium-term and long-term with the dynamic growth threshold respectively, and combine the memory leakage acceleration and the system memory pressure status to determine the current leakage level of the monitored target process. The leakage level includes at least normal, suspected leakage, confirmed leakage and serious leakage. S6. When the determined leakage level changes, generate a log containing the process identifier, leakage level and timestamp or trigger a callback interface to respond and output.

2. The method for real-time memory leak detection in a QNX system according to claim 1, characterized in that, In step S2, calculating the comprehensive memory index at the current moment specifically includes: Obtain the current virtual memory size and resident memory size of the monitored target process; The virtual memory size and the resident memory size are assigned preset weighting coefficients respectively. The weighted virtual memory value and the weighted resident memory value are added together to obtain the comprehensive memory index. The calculated comprehensive memory metrics are stored in the historical data queue corresponding to the monitored target process.

3. The method for real-time memory leak detection in a QNX system according to claim 1, characterized in that, In step S3, calculating the dynamic growth threshold at the current moment includes: After the baseline learning period ends, the updated baseline value for the current time is calculated using the exponentially weighted moving average algorithm, based on the baseline value of the previous time step and the comprehensive memory index of the current time step. Obtain the historical maximum absolute deviation since monitoring started, calculate the sum of the updated baseline value and the weighted historical maximum absolute deviation, and obtain the basic dynamic growth threshold.

4. The real-time memory leak detection method for QNX systems according to claim 3, characterized in that, Step S3 also includes correcting the basic dynamic growth threshold to obtain the final dynamic growth threshold. The correction process includes: Determine whether the updated baseline value is lower than the preset small memory threshold. If so, use the preset small memory multiplier relaxation strategy to calculate the final dynamic growth threshold. If not, the recent memory volatility is further calculated. When the volatility is less than the preset stable value, the process is determined to be in a stable period. The basic dynamic growth threshold is amplified using the stability adjustment coefficient to obtain the final dynamic growth threshold. If the above correction is not triggered, the basic dynamic growth threshold will be used as the final dynamic growth threshold.

5. A real-time memory leak detection method for a QNX system according to claim 1, characterized in that, In step S4, the three different time spans are the short-term observation window, the medium-term observation window, and the long-term observation window, respectively. The calculation of memory leak acceleration specifically involves: calculating the difference between the instantaneous growth rate of the current sampling period and the instantaneous growth rate of the previous sampling period, and dividing the difference in instantaneous growth rates by the sampling interval duration to obtain the acceleration value; when the acceleration value exceeds a preset graded acceleration threshold, an acceleration alarm flag is generated.

6. The method for real-time memory leak detection in a QNX system according to claim 5, characterized in that, In step S5, the specific conditions for determining a suspected leak or confirmed leak are as follows: When the short-term memory growth rate exceeds the product of the dynamic growth threshold and the multiplier for suspected leakage determination, it is determined to be a suspected leak; When the intermediate memory growth rate exceeds the product of the dynamic growth threshold and the multiplier for confirming a leak, and the absolute memory growth within the intermediate observation window exceeds the preset noise filtering threshold, it is determined to be a confirmed leak.

7. A real-time memory leak detection method for a QNX system according to claim 5, characterized in that, In step S5, a serious leak must be determined to meet both the initial screening criteria and the triple verification mechanism. The initial screening criteria are: the long-term memory growth rate exceeds the product of the dynamic growth threshold and the multiplier coefficient for the serious leak determination. The triple verification mechanism must simultaneously meet the following conditions: First verification: The absolute increase in memory of the monitored target process within the long-term observation window exceeds a preset capacity threshold, and the proportion of the absolute increase to the current dynamic baseline exceeds a preset percentage. Second verification: Looking back at the most recent sampling periods, the memory value of all historical sampling points is not lower than the preset maintenance ratio of the memory value when the initial screening condition is first triggered; Third verification: The absolute increase in memory usage of the monitored target process as a percentage of the total memory increase of the operating system during the same period exceeds the preset contribution rate threshold.

8. A real-time memory leak detection method for a QNX system according to claim 7, characterized in that, Step S5 also includes an adaptive adjustment mechanism based on the system memory pressure status: When the system memory pressure status is in a warning state, the multiplier of the severe leakage judgment is reduced, and the time span of the long-term observation window is shortened; When the system memory pressure is critical, a fast judgment path is initiated: directly calculate the absolute growth of the monitored target process within a preset short window. If the ratio of the absolute growth to the current total available memory exceeds a preset critical threshold, it is directly judged as a serious leak, and the triple verification mechanism is skipped.

9. A real-time memory leak detection method for a QNX system according to claim 1, characterized in that, It also includes cyclical hibernation and resource control steps: Record the start and end timestamps of the current sampling period, and calculate the actual execution time of the current period; Calculate the difference between the global sampling time interval and the actual execution time; If the difference is greater than zero, the system sleep interface is called to suspend the current thread for a duration equal to the difference. If the difference is less than or equal to zero, the start timestamp is immediately reset and the next sampling period begins directly.

10. A real-time memory leak detection system for QNX systems, characterized in that, A real-time memory leak detection method for a QNX system includes: The state decision layer is used to perform system initialization and update the system memory pressure state in each sampling period; The system perception and data acquisition module is used to collect the virtual memory size and resident memory size of the monitored target process, and calculate the comprehensive memory index. The event analysis layer is used to maintain a dynamic baseline based on the comprehensive memory metrics, calculate the dynamic growth threshold, and calculate the memory growth rate and memory leak acceleration in parallel over short, medium and long time spans. The multi-level judgment module is used to determine the leakage level of the process according to the memory growth rate, dynamic growth threshold and system memory pressure status, and according to the preset priority logic. When a serious leakage is determined, triple verification including absolute incremental verification, continuous verification and system correlation verification is performed. The response output layer is used to generate hierarchical logs or trigger process status callback interfaces when the leakage level changes.

Images