Kernel stack printing method and device, equipment and storage medium

By detecting the running time of the target task or the interrupt time of the off-time in the CPU core and setting the threshold to print the kernel stack, the problem of inaccurate kernel stack printing in the existing technology is solved, and the accuracy of fault analysis and the stability of the operating system are improved.

CN120447845APending Publication Date: 2025-08-08ZHAOQING XIAOPENG NEW ENERGY INVESTMENT CO LTD
View PDF 5 Cites 0 Cited by

Patent Information

Application Number
CN202510536466.1
Authority / Receiving Office
CN · China
Patent Type
Applications(China)
Current Assignee / Owner
Filing Date
2025-04-25
Publication Date
2025-08-08

AI Technical Summary

Technical Problem

The prior art is difficult to accurately identify abnormal tasks in the CPU core by printing the kernel stack, resulting in misleading fault analysis and affecting the stability and performance of the operating system.

Method used

By obtaining the running time of the target task in the process context or interrupt context or the interrupt duration, set the exception task determination conditions, and print the kernel stack when the threshold exceeds the threshold to provide a basis for fault detection.

Benefits of technology

Accurate positioning and fault analysis of abnormal tasks is achieved, the stability of the operating system and the accuracy of fault detection are improved, and the possibility of misjudgment is reduced.

✦ Generated by Eureka AI based on patent content.

Smart Images

  • Figure CN120447845A_ABST
    Figure CN120447845A_ABST
Patent Text Reader

Abstract

The embodiment of the invention discloses a kernel stack printing method and device, equipment and a storage medium, the method is applied to a target core of terminal equipment, the method comprises the steps that task information of a target task running in the target core is obtained, and the task information comprises the running duration of the target task running in a process context or the running duration of the target task running in the process context; the target task runs in the interruption closing duration of the interruption context; under the condition that the task information meets an abnormal task determination condition, a kernel stack of the target task is printed, the kernel stack is used for fault detection, and the abnormal task determination condition includes that the running duration is larger than or equal to a preset first duration threshold value, or the shutdown duration is larger than or equal to a preset second duration threshold value. The target task running abnormally in the target core can be determined in time, and the kernel stack of the target task is printed to provide a basis for fault detection.
Need to check novelty before this filing date? Find Prior Art

Description

Technical Field

[0001] The embodiments of the present application relate to the field of computer technology, and relate to, but are not limited to, a kernel stack printing method and apparatus, device, and storage medium. Background Art

[0002] With the advancement of technology and increasing demands, operating systems are placing increasingly stringent demands on the real-time and stability of task scheduling. Abnormal execution of tasks within the central processing unit (CPU) core, such as those that occupy computing resources for extended periods or block critical processes, can lead to degraded operating system performance or even crashes. Therefore, detecting and analyzing abnormal tasks within the core is crucial to ensuring stable and efficient operating system operation.

[0003] In related technologies, to prevent some tasks in the CPU core from occupying computing resources for a long time and affecting the scheduling of other tasks, it is possible to detect the running time of high-priority tasks, such as real-time (RT) tasks, per unit time. When the running time exceeds a set threshold, the scheduling of such tasks is restricted and the kernel stack is printed to ensure stable operation of the operating system and assist in subsequent fault detection. However, because the CPU core may switch between multiple high-priority tasks per unit time, it is difficult to determine the location of the anomaly through the printed kernel stack, which may mislead subsequent fault analysis. Summary of the Invention

[0004] In view of this, the kernel stack printing method, apparatus, device, and storage medium provided in the embodiments of the present application can promptly identify the target task that is running abnormally in the target core, and print the kernel stack of the target task to provide a basis for fault detection. The kernel stack printing method, apparatus, device, and storage medium provided in the embodiments of the present application are implemented as follows:

[0005] A first aspect of the present application provides a kernel stack printing method, which is applied to a target kernel of a terminal device, and comprises:

[0006] Acquire task information of a target task running in the target core, wherein the task information includes a running time of the target task running in a process context, or a disabled interrupt time of the target task running in an interrupt context;

[0007] When the task information satisfies the abnormal task determination condition, the kernel stack of the target task is printed, and the kernel stack is used for fault detection, wherein the abnormal task determination condition includes that the running time is greater than or equal to a preset first time threshold, or that the interruption shutdown time is greater than or equal to a preset second time threshold.

[0008] By implementing the above technical solution, it is possible to determine whether the operation of the target task is abnormal by detecting the running time of the target task running in the target core in the process context or the interrupt-off time running in the interrupt context, and print out the kernel stack of the target task in abnormal circumstances, which helps to quickly locate abnormal tasks in the operating system, provide a basis for fault detection, and improve the accuracy of fault analysis.

[0009] As an optional implementation manner, in the first aspect of the embodiment of the present application, when the target task is running in a process context, obtaining the task information of the target task running in the target core includes:

[0010] Obtaining a start time of the target task running in the target core;

[0011] The running time is obtained by periodically triggering a preset clock interrupt and calculating the difference between the time when the clock interrupt is triggered and the start time.

[0012] By implementing the above technical solution and periodically triggering clock interrupts, the running time of the target task in the target core can be updated in real time, ensuring real-time monitoring of the running status of the target task, thereby quickly locating abnormal situations.

[0013] As an optional implementation, in the first aspect of the embodiment of the present application, the abnormal task determination condition includes that the runtime is greater than or equal to the first duration threshold, and when the task information satisfies the abnormal task determination condition, printing the kernel stack of the target task includes:

[0014] When the clock interrupt is triggered and the running time is greater than or equal to the first time threshold, the kernel stack of the target task is printed according to the preset printing rules, wherein the printing rules include printing the kernel stack of the target task when the running time is greater than or equal to the first time threshold for the first time, or printing the kernel stack of the target task according to a preset printing cycle.

[0015] By implementing the above technical solution, the kernel stack can be printed when the target task's runtime reaches or exceeds the first duration threshold for the first time, promptly capturing information on the scene of abnormal task operation and avoiding missing the abnormal scene. The kernel stack can also be printed periodically to continuously monitor abnormal tasks and support fault analysis.

[0016] As an optional implementation, in the first aspect of the embodiment of the present application, the task information further includes a process shutdown duration of the target task running in the process context, the abnormal task determination condition further includes that the process shutdown duration is greater than or equal to a preset third duration threshold, and the method further includes:

[0017] When the target task is interrupted, the running time and the interruption-disabled time of the process are obtained;

[0018] When the runtime is greater than or equal to the first duration threshold, or when the interruption-disabled duration of the process is greater than or equal to the third duration threshold, the kernel stack of the target task is printed.

[0019] By implementing the above technical solution, when the target task turns on interrupts, it is possible to obtain the running time of the target task in the process context and the process interruption-off time. If either of these two time lengths exceeds the corresponding preset threshold, the kernel stack of the target task is triggered to print, thereby realizing comprehensive task anomaly detection.

[0020] As an optional implementation manner, in the first aspect of the embodiment of the present application, when the target task is running in an interrupt context, obtaining the task information of the target task running in the target core includes:

[0021] Obtaining the shutdown interruption time of the target task;

[0022] In the case where the target task is interrupted, an interruption-on time is obtained, a difference between the interruption-on time and the interruption-off time is calculated, and the interruption-off duration is obtained.

[0023] By implementing the above technical solution, it is possible to monitor the target task's interruption-off time in the interrupt context and obtain the interruption-on time when the target task is interrupted, thereby obtaining the target task's interruption-off duration, providing a reliable basis for fault detection.

[0024] As an optional implementation, in the first aspect of the embodiment of the present application, the abnormal task determination condition includes that the interrupt shutdown duration is greater than or equal to the second duration threshold, and when the task information meets the abnormal task determination condition, printing the kernel stack of the target task includes:

[0025] When the target task enables interrupts and the interrupt-disabling duration is greater than or equal to the second duration threshold, the kernel stack of the target task is printed.

[0026] By implementing the above technical solution, after the target task turns on the interrupt, it is determined whether the interruption-off duration is greater than or equal to the second duration threshold, and the kernel stack is printed when the abnormal task determination conditions are met. It can be executed without waiting for the arrival of a new clock interrupt, thereby improving the accuracy of fault detection.

[0027] As an optional implementation, in the first aspect of the embodiment of the present application, after printing the kernel stack of the target task, the method further includes:

[0028] When multiple kernel stacks of the target task are printed, determining whether the multiple kernel stacks are the same;

[0029] In the case that there are at least two identical kernel stacks among the multiple kernel stacks, the at least two identical kernel stacks are parsed to obtain fault information corresponding to the target task.

