Memory detection method of canary technology based on kernel extension of embedded system

Abstract

The invention relates to a memory detection method of a canary technology based on kernel extension of an embedded system, and belongs to the field of embedded systems. According to the method, a canary technology and an operating system kernel are deeply expanded, and a low-overhead detection mechanism is constructed by utilizing thread management, heap management and stack management, so that normalized memory defect detection of memory leakage, use after release and buffer overflow is ensured to be realized under the condition that resources are limited. Compared with a traditional canary technology, the method has the advantages that the coverage rate of defect detection is increased through deep expansion with an operating system, the coverage rate and performance overhead are effectively balanced, and normalized memory defect detection can be realized in an embedded environment with limited resources.

Description

TECHNICAL FIELD

[0001] The application belongs to the field of embedded systems, and particularly relates to a memory detection method based on canary technology of kernel extension of an embedded system. BACKGROUND

[0002] In the current digitalization process, embedded systems, as a key component of information infrastructure, have deeply integrated into all aspects of daily life, from smart home, automotive electronics to aerospace, national defense and other important fields. However, the development of embedded application software still faces many difficult problems, especially the problems of debugging and fault tracing, which have become the main obstacles to the improvement of system reliability and further development. Under such background, how to establish an efficient memory defect detection mechanism while ensuring real-time performance and meeting the demand of low power consumption has become a core issue to be tackled in this field. Canary detection technology, with the help of low resource consumption of sentinel monitoring method, can improve program security while effectively controlling performance overhead, so it has become an important direction worthy of in-depth exploration and optimization.

[0003] Canary technology is a dynamic monitoring method based on memory markers. Its core principle is to insert specific marker values (also known as "canary values") in the key areas of memory, and to identify memory security problems such as buffer overflow by continuously monitoring whether the value changes abnormally. This technology takes the "sentinel" mechanism as the core, deploys canary values around sensitive memory areas, and builds a protective barrier to block illegal access or malicious tampering. Its normal operation process is as follows: 1) Deploy canary values: Insert pre-set or randomly generated canary values at the boundaries of memory areas. Common deployment methods include inserting before the return address in the stack frame structure, or setting at the head and tail of dynamically allocated heap blocks.

[0004] 2) Check canary values: Before performing sensitive operations such as function return and memory release, check the consistency of canary values. For example, when a function is about to return, the program will verify whether the canary value in the stack frame is consistent with the inserted value; before the function returns, the canary value in the stack must be verified to ensure that it has not been modified; before releasing the heap memory, the head and tail marker values must be detected to ensure that they are intact.

[0005] 3) Abnormal response: Once the canary value is found to be incorrect, it is determined that there is a memory out-of-bound or overflow defect, and the system immediately performs abnormal processing to terminate the program to avoid further damage, and generates detailed error logs.

[0006] The key highlight of the technology is that it can realize memory monitoring and real-time response with low system overhead. The detection effect is highly dependent on the timing arrangement of the detection strategy. Too early or too frequent detection can cause false positives and bring additional performance burden, while too late detection can not effectively intercept attacks. Therefore, by reasonably setting the detection points on the critical path, the detection accuracy can be ensured while the impact on the system runtime performance is minimized.

[0007] The technology takes StackGuard as an example. Its implementation embeds the canary value in the stack frame position between the return address and the local variable. Each time the program executes before the return instruction, the canary value is verified. If the value does not change, the program executes normally; if an exception is found, the running is immediately suspended. The generation and verification mechanism of the canary value in StackGuard also continues to evolve: the early generation strategy uses random numbers; then it is improved to embed a specific terminator; further, the canary value is XORed with the return address, and the result is stored in a global comparison table, and the comparison is recalculated before each use of the return address, thereby establishing a more reliable verification system.

[0008] AddressSanitizer detects buffer overflow by inserting red zones between memory objects, and marks the recently released memory as a red zone to detect post-release use errors. Each time a memory operation is performed, ASan queries the shadow memory mapping table to ensure that the access does not exceed the legal area.

[0009] The first technology has the defect that the passive detection mechanism used may result in limited detection coverage. If you want to further improve the coverage, it often comes with an unacceptable increase in overhead. In addition, this technology mainly protects the stack memory and cannot effectively extend to the heap memory area, so there is a limitation in the detection range.