[0030] By implementing the above technical solution, if at least two identical kernel stacks are found when multiple kernel stacks are printed, it can be interpreted as the target task running for a long time and blocked in the same function or code segment. By parsing these two identical kernel stacks, fault information for the target task can be obtained, such as the top function or function call path, improving the accuracy of fault detection.

[0031] A second aspect of the present application provides a kernel stack printing device, which is applied to a target kernel of a terminal device, comprising:

[0032] an acquisition module, configured to acquire task information of a target task running in the target core, wherein the task information includes a running time of the target task running in a process context, or a disabled interrupt time of the target task running in an interrupt context;

[0033] A printing module is used to print the kernel stack of the target task when the task information meets the abnormal task determination condition, and the kernel stack is used for fault detection, wherein the abnormal task determination condition includes that the running time is greater than or equal to a preset first time threshold, or that the interruption shutdown time is greater than or equal to a preset second time threshold.

[0034] A third aspect of the present application provides a computer device, including a memory and a processor, wherein the memory stores a computer program that can be run on the processor, and when the processor executes the program, the method described in the first aspect or the second aspect of the embodiment of the present application is implemented.

[0035] In a fourth aspect, the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the method provided in the first or second aspect of the embodiment of the present application is implemented.

[0036] Compared with the related art, the embodiments of the present application have the following beneficial effects:

[0037] The kernel stack printing method provided in this application is applied to the target core of the terminal device. By detecting the task information of a single target task running in the target core, it can accurately locate abnormal tasks and print out the kernel stack of the target task for fault analysis, which helps to reduce the possibility of misjudgment and improve the stability and reliability of the operating system. BRIEF DESCRIPTION OF THE DRAWINGS

[0038] The drawings herein are incorporated into and constitute a part of the specification. These drawings illustrate embodiments consistent with the present application and, together with the specification, are used to illustrate the technical solutions of the present application.

[0039] Figure 1 A schematic diagram of the structure of a terminal device provided in an embodiment of the present application;

[0040] Figure 2 A schematic diagram of a process flow of a kernel stack printing method provided in an embodiment of the present application;

[0041] Figure 3 A schematic diagram of a kernel stack provided in an embodiment of the present application;

[0042] Figure 4 A flowchart showing a target task running in a process context in a kernel stack printing method provided in an embodiment of the present application;

[0043] Figure 5 A schematic diagram of triggering the printing of a kernel stack in the kernel stack printing method provided in an embodiment of the present application;

[0044] Figure 6 A flowchart of a target task running in an interrupt context in a kernel stack printing method provided in an embodiment of the present application;

[0045] Figure 7 A schematic diagram of a process for obtaining fault information from the kernel stack of a target task in the kernel stack printing method provided in an embodiment of the present application;

[0046] Figure 8 Another flowchart of the kernel stack printing method provided in an embodiment of the present application;

[0047] Figure 9 A schematic diagram of the structure of the kernel stack printing device provided in an embodiment of the present application;

[0048] Figure 10 A schematic diagram of the structure of a computer device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0049] To make the purpose, technical solutions and advantages of the embodiments of the present application clearer, the specific technical solutions of the present application will be further described in detail below in conjunction with the drawings in the embodiments of the present application. The following embodiments are used to illustrate the present application but are not intended to limit the scope of the present application.

[0050] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which this application pertains. The terms used herein are for the purpose of describing the embodiments of this application only and are not intended to limit this application.

[0051] In the following description, reference is made to “some embodiments”, which describes a subset of all possible embodiments, but it will be understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0052] It should be pointed out that the terms "first\second\third" involved in the embodiments of the present application are used to distinguish similar or different objects, and do not represent a specific ordering of the objects. It can be understood that "first\second\third" can be interchanged with a specific order or sequence where permitted, so that the embodiments of the present application described here can be implemented in an order other than that illustrated or described here.

[0053] In computer technology, a central processing unit (CPU) core is an independent computing unit within a physical processor. Multi-core CPUs (such as dual-core and quad-core CPUs) contain multiple cores, each capable of independently executing instructions, enabling parallel computing and improving processing efficiency. The operating system kernel is the core component of the operating system, responsible for managing operating system resources (such as the CPU, memory, and I / O devices) and providing services such as task scheduling, memory management, and file systems.

[0054] Because the number of CPU cores is limited relative to the number of tasks in an operating system, and an operating system typically has multiple tasks that need to run, the kernel is required to schedule tasks to properly allocate the computing resources of the CPU cores and ensure that each task receives the appropriate execution time to meet the needs of different application scenarios. However, during the task scheduling process, tasks may run abnormally. For example, if some tasks occupy the computing resources of the CPU core for a long time (such as being stuck in an infinite loop or not properly giving up time slices), other tasks may be unable to execute or their execution may be delayed, ultimately causing performance issues such as operating system lag and reduced resource scheduling efficiency.

[0055] In the related art, in order to prevent high-priority tasks, such as real-time (RT) tasks, from monopolizing the CPU core for a long time and affecting the scheduling and execution of other tasks, thereby causing the operating system to be blocked. The kernel can limit the running time of such high-priority tasks. For example, when it is detected that the running time of a high-priority task exceeds the set threshold, the high-priority task is terminated to ensure the smooth execution of other tasks and the stable operation of the operating system. Among them, RT tasks refer to tasks in the operating system that have strict requirements on response time, and are usually used in scenarios that require fast processing, such as audio / video stream processing, industrial control, etc. High-priority tasks can also include system service tasks, key business logic tasks, and tasks that need to respond quickly to user input. However, since the CPU core may switch multiple high-priority tasks in a unit of time, it is difficult to determine the location of the exception through the printed kernel stack, which may mislead subsequent fault analysis.

[0056] In view of this, an embodiment of the present application provides a kernel stack printing method and apparatus, equipment, and storage medium, which can promptly determine the target task running abnormally in the target core, and print the kernel stack of the target task to provide a basis for fault detection.

[0057] The following describes the application scenarios of the kernel stack printing method provided in the embodiments of the present application.

[0058] See also Figure 1 , Figure 1 A schematic diagram of the structure of the terminal device provided in the embodiment of the present application. Figure 1 The terminal device shown may include components such as a processor 110 , a memory 120 , a transceiver 130 , a display unit 140 , and an input unit 150 .

[0059] Processor 110 is the control center of the electronic device, connecting all parts of the electronic device using various interfaces and circuits. By running or executing software programs and / or modules stored in memory 120 and accessing data stored in memory 120, it performs various electronic functions and processes data, thereby providing overall monitoring of the electronic device. Optionally, processor 110 may include one or more processing units; alternatively, processor 110 may integrate an application processor, which primarily handles operating devices, user interfaces, and application programs. Of course, other processors may also be included, which are not listed here.

[0060] The memory 120 can be used to store software programs and modules. The processor 110 executes various electronic functional applications and data processing by running the software programs and modules stored in the memory 120. The memory 120 can mainly include a program storage area and a data storage area. The program storage area can store operating devices and applications required for at least one function (such as a sound playback function, an image playback function, etc.); the data storage area can store data created based on the use of the electronic device (such as audio data, a phone book, etc.). In addition, the memory 120 can include high-speed random access memory and non-volatile memory, such as at least one disk storage device, a flash memory device, or other volatile solid-state storage device.

[0061] The transceiver 130 can provide wireless communication solutions for electronic applications, including wireless local area networks (WLAN), Bluetooth (BT), global navigation satellite system (GNSS), frequency modulation (FM), near-field communication (NFC), infrared (IR), and the like. The transceiver 130 can be one or more devices integrating at least one communication processing module, for example, integrating an antenna and a baseband processor into the transceiver 130, or integrating an antenna and a modem processor into the transceiver 130, etc., without limitation herein.

[0062] The display unit 140 can be used to display information input by the user or information provided to the user, as well as various electronic menus. The display unit 140 can be configured in the form of a liquid crystal display (LCD), an organic light emitting diode (OLED), etc., without limitation.

[0063] The input unit 150 can be used to receive input digital or character information, and to generate key signal inputs related to electronic user settings and function controls. Specifically, the input unit 150 can collect user operations on or near it, and drive the corresponding connection device according to a pre-set program. In addition, the input unit 150 may include a touch panel, which can be implemented using various types such as resistive, capacitive, infrared, and surface acoustic wave. In addition to the touch panel, the input unit 150 may also include other input devices. Specifically, other input devices may include, but are not limited to, one or more of function keys (such as volume control buttons, switch buttons, etc.), trackballs, joysticks, etc.