[0010] The second technology inserts additional check instructions before each memory read and write to achieve comprehensive monitoring of memory access. This mechanism can greatly reduce the execution efficiency of the program. At the same time, the technology inserts a protection zone for each memory allocation block and maintains a shadow memory mapping structure for the entire application address space, resulting in a significant increase in memory usage. This kind of resource consumption is often unacceptable in resource-constrained embedded environments, limiting its application feasibility in actual embedded scenarios. SUMMARY

[0011] (1) Technical problems to be solved The technical problem to be solved by the present application is how to provide a memory detection method based on an embedded system kernel extension canary technology to solve the problem of limited coverage of the passive detection mechanism of traditional canary technology and the difficulty of balancing detection range and system overhead.

[0012] (II) Technical solutions To solve the above technical problems, the application provides a memory detection method based on canary technology of embedded system kernel extension, which comprises the following steps: The canary detection logic is deeply integrated into the key interface of the operating system kernel, the detection trigger timing is extended, the real-time capture capability for overflow exceptions is improved, a hierarchical trigger strategy is introduced, the detection intensity is dynamically adjusted in different running scenarios, and the high coverage rate is ensured while the system overhead is maintained low. In terms of memory management, thread-related information is maintained through a hash table, memory allocation and release behaviors are continuously monitored, a linked list is used to manage memory block structures, memory overflow detection is realized in combination with canary values, a delayed release mechanism is introduced to identify the use error after release, and through the implementation of safety checks on the stack space, the safety level of memory operation and the thread management efficiency are improved.

[0013] (III) Advantages The application provides a memory detection method based on canary technology of embedded system kernel extension, which deeply extends the canary technology and the operating system kernel, uses thread management, heap management and stack management to build a low-overhead detection mechanism, and ensures the realization of normal memory defect detection for memory leaks, post-release use and buffer overflow under the condition of limited resources.

[0014] Compared with the traditional canary technology, the method deeply extends the operating system, improves the coverage rate of defect detection, effectively balances the coverage rate and performance overhead, and can realize normal memory defect detection in the resource-limited embedded environment. DETAILED DESCRIPTION

[0015] Figure 1 Fig. 1 is a kernel architecture diagram of the memory safety detection system of the application; Figure 2 Fig. 2 is a memory leak detection flowchart; Figure 3 Fig. 3 is a post-release use detection flowchart; Figure 4 Fig. 4 is an overflow detection flowchart; (a) is a system call interface case; (b) is a thread scheduling and destruction case. DETAILED DESCRIPTION

[0016] In order to make the purpose, content and advantages of the application clearer, the specific embodiments of the application will be further described in detail below in combination with the drawings and examples.

[0017] The purpose of the present application is to propose a dynamic memory detection method combining canary technology and deep cooperation of operating system kernel, which can efficiently and low-cost identify memory violation behaviors such as buffer overflow and post-release use, thereby overcoming the limitations of traditional canary technology, such as limited coverage of passive detection mechanism, difficult to balance detection range and system overhead.

[0018] The present application proposes a memory detection method based on canary technology of embedded system kernel extension, which is based on kernel-level extension based on canary technology, aiming to overcome many limitations of traditional canary method in embedded environment, such as limited coverage caused by passive detection mode, difficult to balance detection accuracy and system overhead, etc. The traditional method usually only checks at fixed nodes such as function return, and it is difficult to capture buffer overflow occurring during execution, and the risk of missed detection is high; at the same time, increasing the detection frequency will introduce unacceptable performance overhead, and it is difficult to balance safety and efficiency in resource-constrained embedded systems.

[0019] To solve the above problems, the present application integrates the canary detection logic deeply into the key interface of the operating system kernel, expands the detection trigger time, and makes it more suitable for the occurrence point of actual memory operation, thereby improving the real-time capture ability of overflow exception. At the same time, a hierarchical triggering strategy is introduced to dynamically adjust the detection intensity in different running scenarios, so as to maintain a low system overhead while ensuring high coverage. The specific implementation includes the following aspects: 1) Kernel key module integration: In order to break through the limitations of traditional canary technology relying on preset detection points (such as function return), this method modifies the operating system kernel and embeds the canary check mechanism into multiple core sub-modules, significantly expanding the detection range and frequency. Specifically, it includes: Memory management module: The detection code is implanted in the underlying memory allocation and release functions (such as malloc, free, calloc, etc.). In the allocation phase, canary value initialization and metadata recording (updated to global hash structure and delayed linked list) are completed, and in the release phase, the memory block is included in the delayed linked list for subsequent integrity audit.

[0020] Thread management module: For the common single-process multi-thread architecture of embedded systems, the detection mechanism is integrated into the core interface of thread scheduling and management (such as thread creation, scheduling switching and destruction). The canary and metadata are initialized when the thread is created; the comprehensive check is performed when the thread is destroyed, including leak detection, delayed linked list scanning and canary verification; the fast check is implemented when the thread is switched, including canary state check and delayed linked list light scanning.

[0021] 2) Hierarchical triggering strategy to balance coverage and overhead: In view of the characteristics of resource-constrained embedded systems, an elastic detection mechanism is designed, which dynamically selects the detection intensity according to the real-time requirements of the system running context: Lightweight detection: deployed in high-frequency operation paths (such as thread switching), performs fast check tasks, including canary effectiveness judgment and delay list preliminary scanning.

[0022] Heavyweight detection: triggered in low-frequency events, such as thread end or periodic system audit points, performs deep scanning and comprehensive verification, including complete metadata comparison, leakage analysis and delay list thorough inspection.

[0023] This strategy effectively disperses detection pressure, avoids performance bottlenecks, and balances real-time response and safety and reliability.

[0024] 3) Kernel state security and isolation guarantee: The detection mechanism runs completely in the operating system kernel state, not only has higher anti-attack ability itself, but also can realize the isolation of memory access in different threads to prevent cross-thread security pollution.

[0025] 4) Low-overhead detection mechanism implementation: The resource consumption is systematically reduced through the following techniques: Hierarchical triggering mechanism: clearly distinguish high and low frequency detection scenarios, limit performance sensitive operations to lightweight detection, and postpone heavy operations to non-real-time tasks.

[0026] Kernel built-in data structures and privileged operations: implement core structures such as delay list and hash table as kernel modules to avoid user-kernel state switching overhead.

[0027] Delay release and delay check mechanism: when releasing memory, do not immediately perform comprehensive inspection, but add it to the delay list and postpone integrity verification to subsequent appropriate detection points for execution, thereby decoupling release operation and high-overhead audit.

[0028] Metadata design: only key control information is retained, such as object first address, adjacent block address, total memory application amount and canary value, which significantly reduces additional memory occupancy.

[0029] The present application adopts a hash table structure to implement full life cycle monitoring of thread memory operations, accurately tracks memory allocation and release behavior by isolating memory data of different threads, and effectively supports dynamic detection of memory leakage and post-release use defects.

[0030] As a core management component of the system, the thread management method covers comprehensive control of the full life cycle of threads. In terms of memory management, the method maintains thread-related information through a hash table, continuously monitors memory allocation and release behavior, manages memory block structures using a linked list, implements memory overflow detection in combination with a canary value, and introduces a delay release mechanism to identify post-release use errors. At the same time, by implementing safety checks on stack space, the overall safety level of memory operations and thread management efficiency are improved.

[0031] In terms of memory management, to ensure memory efficiency and security, this method employs a dual-block isolation allocation strategy, records the allocation and release information of memory blocks in each thread, combines canary values ​​for overflow detection, and utilizes a delayed release mechanism to systematically identify defects such as memory leaks, buffer overflows, and post-release usage. Specifically, the system performs statistics during memory allocation and release phases to identify potential leaks, inserts canary values ​​at the beginning and end of each memory block for overflow detection, and uses a delayed release linked list to capture post-release usage errors.

[0032] The memory leak detection mechanism dynamically tracks memory allocation and deallocation operations to accurately identify memory blocks that are not properly released during runtime. Based on a thread-level memory management architecture, this mechanism relies on a global hash table to record memory operation status in real time, enabling proactive monitoring and rapid location of memory leaks. The specific process is as follows: S11. Thread creation and initialization: When a new thread is created, the system uses its unique identifier—the thread ID—as the key to create a corresponding new entry in the global hash table for subsequent tracking of the thread's memory operations.

[0033] S12. Memory Allocation Record: When the malloc function is called to allocate memory, in addition to returning the allocated memory address, the system also records that address in the hash table entry corresponding to the current thread ID. Simultaneously, the allocated memory size is accumulated in the total_allocated variable to track the total memory allocated by this thread.