[0064] The electronic device may also include components such as at least one sensor, an audio circuit, and a power module. For example, the at least one sensor may be a gyroscope, a motion sensor, or other sensors. The audio circuit may include a speaker and a microphone, providing an audio interface between the user and the electronic device. The power module may be logically connected to the processor 110 via a power management device, thereby enabling the power management device to manage charging, discharging, and power consumption, among other functions, without limitation herein.

[0065] It is understood that the structures illustrated in the embodiments of the present application do not constitute specific limitations on the terminal device. In other embodiments of the present application, the terminal device may include more or fewer components than shown, or may combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0066] Optionally, the above-mentioned terminal devices may include but are not limited to wearable devices (such as smart bracelets, smart watches, smart glasses, etc.), mobile phones, tablet computers, laptops or servers, etc., which are not limited here.

[0067] Normally, the above Figure 1 The terminal device shown needs to be equipped with a corresponding operating system and run based on the operating system. The terminal device operating system can be Android, iOS, or Linux, etc., without limitation. The operating system kernel can monitor the running time of high-priority tasks and terminate the task when the running time of such tasks exceeds a set threshold to ensure the execution of other lower-priority tasks and ensure stable operation of the operating system.

[0068] For example, in a Linux system, the RT-Throttle policy can be used to limit the cumulative running time of RT tasks to prevent them from excessively occupying the computing resources of the CPU core. For example, by detecting the running time of RT tasks, if the running time of RT in a unit time (1 second) on the CPU core exceeds a set threshold (such as 950 milliseconds), the kernel stack can be printed for fault analysis and the corresponding management mechanism can be triggered to allow other tasks to obtain the opportunity to run, thereby maintaining the stability and responsiveness of the system.

[0069] However, when adopting strategies such as RT-Throttle to detect abnormal operation of high-priority tasks, since all tasks of a specific type are detected, it is possible that high-priority task A running successively in the CPU core has been running for 940 milliseconds, high-priority task B has been running for 5 milliseconds, and high-priority task C is running and has been running for 5 milliseconds. This can be understood as a significant abnormality in high-priority task A. However, according to strategies such as RT-Throttle, if the threshold is set to 950 milliseconds, the CPU's currently running tasks, that is, the kernel stack of high-priority task C, will only be printed during the running of high-priority task C. This makes it difficult to accurately identify the true abnormal task and easily leads to misjudgment.

[0070] In order to accurately identify abnormal tasks and analyze and optimize them, the kernel stack printing method provided in this application can determine the target task running abnormally in the target core, and print the kernel stack of the target task to provide a basis for fault detection. The kernel stack printing method provided in this application will be introduced in conjunction with the accompanying drawings below to better understand the implementation process of the kernel stack printing method.

[0071] See also Figure 2 , Figure 2 A flowchart of a kernel stack printing method provided in an embodiment of the present application is provided. The kernel stack printing method can be applied to a target kernel of a terminal device, such as Figure 2 As shown, the method may include the following steps:

[0072] S201 , obtaining task information of a target task running in a target core, wherein the task information includes a running time of the target task running in a process context, or an interrupt-disabled time of the target task running in an interrupt context.

[0073] In an embodiment of the present application, a terminal device may be provided with multiple processor cores, and the target core of the terminal device is one of the multiple processor cores. A target task refers to a task instance running on the target core that requires anomaly detection using the kernel stack printing method provided in this application.

[0074] For example, the target core can be a CPU core of a terminal device, and the target task can be a thread task or a process task running in the CPU core. A thread can be considered as part of a process, describing the execution state of an instruction stream and being the smallest unit of the instruction execution stream in a process.

[0075] It's important to note that when the terminal device's operating system is Linux, the processor core (e.g., the physical CPU core) and kernel (the software operating system kernel) do not distinguish between threads and processes when processing tasks. Threads can be considered a special type of process and are managed and scheduled as schedulable entities. Other operating systems, such as Windows, treat threads and processes differently, and threads have their own unique data structures, which are not discussed here.

[0076] In an embodiment of the present application, the acquired task information of the target task includes the running time of the target task running in the process context, or the interrupt-disabled time of the target task running in the interrupt context.

[0077] It's important to note that operating systems have two different contexts: process context and interrupt context. Interrupts don't have process context, but they do have interrupt context. Therefore, sleep, or task switching, cannot occur in interrupt context. An interrupt is when a situation arises during the operation of a terminal device that requires intervention. The device automatically stops the currently running program and switches to a program to handle the new situation. After processing is complete, the device returns to the originally paused program and continues execution. Process context may also be referred to as task context or thread context, but this is not limited here.

[0078] When the target task runs in the process context, it can be understood that the target task runs in the normal execution process, has independent memory space and complete scheduling information, and can perform various calculations or wait operations. Common tasks running in the process context may include tasks corresponding to services such as web browsers, word processors, and media players. When the target task runs in the interrupt context, it can be understood that the target task needs to complete the corresponding processing work in a very short time to ensure the stable operation and efficient collaboration of the entire system. Common tasks running in the interrupt context may include tasks corresponding to services such as keyboard input processing, mouse event response, network data packet reception and transmission processing, disk I / O operations, etc., which are not limited here.

[0079] In some possible embodiments, before obtaining the task information of the target task running in the target core, the kernel stack printing method provided by the present application may further include: determining the target context in which the target task is located, wherein the target context includes a process context or an interrupt context.

[0080] In embodiments of the present application, it is possible to determine whether a target task is running in a process context or an interrupt context in a variety of ways. For example, it is possible to determine whether a target task is running in a process context or an interrupt context by detecting an identifier of the target task, detecting the current interrupt status of the target core, or detecting scheduling information of the target task.

[0081] Optionally, when determining the context of the target task by detecting the identifier of the target task, different tasks can be assigned unique identifiers, and the judgment is made by checking whether the identifier of the target task belongs to a predefined interrupt context identifier set. If the identifier of the target task is in the interrupt context identifier set, it can be determined that the target task is running in the interrupt context; otherwise, it is considered to be running in the process context.

[0082] In some possible embodiments, when the target task is running in a process context,

[0083] Optionally, when the context of the target task is determined by detecting the current interrupt status of the target core, the current interrupt status of the target core can be obtained by calling a specific function or accessing a specified storage area. The target core can record the execution status of the soft interrupt and hard interrupt of each CPU core. If it is detected that the target core is in the interrupt processing process, the target task is determined to be running in the interrupt context; if the target core is not in the interrupt processing state, the target task is determined to be running in the process context.

[0084] Optionally, when determining the context of the target task by detecting the scheduling information of the target task, since tasks in the process context usually have relatively complete scheduling information, including but not limited to time slices, priorities, scheduling policies, etc., while tasks in the interrupt context are mainly used to quickly respond to interrupt requests and usually do not have complete scheduling information. It is possible to determine whether the task is running in the process context or the interrupt context by checking whether the target task is assigned a time slice or whether it has a clear scheduling priority. In addition, since tasks in the process context are usually included in the scheduling queue for management and scheduling, while tasks in the interrupt context are usually not, it is also possible to assist in determining its context by checking whether there is a record of the task in the scheduling queue, which is not limited here.

[0085] It should be noted that determining the context of the target task by detecting the identifier of the target task, detecting the current interrupt status of the target core, or detecting the scheduling information of the target task is only an example and does not constitute a limitation on the method provided in this application. In actual applications, the context environment of the target task can be determined by other methods such as checking the real-time status of the operating system, which is not limited here.

[0086] In an embodiment of the present application, when the target task runs in a process context, the task information may include the runtime of the target task running in the process context. When the target task runs in an interrupt context, the task information may include the interrupt-off duration of the target task running in the interrupt context.

[0087] It should be noted that the runtime of the target task in the process context may indicate the duration from the start of execution of the target task to the timing instant, and may be obtained through timing functions provided by the operating system, hardware timers, system monitoring tools, and the like, without limitation herein.

[0088] The interrupt-disabled duration of the target task running in the interrupt context may indicate the length of time from when the target task enters the interrupt context and disables interrupts to when interrupts are re-enabled. The interrupt-disabled duration can be obtained by detecting the moment when the target task turns interrupts on and off. For example, the interrupt flag bit can be monitored for changes, or an interrupt can be triggered to determine whether the target task is in the interrupt-disabled state. This is not limited to the following methods.

[0089] In some possible embodiments, the target task is a high-priority task, for example, a real-time task in a terminal device that is typically latency-sensitive and requires timely response and processing. Fault analysis of the high-priority target task helps improve the stability of the target core when invoking the target task.

[0090] S202, when the task information meets the abnormal task determination conditions, print the kernel stack of the target task, and the kernel stack is used for fault detection, wherein the abnormal task determination conditions include the running time being greater than or equal to the preset first time threshold, or the interruption-disabled time being greater than or equal to the preset second time threshold.