[0034] S13. Memory Release Processing: When calling `free` to release a memory block, its starting address must be provided. The system queries the corresponding memory block from the heap management structure based on this address and obtains its size. Then, it deletes the record related to this address from the hash table entry of the current thread, adds the size of the released memory to the `total_freed` variable, and updates the total amount of released memory.

[0035] S14. Memory Leak Detection During Thread Destruction: Before a thread is destroyed, the system checks its memory usage by comparing the values ​​of total_allocated and total_freed. If they match, there is no memory leak; if they do not match, a leak is detected. In this case, the system will traverse all unreleased memory block records in the thread's hash table and output their detailed information for diagnosis.

[0036] After the memory is freed, a detection mechanism is used to proactively identify illegal behaviors such as accessing memory again or double-freeing memory through a strategy combining delayed freeing, pointer marking, and memory block integrity verification. The specific steps are as follows: S21, release request verification: when a free function is called to release a memory block, the system first verifies the validity of the provided address and checks whether the memory block already exists in the delayed release chain table. If it does, it is determined to be a double release error; otherwise, it proceeds to the next step.

[0037] S22, delayed release and memory overwrite: the memory block to be released is added to the delayed release chain table, and its original data content is filled with a specific canary value (such as zero) to destroy the original data semantics and enhance the ability to identify abnormal access.

[0038] S23, pointer marking: the original pointer to the memory block is forcibly converted to a specific value.

[0039] S24, thread scheduling memory content check: when thread scheduling, the system scans each memory block in the delayed release chain table to detect whether its content has been modified. If the canary value is found to have changed, it is determined that a post-release use defect has occurred.

[0040] S25, thread comprehensive verification and cleaning: when the thread is destroyed, the system performs integrity checks on all memory blocks in the delayed release chain table to confirm whether they have been illegally written. Once modification is found, a post-release use error is reported. After completing all checks, the memory blocks are safely released and the chain table is emptied.

[0041] The buffer overflow detection mechanism identifies illegal write behavior to memory blocks in real time through strategies such as isolating memory layout, verifying canary values, and dynamically monitoring memory content. This mechanism, combined with verification of canary values at the beginning and end of heap blocks and XOR verification of adjacent memory regions, effectively prevents data destruction or security vulnerabilities caused by buffer overflows at key nodes such as memory allocation, sensitive function calls, release operations, and thread scheduling and destruction. The specific steps are as follows: S31, monitoring initialization at thread creation: whenever a new thread is created, the system registers a new entry in the global hash table using its thread ID as the key, which continuously records the allocation and release status of all memory blocks within the thread, providing context for subsequent overflow detection.

[0042] S32, protection setting at memory allocation: when malloc is called to allocate memory, the system inserts canary values before and after the user's available data area in the allocated memory block to create a protection area for subsequent detection of whether write out-of-bound has occurred.

[0043] S33, immediate verification after high-risk operations: after calling safe_strcat, safe_strcpy, and other security-enhanced functions that may trigger overflow operations, immediately perform integrity checks on the canary values at the beginning and end of the target memory block to ensure that no overflow has occurred.

[0044] S34, canary verification before memory release: when calling free to release a certain memory block, the system locates the corresponding heap block information according to the provided address, and first checks whether the head and tail canary values are modified, and confirms that there is no overflow, and then continues the release process.

[0045] S35, cycle check when thread scheduling: when thread switching, the system traverses all allocated memory blocks of the thread through the hash table, checks the integrity of the canary value one by one, and performs exclusive or operation on adjacent memory blocks to verify content consistency. At the same time, check whether the preset canary value at the end of the thread stack is tampered with.

[0046] S36, comprehensive audit when thread is destroyed: before the thread is destroyed, the system performs a thorough check on all memory blocks that have not been released, including canary value check and adjacent block exclusive or content comparison, and finally verifies the canary marker in the thread stack again. Any abnormality indicates that heap overflow or stack overflow has occurred. Key points of the present application: The present application expands the canary technology deeply with the operating system kernel, uses thread management, heap management and stack management to build a low-overhead detection mechanism, and ensures the realization of normalized memory defect detection for memory leakage, release after use and buffer overflow under the condition of limited resources.