[0091] In an embodiment of the present application, when the task information meets the abnormal task determination conditions, the kernel stack of the target task is printed. For example, when the target task is running in a process context, if the obtained target task running in the process context has a runtime greater than or equal to a preset first duration threshold, it is determined that the task information meets the abnormal task determination, and the kernel stack of the target task is printed. When the target task is running in an interrupt context, if the obtained target task running in the interrupt context has an interrupt off duration greater than or equal to a preset second duration threshold, it is determined that the task information meets the abnormal task determination, and the kernel stack of the target task is printed.

[0092] It's important to note that the kernel stack is a memory area used to store information such as function calls, local variables, and register states while the corresponding task is running in the processor core. Each task has its own independent kernel stack. As the task executes, the contents of the kernel stack evolve continuously as functions are called. For example, when a task calls a specific function, the parameters, local variables, and other information associated with the function are pushed onto the kernel stack. This allows the operating system to use the kernel stack to ensure that the task continues executing from the point of interruption or switchover during context switching or interrupt recovery. The kernel stack also provides a reference for analyzing issues such as blocking and scheduling delays during task exception analysis.

[0093] To understand how information is stored in the kernel stack, see Figure 3 , Figure 3 A schematic diagram of the kernel stack provided in the embodiment of the present application is shown as follows: Figure 3 As shown, for the target task running in the target core of the terminal device, its function calling relationship can be function 1 calling function 2, function 2 calling function 3, where function 1 can be the first function called when the target task runs in the target core.

[0094] It should be noted that before function 1 starts running, the target core will set a stack top (Stacktop) and a corresponding stack bottom (Stackfloor) for function 1. Figure 3 As shown in part (A), when function 1 starts executing, the stack pointer sp moves down, and the difference between it and the top of the stack is the stack space required for the local variables in function 1. Figure 3 As shown in part (B), when function 1 calls function 2, the stack pointer sp will move down again, and the newly added area is the stack space required for the local variables in function B. Figure 3 As shown in part (C), if function 2 calls function 3, the stack pointer sp will continue to move down, and the increased area is the stack space required for the local variables in function 3.

[0095] By printing the kernel stack of the target task, terminal devices or developers can quickly identify the execution status and call path of the target task, so as to promptly discover potential problems, locate the root cause of the fault and take effective repair measures, thereby ensuring stable operation and performance optimization of the system.

[0096] In some possible embodiments, the kernel stack of the target task may be printed by using a kernel debugging tool or a preset printing function when the task information meets the abnormal task determination condition.

[0097] In some possible embodiments, the kernel stack of the printed target task can be stored in a specified path in the form of a preset log file, or stored in the internal memory of the terminal device or a specified area of an external storage device for subsequent detailed analysis and troubleshooting.

[0098] For example, when storing in a log file, such log file usually has a fixed storage path and format to ensure that relevant data can be quickly retrieved and interpreted. For example, log files may be named and archived according to date, timestamp or task name, and stored in a specific log directory of the terminal device. This allows developers to accurately locate and solve abnormal problems in the system. When stored in a designated area of an internal memory or external storage device, the internal memory can be a high-speed storage device such as a flash memory or a solid-state drive (SSD), which can provide fast read and write speeds to ensure timely recording of log data. External storage devices may include external hard drives, network attached storage (NAS), cloud storage services, etc. These devices can provide larger storage capacity and data backup functions, facilitating long-term storage and analysis of a large number of kernel stacks.

[0099] The kernel stack printing method provided in the embodiment of the present application can determine whether the operation of the target task is abnormal by detecting the running time of the target task running in the target core in the process context or the interrupt-off time of the target task running in the interrupt context, and print out the kernel stack of the target task in an abnormal situation, which helps to quickly locate abnormal tasks in the operating system, provide a basis for fault detection, and improve the accuracy of fault analysis.

[0100] The following will introduce the situation in which the target task runs in the process context in the kernel stack printing method with reference to the accompanying drawings, so as to better understand the implementation process of the kernel stack printing method.

[0101] See also Figure 4 , Figure 4 A flowchart of a target task running in a process context in a kernel stack printing method provided in an embodiment of the present application is provided. The kernel stack printing method can be applied to a target kernel of a terminal device, such as Figure 4 As shown, the method may include the following steps:

[0102] S401, obtaining the start time of the target task running in the target core.

[0103] In some possible embodiments, when the target task is running in a process context, obtaining task information of the target task running in the target core includes:

[0104] Get the start time of the target task running in the target core;

[0105] By periodically triggering a preset clock interrupt, the difference between the time when the clock interrupt is triggered and the start time is calculated to obtain the running time.

[0106] It should be noted that obtaining the start time of the target task running on the target core can be achieved in a variety of ways. For example, a preset function can be used to record the start time when the target task begins executing on the target core. For example, the preset function can be a hook function pre-installed in the kernel scheduler. When the hook function detects that the target task has been scheduled to run on the target core, it can call a high-precision timing function provided by the kernel or read the value of a hardware timer to obtain the current time and record it as the start time of the target task. This method can accurately capture the start time of the target task running on the target core, providing reliable time information for subsequent exception monitoring and analysis. Alternatively, the start time of the target task starting execution on the target core can be recorded by triggering an interrupt. The interrupt mechanism is a mechanism whereby a specific event triggers an interrupt signal, notifying the CPU and pausing the current task, allowing the interrupt service routine to process. When the target task begins executing, a hardware device (such as a hardware timer) can be used to generate an interrupt signal, and the current time can be recorded in the interrupt service routine.

[0107] S402 , periodically triggering a preset clock interruption, calculating the difference between the time when the clock interruption is triggered and the start time, and obtaining the running time.

[0108] In some possible embodiments, when a clock (tick) interrupt is triggered periodically, the difference between the time when the clock interrupt is triggered and the start time is obtained, and the running time of the target task each time the clock interrupt is triggered is obtained.

[0109] It should be noted that the start time of the target task and the time when each clock interrupt is triggered can be the terminal device's system timestamp. The system timestamp is typically a global counter maintained by the operating system that records the elapsed time since system startup. It can be read through system calls or specific hardware instructions. The microsecond or nanosecond level depends on the hardware support of the terminal device and the design of the operating system, and is not limited here. In addition, the preset clock interrupt period can be flexibly configured according to actual needs. For example, the preset clock interrupt period can be 4 milliseconds or 8 milliseconds, etc., which is not limited here.

[0110] In some possible embodiments, the task information also includes an interrupt count of the target task running in the process context. Exemplarily, when it is detected that the target task starts running in the process context, the interrupt count of the target task is determined to be zero. And by periodically triggering a preset clock interrupt, the clock count when the clock interrupt is triggered is obtained. Exemplarily, each time the clock interrupt is triggered, the interrupt count is added by 1 to obtain an updated interrupt count, that is, at the first clock interrupt after the target task starts running, the clock count is 1, and at the second clock interrupt, the clock count is 2, thereby obtaining an accurate interrupt count. In this way, there is no need to calculate the difference between the time when the clock interrupt is triggered and the start time, which simplifies the calculation process.

[0111] S403, when the running time is greater than or equal to the first time threshold, printing the kernel stack of the target task according to the preset printing rules, wherein the printing rules include printing the kernel stack of the target task when the running time is greater than or equal to the first time threshold for the first time, or printing the kernel stack of the target task according to a preset printing cycle.

[0112] It should be noted that, when the task information includes the runtime of the target task running in the process context, if the runtime is greater than or equal to the first duration threshold, it can be understood that the target task may have an exception. At this time, by printing the kernel stack, the function call information of the current task can be obtained to help analyze the execution status and potential problems of the task. For example, if the task runs for too long, it may be due to an infinite loop, resource waiting timeout, etc. Printing the kernel stack can provide the current call link of the task, which is convenient for quickly locating the root cause of the problem. Among them, the first preset duration can be flexibly set according to the sensitivity requirements of the anomaly detection. For example, the preset first duration threshold can be 100 milliseconds, 150 milliseconds or 200 milliseconds, etc., which are not limited here.

[0113] In some possible embodiments, the printing rule may be to print the kernel stack of the target task when the running time is greater than or equal to the first time length threshold for the first time. In this way, the kernel stack will be printed at most once during the running process of the target task for fault analysis.

[0114] For example, when the preset first duration threshold is 100 milliseconds, the running duration of the target task is periodically updated through the preset clock interrupt. After a clock interrupt is triggered, if the detected running duration has reached or exceeded 100 milliseconds, the system will print the kernel stack of the target task according to the preset printing rules.

[0115] In some possible embodiments, the printing rule can be to print the kernel stack of the target task according to a preset printing period. In this way, if the target task's running process is greater than or equal to the first duration threshold, and the target task continues to run for a long time, the kernel stack at multiple different times can be accurately printed, which helps to comprehensively analyze whether the target task is stuck in a long-term running state due to resource competition, frequent blocking, etc., thereby providing data basis for troubleshooting and solving problems.

[0116] It should be noted that a single period of the preset printing cycle may be the same as or different from the preset first duration threshold. For example, in the case where a single period of the preset printing cycle may be the same as the preset first duration threshold and is 100 milliseconds. The target task will trigger printing of the kernel stack once if it runs for 100ms. In the case where a single period of the preset printing cycle may be different from the preset first duration threshold, the first duration threshold and the preset printing cycle may be flexibly set. For example, the first duration threshold is 100 milliseconds and the preset printing cycle is 50, so as to increase the frequency of kernel stack printing after determining that the target task is abnormal, and provide richer data support for subsequent fault analysis and problem location. It is also possible that a single period of the clock preset printing cycle is greater than the first duration threshold, which is not limited here.

[0117] See also Figure 5 , Figure 5 A schematic diagram of triggering the printing of the kernel stack in the kernel stack printing method provided in an embodiment of the present application, such as Figure 5 As shown, the preset first duration threshold is 100 milliseconds, the preset printing period is 50 milliseconds, and the target task ends at 280 milliseconds. The target core can print out a total of five kernel stacks at 100 milliseconds, 150 milliseconds, 200 milliseconds, and 250 milliseconds for fault analysis.

[0118] It should be noted that for ease of understanding Figure 5 The duration information in is a relative duration. In actual applications, the start time and the subsequent time for determining whether to print can be the standard time of the system clock. In addition, in actual applications, the end time of the target task may not be obtained, which is not limited here.

[0119] In some possible embodiments, the set first preset duration and preset printing cycle can be integer multiples of the clock interruption cycle. In this way, after each clock interruption, it can be ensured that the obtained running duration can match the first preset duration and the preset printing cycle. For example, when the clock interruption cycle is 5 milliseconds, the first preset duration is set to 100 milliseconds and the preset printing cycle is set to 50 milliseconds, so that the running duration after the clock interrupt is triggered will immediately trigger the printing of the kernel stack after reaching the moment corresponding to the first preset duration or the preset printing cycle, thereby improving the accuracy and timeliness of the kernel stack printing.

[0120] In some possible embodiments, when the running time is greater than or equal to the first time threshold, printing the kernel stack of the target task according to a preset printing rule includes:

[0121] At the next moment after the clock interrupt is triggered, if the running time is greater than or equal to the first time threshold, the kernel stack of the target task is printed according to a preset printing rule.

[0122] It is understandable that after any clock interrupt is triggered, it should be immediately determined whether the running time is greater than or equal to the first time threshold and whether it complies with the preset printing rules, so as to decide whether to print the kernel stack. In this way, it is possible to avoid problems that may be caused by making a judgment after a period of time after the clock interrupt. For example, if the judgment is delayed, the target task may call a new function or change the execution state during this period, resulting in the printed kernel stack information not accurately reflecting the actual state of the target task at the time the time threshold is reached, thereby affecting the accuracy of the fault analysis.

[0123] In some possible embodiments, determining whether the runtime is greater than or equal to a first duration threshold by a preset first interrupt function, and printing the kernel stack of the target task according to a preset printing rule. If the runtime is greater than or equal to the first duration threshold, printing the kernel stack of the target task according to the preset printing rule includes:

[0124] At the next moment when the clock interrupt is triggered, according to the preset first interrupt function, it is determined whether the running time of the target task meets or exceeds the first time threshold, and if the running time is greater than or equal to the first time threshold, a sneak peek is taken and the kernel stack of the target task is printed according to the preset printing rules.

[0125] It can be understood that the judgment of whether the running time of the above-mentioned target task meets or exceeds the first time threshold, and the printing of the target task kernel stack can be performed in the preset first interrupt function. By triggering the interrupt, it is ensured that the printed kernel stack can accurately reflect the running status of the target task when an abnormality is detected.

[0126] In some possible embodiments, when the task information further includes an interrupt count of the target task running in the process context, the abnormal task determination condition further includes that the interrupt count is greater than or equal to a preset count threshold. When the task information satisfies the abnormal task determination condition, printing the kernel stack of the target task includes:

[0127] When the interrupt count is greater than or equal to a preset count threshold, the kernel stack of the target task is printed according to a preset printing rule. The printing rule includes printing the kernel stack of the target task when the interrupt count is greater than or equal to the preset count threshold for the first time, or printing the kernel stack of the target task at a preset count interval. The preset technical threshold and the preset count interval can be flexibly set as needed and are not described in detail here.

[0128] In some possible embodiments, the task information further includes a process shutdown duration during which the target task runs in a process context, and the abnormal task determination condition further includes a process shutdown duration being greater than or equal to a preset third duration threshold. The kernel stack printing method provided in the present application further includes:

[0129] When the target task is interrupted, obtain the running time and the interruption-disabled time of the process;

[0130] When the runtime is greater than or equal to the first duration threshold, or when the process interruption-disabled duration is greater than or equal to the third duration threshold, the kernel stack of the target task is printed.

[0131] It should be noted that when the target task is running in the context of a process, it may be necessary to enable or disable interrupts to call certain important functions to ensure that the function execution is not interrupted. Since the target core cannot trigger a clock interrupt to obtain the running time or the process's interrupt-disabled time when interrupts are disabled, a hook function or other mechanism can be used to obtain the current time of the hardware timer when interrupts are enabled for the target task, thereby obtaining the running time and the process's interrupt-disabled time. When any of these conditions meet the threshold, the kernel stack will be printed.

[0132] In the above technical solution, when the target task is running in the process context, by periodically triggering the clock interrupt, the running time of the target task in the target core can be updated in real time, ensuring real-time monitoring of the running status of the target task, and printing the kernel stack when the running time of the target task reaches or exceeds the first time threshold for the first time, so as to capture the on-site information of the abnormal operation of the task in time, thereby quickly locating the abnormal situation and helping to ensure the stable operation of the operating system.

[0133] The following will introduce the situation where the target task runs in the interrupt context in the kernel stack printing method with reference to the accompanying drawings, so as to better understand the implementation process of the kernel stack printing method.

[0134] See also Figure 6 , Figure 6 A flowchart of a target task running in an interrupt context in a kernel stack printing method provided in an embodiment of the present application is provided. The kernel stack printing method can be applied to a target kernel of a terminal device, such as Figure 6 As shown, the method may include the following steps:

[0135] S601, obtaining the shutdown interruption time of the target task.

[0136] In some possible embodiments, when the target task is running in an interrupt context, obtaining task information of the target task running in the target core includes:

[0137] Get the shutdown time of the target task;

[0138] When the target task is interrupted, the interruption time is obtained, the difference between the interruption time and the interruption time is calculated, and the interruption duration is obtained.

[0139] It's important to note that in related technologies, for tasks running in interrupt context, timing functions such as update_curr_rt can be used to determine whether the task has timed out and then print the kernel stack based on the timeout. However, since other functions cannot execute when interrupts are disabled, and timing functions have inherent triggering cycles when interrupts are enabled, they won't execute immediately. This can miss the actual function that caused the exception, potentially leading to the printed kernel stack not being the one that occurred.

[0140] In some possible embodiments, in order to obtain the accurate kernel stack when the target task is running in the interrupt context and an exception occurs for fault analysis, a pre-installed hook function can be used to detect the interrupt status of the target task in real time. When an interrupt-disable event is detected, the current time of the hardware timer is recorded as the interrupt-disable time; when an interrupt-enable event is detected, the current time of the hardware timer is recorded as the interrupt-enable time.

[0141] Exemplarily, the pre-mounted hook function can detect whether the target task executes the switch interrupt function. For example, in a Linux system, the pre-mounted hook function can detect the state of the target task switch interrupt by detecting whether the target task executes the interrupt disable function local_irq_disable or the interrupt enable function local_irq_ensable.

[0142] In some possible embodiments, the interruption status of the target task can also be monitored in real time using kernel debugging tools or performance analysis tools, etc. These tools can generally provide detailed interrupt information, including the time when the interrupt is disabled and enabled, which is not limited here.

[0143] S602: When the target task is interrupted, obtain the interruption enabling time, calculate the difference between the interruption enabling time and the interruption disabling time, and obtain the interruption disabling duration.