[0047] Advantages of the present application: Compared with the traditional canary technology, the method improves the coverage rate of defect detection by deeply expanding with the operating system, and effectively balances the coverage rate and performance overhead, so that the normalized memory defect detection can be realized in the resource-limited embedded environment. The above is only the preferred embodiment of the present application, it should be pointed out that for ordinary skilled in the art, without departing from the technical principles of the present application, can make a number of improvements and deformation, these improvements and deformation also should be regarded as the protection scope of the present application.

Claims

1. A memory detection method based on canary technology for embedded system kernel extensions, characterized in that, The method includes: The canary detection logic is deeply integrated into the key interface of the operating system kernel, expanding the detection triggering timing and improving the real-time capture capability of overflow exceptions; a hierarchical triggering strategy is introduced to dynamically adjust the detection intensity under different operating scenarios, so as to maintain low system overhead while ensuring high coverage. In terms of memory management, a hash table is used to maintain thread-related information, continuously monitor memory allocation and release behavior, use linked lists to manage memory block structure, combine canary values ​​to implement memory overflow detection, and introduce a delayed release mechanism to identify errors in use after release; at the same time, by implementing safety checks on the stack space, the overall security level of memory operations and thread management efficiency are improved.

2. The memory detection method based on the canary technique of embedded system kernel extension as described in claim 1, characterized in that, Key interfaces for deeply integrating canary detection logic into the operating system kernel include: By extending the operating system kernel, the canary verification mechanism is embedded into multiple core sub-modules, specifically including: Memory management module: Detection code is embedded in the underlying memory allocation and deallocation functions; during the allocation phase, canary value initialization and metadata recording are completed, and during the deallocation phase, memory blocks are added to a delayed linked list for subsequent integrity auditing; Thread Management Module: Integrates the detection mechanism into the core interface of thread scheduling and management. When a thread is created, the canary and metadata are initialized; when a thread is switched, fast verification is performed, including canary state check and light scan of the delayed linked list; when a thread is destroyed, a comprehensive check is performed, including leak detection, delayed linked list scan and canary verification.

3. The memory detection method based on the canary technique of embedded system kernel extension as described in claim 1, characterized in that, Tiered triggering strategies include: Lightweight detection: Deployed on high-frequency operation paths to perform rapid inspection tasks, including canary validity judgment and preliminary scanning of delayed linked lists; Heavyweight detection: Triggered by low-frequency events, it performs deep scanning and comprehensive verification, including full metadata comparison, leakage analysis and thorough inspection of delayed linked lists; A tiered triggering mechanism is adopted: clearly distinguishing between high-frequency and low-frequency detection scenarios, restricting performance-sensitive operations to lightweight detection, and postponing heavyweight operations to non-real-time tasks.

4. The memory detection method based on canary technology for embedded system kernel extension as described in claim 1, characterized in that, The core structures of delayed linked lists and hash tables are implemented as kernel modules to avoid the overhead of switching between user mode and kernel mode.

5. The memory detection method based on canary technology for embedded system kernel extension as described in claim 1, characterized in that, When freeing memory, instead of performing a full check immediately, the memory is added to a deferred list, postponing integrity verification to a later, more appropriate checkpoint.

6. The memory detection method based on canary technology for embedded system kernel extension as described in claim 1, characterized in that, Metadata retains only critical control information.

7. The memory detection method based on the canary technique of embedded system kernel extension as described in any one of claims 1-6, characterized in that, Memory management specifically includes: adopting a dual-block isolation allocation strategy, recording the allocation and release information of memory blocks in each thread, using canary values ​​for overflow detection, and employing a delayed release mechanism to systematically identify memory leaks, buffer overflows, and post-release usage; the system performs statistics during memory allocation and release phases to identify memory leaks, inserts canary values ​​at the beginning and end of each memory block to achieve overflow detection, and uses a delayed release linked list to capture post-release usage errors.