[0144] In some possible embodiments, a pre-installed hook function or kernel debugging tool can be used to obtain the interrupt enable time when the target task is detected to be interrupt-enabled, and then determine whether to print the kernel stack of the target task based on the obtained interrupt disable time. In this way, accurate time information can be obtained in a timely manner when the target task is interrupt-enabled, avoiding errors in printing the kernel stack due to delayed recording.

[0145] S603: When the target task has interrupts enabled and the interrupt-disabled duration is greater than or equal to a second duration threshold, print the kernel stack of the target task.

[0146] In some possible embodiments, the abnormal task determination condition includes that the interruption disablement duration is greater than or equal to a second duration threshold. When the task information satisfies the abnormal task determination condition, printing the kernel stack of the target task includes:

[0147] When the target task has interrupts enabled and the interrupt-disabled duration is greater than or equal to the second duration threshold, the kernel stack of the target task is printed.

[0148] It should be noted that if the abnormal task determination condition includes the interrupt-disable duration being greater than or equal to the second duration threshold, then if the interrupt-disable duration is greater than or equal to the second duration threshold, it can be understood that the target task may be abnormal. In this case, by printing the kernel stack, function call information of the current task can be obtained to help analyze the task's execution status and potential problems. The preset second duration threshold can be set to 100 milliseconds, 150 milliseconds, or 200 milliseconds, etc., without limitation here.

[0149] In some possible embodiments, the difference between the interruption-enabling time and the interruption-disabling time can be calculated by a preset second interruption function to obtain the interruption-disabling duration, and when the interruption of the target task is enabled and the interruption-disabling duration is greater than or equal to the second duration threshold, the kernel stack of the target task is printed.

[0150] It should be noted that when the target core determines that the target task is interrupted and obtains the interruption-enabling time through a pre-mounted hook function or kernel debugging tool, the second interrupt function can be called to implement the subsequent abnormal task determination condition judgment and kernel stack printing process to ensure that the printed kernel stack can accurately reflect the running status of the target task when the abnormality is detected.

[0151] In some possible embodiments, when the interrupt disabling duration is greater than or equal to the second duration threshold, the kernel stack printing method provided by the present application further includes:

[0152] Control the target core to call the target task multiple times;

[0153] For each call to the target task, when the interruption-disabled duration is greater than or equal to the second duration threshold, the kernel stack of the target task is printed.

[0154] It's understandable that, unlike when a task runs in process context, when a task runs in interrupt context, the interrupt-disabled duration is typically only available once during a single task lifecycle. Therefore, stress testing can be performed by controlling the target core to call the target task multiple times, increasing the number of kernel stacks captured. This allows for more comprehensive monitoring and analysis of exceptions in the target task within the interrupt context, helping to improve the target task based on the anomaly analysis results and enhance the stability and reliability of the operating system.

[0155] In the above technical solution, when the target task is running in the interrupt context, the target task's interruption-off time can be monitored, and the interruption-on time can be obtained in a timely manner when the target task is interrupted. Then, the interruption-off duration of the target task can be calculated, providing a reliable basis for fault detection. After the target task is interrupted, by determining whether the interruption-off duration exceeds a second duration threshold, the kernel stack is printed in a timely manner when the abnormal task identification conditions are met, without waiting for a new clock interrupt, thereby improving the accuracy of task fault detection.

[0156] The following will introduce a method for obtaining fault information of a target task according to a kernel stack in the kernel stack printing method with reference to the accompanying drawings, so as to better understand the implementation process of the kernel stack printing method.

[0157] See also Figure 7 , Figure 7 A flowchart of a kernel stack printing method for a target task in an embodiment of the present application to obtain fault information is provided. The kernel stack printing method can be applied to a target kernel of a terminal device, such as Figure 7 As shown, the method may include the following steps:

[0158] S701: Obtain task information of a target task running in a target core.

[0159] S702: When the task information satisfies the abnormal task determination condition.

[0160] S703: When multiple kernel stacks of the target task are printed, determine whether the multiple kernel stacks are the same.

[0161] In some possible embodiments, after printing the kernel stack of the target task, the kernel stack method further includes:

[0162] When multiple kernel stacks of the target task are printed, determining whether the multiple kernel stacks are the same;

[0163] In the case that there are at least two identical kernel stacks among the multiple kernel stacks, the at least two identical kernel stacks are parsed to obtain fault information corresponding to the target task.

[0164] It's important to note that when multiple kernel stacks are identical, it can be understood that a fault, such as an infinite loop or resource contention, may have occurred during the printing of multiple kernel stacks in the target task. By analyzing these identical kernel stacks, the cause of the fault can be more accurately located, providing strong support for troubleshooting and improving operating system stability.

[0165] In some possible embodiments, in order to avoid the function for obtaining the task information of the target task running in the target core and the function for judging whether the task information meets the abnormal task determination conditions from being printed into the kernel stack, which affects the judgment of whether multiple kernel stacks are the same, these functions can be set as interrupt functions so that their function information appears in the interrupt stack, ensuring the purity of the kernel stack and avoiding interference with the analysis of the actual running status of the target task.

[0166] It should be noted that the function that obtains task information for the target task running in the target core and the function that determines whether the task information meets the abnormal task determination criteria can be different parts of the same function, and this is not limited here. By setting these functions as interrupt functions, the relevant information during their execution will be recorded on the interrupt stack instead of the kernel stack, thus ensuring the accuracy of the kernel stack and improving the reliability of fault analysis.

[0167] In some possible embodiments, when multiple kernel stacks of a target task are printed, determining whether the multiple kernel stacks are identical may include: preprocessing the multiple kernel stacks after printing the multiple kernel stacks of the target task, and determining whether the multiple preprocessed kernel stacks are identical. The preprocessing includes deleting, from each kernel stack, the function for obtaining task information of the target task running in the target core, and the function information related to the function for determining whether the task information satisfies abnormal task determination criteria, thereby preserving the original function call relationships and related parameters of the target task, preventing abnormal task detection and printed function information from affecting abnormality analysis, and improving the accuracy of fault analysis.

[0168] S704 : When there are at least two identical kernel stacks among the multiple kernel stacks, parse the at least two identical kernel stacks to obtain fault information corresponding to the target task.

[0169] In some possible embodiments, after printing the kernel stack of the target task, the kernel stack printing method provided by the present application further includes:

[0170] Parse the kernel stack to obtain the fault information corresponding to the target task.

[0171] It should be noted that the kernel stack can be parsed and processed locally by the terminal device after the target task is completed, or the kernel stack can be sent to the server, parsed and processed using the server's computing resources, and fault information returned by the server can be received. This is not limited here.

[0172] In some possible embodiments, when there are at least N identical kernel stacks in multiple kernel stacks, at least N identical kernel stacks are parsed to obtain fault information corresponding to the target task, where N is an integer greater than or equal to 2, and the value of N can be determined based on the number of multiple kernel stacks and the first duration threshold, the preset printing cycle, or the second duration threshold, and is not limited here.

[0173] In some possible embodiments, N is set to 2. When the target task is running in a process context, it may run for a long time. For example, after exceeding the first time threshold, multiple kernel stacks may be printed after multiple preset printing cycles. If there are at least two identical kernel stacks among the multiple kernel stacks, it can be understood that during the printing of at least two identical kernel stacks, the target task may have encountered a problem in the same execution state, such as a dead loop in some functions instead of normal function progress. By parsing these identical kernel stacks, the function call or execution path that caused the problem can be more accurately located, thereby providing key information for in-depth analysis and troubleshooting.

[0174] In some possible embodiments, N takes a value of 2. When the target task runs in an interrupt context, the target task can be run multiple times to perform a stress test, thereby printing out multiple kernel stacks. If there are at least two identical kernel stacks among the multiple kernel stacks, it can be understood that the target task may have encountered similar abnormal situations during multiple runs. The accuracy of fault location can be improved by parsing these identical kernel stacks.

[0175] In some possible embodiments, after determining whether multiple kernel stacks are the same, the kernel stack printing method provided by the present application further includes:

[0176] When there are at least two kernel stack groups among multiple kernel stacks, the at least two kernel stack groups are parsed to obtain at least two fault information corresponding to the target task, wherein each kernel stack group includes at least M identical kernel stacks, and M is an integer greater than or equal to 2.

[0177] It's important to note that a target task running on a target core may experience multiple failures during execution, leading to prolonged pauses. By analyzing multiple kernel stack groups, we can identify different failure messages, providing a comprehensive understanding of the target task's anomalies and providing support for remediation.

[0178] In some possible embodiments, at least two identical kernel stacks are parsed to obtain fault information corresponding to the target task, which may include, but is not limited to, the kernel stack's top function, function call relationships, local variable values, global variable values, or register parameter information. This allows developers to quickly locate potentially abnormal functions or parameter values based on the fault information and perform targeted optimizations on the target task, thereby effectively improving the stability and operational efficiency of the operating system.

[0179] In some possible embodiments, after printing the kernel stack of the target task, the kernel stack printing method provided by the present application further includes:

[0180] When a kernel stack of a target task is printed, the kernel stack is parsed to obtain fault information corresponding to the target task.

[0181] It should be noted that, when only one kernel stack is printed, the execution status and potential problems of the target task can also be obtained by parsing the single kernel stack, providing support for the diagnosis of the target task.

[0182] In some possible embodiments, the kernel stack printing method provided by the present application further includes:

[0183] When the target task is running in the process context and the running time is greater than or equal to the preset fourth time threshold, terminate the running of the target task; or

[0184] When the target task is running in the interrupt context and the interruption-disabled duration is greater than or equal to a preset fifth duration threshold, the running of the target task is terminated.

[0185] It should be noted that the fourth and fifth duration thresholds can be set based on actual needs and can be the same or different. In this way, the target task can be ensured not to take too long to execute on the target core, thus avoiding prolonged resource occupation that prevents other tasks from being executed in a timely manner, thereby improving the overall responsiveness and stability of the system.

[0186] In the above technical solution, by analyzing the kernel stack mechanical energy, detailed fault information can be provided to developers. The fault information can cover multiple levels, from the top of the stack function to the local variable value, which facilitates the location and repair of the target task fault.

[0187] See also Figure 8 , Figure 8 Another flowchart of the kernel stack printing method provided in the embodiment of the present application is provided. The kernel stack printing method can be applied to the target kernel of the terminal device, such as Figure 2 As shown, the method may include the following steps:

[0188] S801: Determine a target context of a target task, where the target context includes a process context or an interrupt context.

[0189] S802: When the target context is a process context, obtain the start time of the target task running in the target core.

[0190] S803 , periodically triggering a preset clock interruption, calculating the difference between the time when the clock interruption is triggered and the start time, and obtaining the running time.

[0191] S804, when the running time is greater than or equal to the first time threshold, print the kernel stack of the target task according to the preset printing rules, wherein the printing rules include printing the kernel stack of the target task when the running time is greater than or equal to the first time threshold for the first time, or printing the kernel stack of the target task according to a preset printing cycle.

[0192] It should be noted that the implementation process of S802 to S804 is similar to that of S401 to S403 and will not be repeated here.

[0193] S805: When the target context is an interrupt context, obtain the interruption disabling time of the target task.

[0194] S806: When the target task is interrupted, obtain the interruption enabling time, calculate the difference between the interruption enabling time and the interruption disabling time, and obtain the interruption disabling duration.

[0195] S807 : When the target task has interrupts enabled and the interrupt-disabled duration is greater than or equal to the second duration threshold, print the kernel stack of the target task.

[0196] It should be noted that the implementation process of S805 to S807 is similar to that of S601 to S603, and will not be repeated here.

[0197] S808: Analyze the kernel stack to obtain fault information corresponding to the target task.

[0198] It should be noted that the implementation process of S808 is similar to that of S704 and will not be repeated here.

[0199] By implementing the above technical solution, it is possible to promptly identify the target task that is running abnormally in the target core, print the kernel stack of the target task and perform fault analysis, thereby improving the stability and reliability of the operating system.

[0200] It should be understood that, although the steps in the above-mentioned flowcharts are shown in sequence according to the instructions of the arrows, these steps are not necessarily performed in sequence in the order indicated by the arrows. Unless otherwise specified herein, there is no strict order restriction on the execution of these steps, and these steps can be performed in other orders. Moreover, at least a portion of the steps in the above-mentioned flowcharts may include multiple sub-steps or multiple stages, and these sub-steps or stages are not necessarily performed at the same time, but can be performed at different times, and the execution order of these sub-steps or stages is not necessarily to be performed in sequence, but can be performed in turn or alternately with other steps or at least a portion of the sub-steps or stages of other steps.

[0201] Based on the foregoing embodiments, an embodiment of the present application provides a kernel stack printing device, which includes the modules included and the units included in each module, and can be implemented by a processor; of course, it can also be implemented by a specific logic circuit; in the implementation process, the processor can be a central processing unit (CPU), a microprocessor (MPU), a digital signal processor (DSP) or a field programmable gate array (FPGA), etc.

[0202] See also Figure 9 , Figure 9 A schematic diagram of the structure of the kernel stack printing device provided in the embodiment of the present application is shown as follows: Figure 9 As shown, kernel stack printing includes an acquisition module 901 and a printing module 902, wherein:

[0203] The acquisition module 901 is used to acquire task information of a target task running in a target core, wherein the task information includes the running time of the target task running in a process context, or the interruption-disabled time of the target task running in an interrupt context.

[0204] Printing module 902 is used to print the kernel stack of the target task when the task information meets the abnormal task determination conditions. The kernel stack is used for fault detection, wherein the abnormal task determination conditions include the running time being greater than or equal to the preset first duration threshold, or the interruption shutdown time being greater than or equal to the preset second duration threshold.

[0205] In some possible embodiments, when the target task runs in the process context, the acquisition module 901 is also used to obtain the start time of the target task running in the target core; by periodically triggering the preset clock interrupt, calculating the difference between the time when the clock interrupt is triggered and the start time, the running time is obtained.

[0206] In some possible embodiments, the abnormal task determination condition includes a runtime greater than or equal to a first duration threshold, and the printing module 902 is further used to print the kernel stack of the target task according to a preset printing rule when the runtime is greater than or equal to the first duration threshold, wherein the printing rule includes printing the kernel stack of the target task when the runtime is greater than or equal to the first duration threshold for the first time, or printing the kernel stack of the target task according to a preset printing cycle.

[0207] In some possible embodiments, when the target task is running in an interrupt context, the acquisition module 901 is also used to obtain the interruption shutdown time of the target task; when the target task is interrupted, the interruption startup time is obtained, the difference between the interruption startup time and the interruption shutdown time is calculated, and the interruption shutdown duration is obtained.

[0208] In some possible embodiments, the abnormal task determination condition includes that the interruption-disabled duration is greater than or equal to a second duration threshold, and the printing module 902 is further used to print the kernel stack of the target task when the interruption is enabled for the target task and the interruption-disabled duration is greater than or equal to the second duration threshold.

[0209] In some possible embodiments, the kernel stack printing device also includes a parsing module for determining whether multiple kernel stacks of a target task are identical when multiple kernel stacks are printed; and if there are at least two identical kernel stacks among the multiple kernel stacks, parsing the at least two identical kernel stacks to obtain fault information corresponding to the target task.

[0210] The description of the above device embodiment is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment. For technical details not disclosed in the device embodiment of this application, please refer to the description of the method embodiment of this application for understanding.

[0211] It should be noted that in the embodiments of this application Figure 9 The division of modules in the kernel stack device shown is schematic and is merely a logical functional division. In actual implementation, other division methods may be used. Furthermore, the functional units in the various embodiments of the present application may be integrated into a single processing unit, or may exist physically separately, or two or more units may be integrated into a single unit. The aforementioned integrated units may be implemented in the form of hardware or software functional units. Alternatively, they may be implemented in a combination of software and hardware.

[0212] It should be noted that, in the embodiment of the present application, if the above method is implemented in the form of a software function module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application is essentially or the part that contributes to the relevant technology can be embodied in the form of a software product, and the computer software product is stored in a storage medium, including a number of instructions for enabling an electronic device to execute all or part of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a U disk, a mobile hard disk, a read-only memory (ROM), a magnetic disk or an optical disk. In this way, the embodiment of the present application is not limited to any specific combination of hardware and software.

[0213] The embodiment of the present application provides a computer device, which may be a server, and its internal structure diagram may be as follows: Figure 10 As shown. The computer device includes a processor, a memory, and a network interface connected via a system bus. The processor of the computer device is used to provide computing and control capabilities. The memory of the computer device includes a non-volatile storage medium and an internal memory. The non-volatile storage medium stores an operating system, a computer program, and a database. The internal memory provides an environment for the operation of the operating system and computer program in the non-volatile storage medium. The database of the computer device is used to store data. The network interface of the computer device is used to communicate with an external terminal via a network connection. When the computer program is executed by the processor, the above method is implemented.

[0214] An embodiment of the present application provides a computer-readable storage medium having a computer program stored thereon. When the computer program is executed by a processor, the steps of the method provided in the above embodiment are implemented.