8. The memory detection method based on the canary technique of embedded system kernel extension as described in claim 7, characterized in that, Memory leak detection identifies memory blocks that are not properly released during runtime by dynamically tracking memory allocation and deallocation operations. This mechanism is based on a thread-level memory management architecture and relies on a global hash table to record memory operation status in real time, enabling proactive monitoring and rapid location of memory leaks. The specific process is as follows: S11. Thread creation and initialization: When a new thread is created, the system uses its unique identifier, i.e., the thread ID, as the key to create a corresponding new entry in the global hash table for subsequent tracking of the thread's memory operations. S12. Memory allocation record: When the malloc function is called to allocate memory, in addition to returning the allocated memory address, the system will also record the address in the hash table entry corresponding to the current thread ID; at the same time, the allocated memory size will be accumulated in the total_allocated variable to count the total amount of memory allocated by the thread. S13. Memory release processing: When the free function is called to release memory, the system queries the corresponding memory block from the heap management structure based on the starting address provided by the free function and performs a series of address checks. Then, the block is placed in the delayed release list, and the record related to the address is deleted from the hash table entry of the current thread. The size of the released memory is added to the total_freed variable, and the total amount of released memory is updated. S14. Memory leak detection during thread destruction: Before a thread is destroyed, the system checks its memory usage and compares the values ​​of total_allocated and total_freed. If they match, there is no memory leak. If they do not match, a leak is detected. At this time, the system will traverse all unreleased memory block records in the thread's hash table entry and output their detailed information for diagnosis.

9. The memory detection method based on the canary technique of embedded system kernel extension as described in claim 7, characterized in that, After the memory is freed, a strategy combining delayed freeing, pointer marking, and memory block integrity verification is used to proactively identify illegal behaviors such as accessing memory after it has been freed or freeing it again. The specific steps are as follows: S21. Release Request Verification: When the free function is called to release a memory block, the system first verifies the validity of the provided address and checks whether the memory block already exists in the delayed release list; if it already exists, it is determined to be a double-free error. Otherwise, proceed to the next step; S22, Delayed Release and Memory Overwrite: Add the memory block to be released to the delayed release list, and fill its original data content with a specific canary value to destroy the original data semantics and enhance the ability to identify abnormal access. S23, Pointer Mark: Casts the raw pointer to the memory block to a specific value; S24. Thread scheduling memory content check: During thread scheduling, the system scans each memory block in the delayed release list to check whether its content has been modified; if the canary value is found to have changed, it is determined that a post-release use defect has occurred. S25. Thread-wide verification and cleanup: When a thread is destroyed, the system performs an integrity check on all memory blocks in the delayed release list to confirm whether they have been illegally written to. If any modification is found, an error in post-release usage is reported. After all checks are completed, these memory blocks are safely released and the list is cleared.

10. The memory detection method based on the canary technique of embedded system kernel extension as described in claim 7, characterized in that, Buffer overflow detection employs strategies such as isolating memory layout, verifying canary values, and dynamically monitoring memory content to identify illegal write operations to memory blocks in real time. This mechanism combines verification of the canary values ​​at the beginning and end of heap blocks with XOR checks of adjacent memory regions during memory allocation, sensitive function calls, deallocation operations, and thread scheduling and destruction. The specific steps are as follows: S31. Monitoring initialization during thread creation: Whenever a new thread is created, the system registers a new entry in the global hash table with its thread ID as the key. This entry is used to continuously record the allocation and release status of all memory blocks within the thread, providing context for subsequent overflow detection. S32. Protection settings during memory allocation: When calling malloc to request memory, the system inserts canary values ​​before and after the user-available data area in the allocated memory block to build a protection area for subsequent detection of whether out-of-bounds writes have occurred. S33. Immediate verification after high-risk operations: After calling the security enhancement function that may cause an overflow operation, immediately perform an integrity check on the canary values ​​at the beginning and end of the target memory block to ensure that no overflow has occurred. S34. Canary verification before memory release: When calling free to release a memory block, the system locates the corresponding heap block information based on the provided address, and first checks whether its first and last canary values ​​have been modified. Only after confirming that there is no overflow will the release process continue. S35. Periodic checks during thread scheduling: When switching threads, the system traverses all allocated memory blocks of the thread through a hash table, verifies the integrity of its canary value one by one, and performs an XOR operation on adjacent memory blocks to verify content consistency; at the same time, it checks whether the preset canary value at the end of the thread's stack has been tampered with. S36. Comprehensive auditing during thread destruction: Before a thread is destroyed, the system performs a thorough check on all its unreleased memory blocks, including canary value verification and XOR comparison of adjacent blocks, and finally re-verifies the canary flag in the thread stack; any exception indicates that a heap overflow or stack overflow has occurred.

Images