[0215] An embodiment of the present application provides a computer program product containing instructions, which, when executed on a computer, enables the computer to execute the steps of the method provided in the above method embodiment.

[0216] Those skilled in the art will understand that Figure 10 The structure shown in the figure is only a block diagram of a part of the structure related to the solution of the present application, and does not constitute a limitation on the computer device to which the solution of the present application is applied. The specific computer device may include more or fewer components than shown in the figure, or combine certain components, or have a different component arrangement.

[0217] In one embodiment, the kernel stack printing device provided by the present application can be implemented in the form of a computer program. Figure 10The computer device is operated on the computer device shown. The memory of the computer device can store various program modules that constitute the above-mentioned device. The computer program composed of each program module enables the processor to execute the steps of the method of each embodiment of the present application described in this specification.

[0218] It should be noted that the description of the above storage medium and device embodiments is similar to the description of the above method embodiments and has similar beneficial effects as the method embodiments. For technical details not disclosed in the storage medium, storage medium, and device embodiments of this application, please refer to the description of the method embodiments of this application for understanding.

[0219] It should be understood that "one embodiment" or "an embodiment" or "some embodiments" mentioned throughout the specification means that the specific features, structures or characteristics related to the embodiment are included in at least one embodiment of the present application. Therefore, "in one embodiment" or "in an embodiment" or "in some embodiments" appearing throughout the specification do not necessarily refer to the same embodiment. In addition, these specific features, structures or characteristics can be combined in one or more embodiments in any suitable manner. It should be understood that in the various embodiments of the present application, the size of the serial numbers of the above-mentioned processes does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present application. The above-mentioned serial numbers of the embodiments of the present application are for description only and do not represent the advantages and disadvantages of the embodiments. The above description of the various embodiments tends to emphasize the differences between the various embodiments. The same or similar aspects can be referenced to each other. For the sake of brevity, they will not be repeated here.

[0220] The term "and / or" in this article is only a description of the association relationship between associated objects, indicating that there can be three relationships. For example, object A and / or object B can mean: object A exists alone, object A and object B exist at the same time, and object B exists alone.

[0221] It should be noted that, in this document, the terms "comprises," "includes," or any other variations thereof are intended to encompass non-exclusive inclusion, such that a process, method, article, or apparatus comprising a series of elements includes not only those elements but also other elements not explicitly listed, or elements inherent to such process, method, article, or apparatus. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or apparatus comprising the element.

[0222] In the several embodiments provided in this application, it should be understood that the disclosed devices and methods can be implemented in other ways. The embodiments described above are merely illustrative. For example, the division of the modules is merely a logical function division. In actual implementation, there may be other division methods, such as: multiple modules or components can be combined, or can be integrated into another system, or some features can be ignored or not executed. In addition, the coupling, direct coupling, or communication connection between the components shown or discussed can be through some interfaces, and the indirect coupling or communication connection of devices or modules can be electrical, mechanical or other forms.

[0223] The modules described above as separate components may or may not be physically separated, and the components displayed as modules may or may not be physical modules; they may be located in one place or distributed across multiple network units; some or all of the modules may be selected according to actual needs to achieve the purpose of this embodiment.

[0224] In addition, all functional modules in the embodiments of the present application can be integrated into one processing unit, or each module can be a separate unit, or two or more modules can be integrated into one unit; the above-mentioned integrated modules can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0225] Those skilled in the art will understand that all or part of the steps of implementing the above-mentioned method embodiment can be completed by hardware related to program instructions, and the aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it executes the steps of the above-mentioned method embodiment; and the aforementioned storage medium includes: mobile storage devices, read-only memories (ROM), magnetic disks or optical disks, and other media that can store program codes.

[0226] Alternatively, if the above-mentioned integrated unit of the present application is implemented in the form of a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the embodiment of the present application, or the part that contributes to the relevant technology, can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a number of instructions for enabling an electronic device to execute all or part of the methods described in each embodiment of the present application. The aforementioned storage medium includes: various media that can store program codes, such as mobile storage devices, ROMs, magnetic disks or optical disks.

[0227] The methods disclosed in the several method embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments.

[0228] The features disclosed in the several product embodiments provided in this application can be arbitrarily combined without conflict to obtain new product embodiments.

[0229] The features disclosed in the several method or device embodiments provided in this application can be arbitrarily combined without conflict to obtain new method embodiments or device embodiments.

[0230] The above is merely an embodiment of the present application, but the scope of protection of the present application is not limited thereto. Any changes or substitutions that can be easily conceived by a person skilled in the art within the technical scope disclosed in this application should be included in the scope of protection of this application. Therefore, the scope of protection of this application should be based on the scope of protection of the claims.

Claims

1. A kernel stack printing method, characterized in that: The method is applied to a target core of a terminal device, and the method includes: Acquire task information of a target task running in the target core, wherein the task information includes a running time of the target task running in a process context, or a disabled interrupt time of the target task running in an interrupt context; When the task information satisfies the abnormal task determination condition, the kernel stack of the target task is printed, and the kernel stack is used for fault detection, wherein the abnormal task determination condition includes that the running time is greater than or equal to a preset first time threshold, or that the interruption shutdown time is greater than or equal to a preset second time threshold.

2. The method according to claim 1, characterized in that In a case where the target task is running in a process context, obtaining task information of the target task running in the target core includes: Obtaining a start time of the target task running in the target core; The running time is obtained by periodically triggering a preset clock interrupt and calculating the difference between the time when the clock interrupt is triggered and the start time.

3. The method according to claim 2, characterized in that The abnormal task determination condition includes that the running time is greater than or equal to the first time threshold, and when the task information satisfies the abnormal task determination condition, printing the kernel stack of the target task includes: When the running time is greater than or equal to the first time threshold, the kernel stack of the target task is printed according to the preset printing rules, wherein the printing rules include printing the kernel stack of the target task when the running time is greater than or equal to the first time threshold for the first time, or printing the kernel stack of the target task according to a preset printing cycle.

4. The method according to claim 3, characterized in that The task information also includes a process shutdown duration of the target task running in the process context, the abnormal task determination condition also includes that the process shutdown duration is greater than or equal to a preset third duration threshold, and the method further includes: When the target task is interrupted, the running time and the interruption-disabled time of the process are obtained; When the runtime is greater than or equal to the first duration threshold, or when the interruption-disabled duration of the process is greater than or equal to the third duration threshold, the kernel stack of the target task is printed.

5. The method according to claim 1, wherein In a case where the target task is running in an interrupt context, obtaining task information of the target task running in the target core includes: Obtaining the shutdown interruption time of the target task; In the case where the target task is interrupted, an interruption-on time is obtained, a difference between the interruption-on time and the interruption-off time is calculated, and the interruption-off duration is obtained.

6. The method according to claim 4, characterized in that The abnormal task determination condition includes that the interruption disabling duration is greater than or equal to the second duration threshold, and when the task information satisfies the abnormal task determination condition, printing the kernel stack of the target task includes: When the target task enables interrupts and the interrupt-disabling duration is greater than or equal to the second duration threshold, the kernel stack of the target task is printed.

7. The method according to claim 1, characterized in that After printing the kernel stack of the target task, the method further includes: When multiple kernel stacks of the target task are printed, determining whether the multiple kernel stacks are the same; In the case that there are at least two identical kernel stacks among the multiple kernel stacks, the at least two identical kernel stacks are parsed to obtain fault information corresponding to the target task.

8. A kernel stack printing device, characterized in that: The device is applied to a target core of a terminal device, and includes: an acquisition module, configured to acquire task information of a target task running in the target core, wherein the task information includes a running time of the target task running in a process context, or a disabled interrupt time of the target task running in an interrupt context; A printing module is used to print the kernel stack of the target task when the task information meets the abnormal task determination condition, and the kernel stack is used for fault detection, wherein the abnormal task determination condition includes that the running time is greater than or equal to a preset first time threshold, or that the interruption shutdown time is greater than or equal to a preset second time threshold.

9. A computer device comprising a memory and a processor, wherein the memory stores a computer program that can be run on the processor, characterized in that: When the processor executes the program, the steps of the method according to any one of claims 1 to 7 are implemented.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that: When the computer program is executed by a processor, the method according to any one of claims 1 to 7 is implemented.

Citation Information

Patent Citations

  • Method and device for detecting multi-core CPU

    CN106407088A

  • Overtime detection method, device and equipment and storage medium

    CN111176869A

  • CPU utilization rate monitoring method and device, equipment and storage medium

    CN117555732A

  • Task schedule device and task schedule method

    JP2011192166A

  • System test apparatus

    US20130086425A1