Call stack address acquisition processing method, device, equipment and medium

Abstract

The invention relates to the technical field of computer data processing, and discloses a call stack address collecting and processing method, device and equipment and a medium, and the method comprises the steps that call stack shallow backtracking is executed on a target monitoring thread in a preset period, and a shallow backtracking address is collected; meanwhile, whether the target monitoring thread meets a preset exception triggering condition or not is judged; if the preset exception triggering condition is met, calling stack deep backtracking is carried out on the target monitoring thread, and a deep backtracking address is obtained; forming a candidate address set by the shallow backtracking addresses and the deep backtracking addresses; and analyzing the candidate address set, and generating an exception report based on the analyzed stack information. According to the method and the device, by decoupling call stack acquisition and symbolization, setting shallow backtracking in a normal stage, only extracting a return address and not executing symbolization operation, and executing deeper call stack backtracking in an abnormal stage, the problems of high CPU consumption and incapability of meeting the requirement of starting monitoring for a long time due to the fact that symbolization is carried out when the call stack is sampled are solved.

Description

Technical Field

[0001] This application relates to the field of computer data processing technology, and in particular to a method, apparatus, device and medium for collecting and processing call stack addresses. Background Technology

[0002] During long-term operation, common performance issues in mobile applications include unresponsive interfaces, abnormally high CPU usage, and excessive memory usage. To pinpoint these issues, performance monitoring is necessary without increasing overhead. In mobile performance monitoring, the call stack is crucial evidence for locating Central Processing Unit (CPU) anomalies, Application Not Responding (ANR) stutters, and memory anomalies.

[0003] In existing technologies, call stack acquisition methods typically perform symbolization during sampling. The advantage is that a readable stack can be obtained immediately. However, since symbolization involves symbol table lookups, long-term operation at high-frequency periods such as 33ms or 50ms can easily lead to high CPU consumption, failing to meet the requirements for long-term monitoring. Another type of call stack acquisition method attempts delayed symbolization, but lacks a unified interface, leading to different modules implementing it independently, which easily results in duplicated overhead and maintenance difficulties. Summary of the Invention

[0004] To address the shortcomings of existing technologies in terms of performance and maintainability, this application discloses a method, apparatus, device, and medium for call stack address acquisition and processing. By employing an "address-based acquisition + delayed unified symbolization" approach, the normal sampling and symbolization of the call stack are decoupled. Furthermore, different backtracking depths are designed for different stages, achieving a balance between performance, accuracy, and maintainability. Specifically, the technical solution of this application is as follows: Firstly, this application discloses a method for collecting and processing call stack addresses, the method comprising: Perform shallow backtracking of the call stack on the target monitoring thread at a preset period and collect the shallow backtracking address; at the same time, determine whether the target monitoring thread meets the preset abnormal triggering condition. If the preset exception triggering condition is met, a deep backtracking of the call stack is performed on the target monitoring thread, and the deep backtracking address is obtained; The shallow backtracking address and the deep backtracking address form a candidate address set; the candidate address set is parsed, and an exception report is generated based on the parsed stack information.

[0005] In some implementations, parsing the candidate address set and generating an exception report based on the parsed stack information specifically includes: The candidate address set is parsed in one go through a unified symbolic interface, and the addresses are converted into function symbol stacks; For each function symbol stack, fingerprint feature values ​​are calculated to generate a unique identifier, and repeated event suppression and reporting frequency adjustment are performed according to the annealing strategy. The stack information is used to determine whether the current exception meets the preset release conditions. If the conditions are met, an exception report is generated based on the function symbol stack and reported.

[0006] In other embodiments, the call stack address acquisition and processing method further includes: A unified symbolization service interface is provided to perform centralized symbol resolution for each monitoring module, avoiding redundant implementation of symbolization logic in each monitoring module.

[0007] In some implementations, determining whether the target monitoring thread meets a preset exception triggering condition includes: Based on each of the aforementioned monitoring modules, the runtime data stream collected from the target monitoring thread is continuously analyzed; The runtime data stream is matched with preset abnormal feature thresholds to determine whether the abnormal triggering conditions are met.

[0008] Optionally, the step of performing shallow call stack backtracking on the target monitoring thread at a preset period and collecting the shallow backtracking address includes: Obtain a preset first backtracking depth threshold, wherein the first backtracking depth threshold is the maximum number of backtracking frames for shallow backtracking; The call stack of the target monitoring thread is traced back based on the first backtracking threshold.

[0009] Optionally, the step of performing a deep backtracking of the call stack on the target monitoring thread and obtaining the deep backtracking address includes: Obtain a preset second backtracking depth threshold, wherein the second backtracking depth threshold is the maximum number of backtracking frames for deep backtracking, and the second backtracking depth threshold is greater than the first backtracking depth threshold; The call stack of the target monitoring thread is traced back based on the second backtracking threshold.

[0010] Secondly, this application also discloses a call stack address acquisition and processing device, the device comprising: The first address acquisition module is used to perform shallow backtracking of the call stack of the target monitored thread at a preset period and collect the shallow backtracking address. An exception triggering judgment module is used to simultaneously determine whether the target monitoring thread meets the preset exception triggering conditions; The second address acquisition module is used to perform a deep backtracking of the call stack of the target monitoring thread and obtain the deep backtracking address if the preset abnormal triggering condition is met. The symbolic reporting module is used to form a candidate address set by the shallow backtracking address and the deep backtracking address; parse the candidate address set, and generate an exception report based on the parsed stack information.

[0011] In some implementations, the symbolization reporting module specifically includes: The parsing submodule is used to parse the candidate address set in one go through a unified symbolization interface, converting the addresses into function symbol stacks; The annealing submodule is used to calculate fingerprint feature values ​​for each function symbol stack, generate a unique identifier, and suppress repeated events and adjust the reporting frequency according to the annealing strategy. The release judgment submodule is used to judge the stack information to determine whether the current exception meets the preset release conditions; The reporting submodule is used to generate an exception report based on the function symbol stack and report it if the condition is met.

[0012] Optionally, a computer device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the steps described in the call stack address acquisition and processing method above.

[0013] Optionally, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the steps described in the call stack address acquisition and processing method above.

[0014] Compared with the prior art, this application has at least one of the following beneficial effects: 1. This application adopts a design approach of "address-based data collection + delayed unified symbolization," and designs backtracking depths for different stages: shallow backtracking during the normal period ensures low cost, while deep backtracking during the triggering period provides complete evidence. This successfully balances low cost during the sampling period with completeness during the triggering period. This scheme decouples data collection and parsing, reducing resource consumption caused by periodic symbolization.

[0015] 2. This application uses a unified interface to support multi-module sharing. A unified symbolic interface runs through modules such as CPU, ANR, and memory, enabling multiple modules to share the parsed results from a single step, thus enhancing system consistency and maintainability. It ensures a balance between performance, accuracy, and maintainability. Overall, it forms a lightweight, modular, and long-term operable mobile terminal call stack collection and reporting mechanism. Attached Figure Description

[0016] Figure 1This is a flowchart illustrating the call stack address acquisition and processing method in one embodiment; Figure 2 This is a simplified flowchart illustrating the call stack address acquisition and processing method in one embodiment; Figure 3 This is a structural block diagram of a call stack address acquisition and processing device in one embodiment. Detailed Implementation

[0017] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0018] It should be understood that, when used in this application specification and the appended claims, the term "comprising" indicates the presence of the described features, integrals, steps, operations, elements and / or components, but does not exclude the presence or addition of one or more other features, integrals, steps, operations, elements, components and / or a collection thereof.

[0019] It should also be understood that the term “and / or” as used in this application specification and the appended claims means any combination of one or more of the associated listed items and all possible combinations, and includes such combinations.

[0020] As used in this application specification and the appended claims, the term "if" may be interpreted, depending on the context, as "when," "once," "in response to determination," or "in response to detection." Similarly, the phrase "if determined" or "if detected [the described condition or event]" may be interpreted, depending on the context, as meaning "once determined," "in response to determination," "once detected [the described condition or event]," or "in response to detection [the described condition or event]."

[0021] Furthermore, in the description of this application and the appended claims, the terms "first," "second," "third," etc., are used only to distinguish descriptions and should not be construed as indicating or implying relative importance.

[0022] References to "one embodiment" or "some embodiments" as described in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0023] In the field of mobile performance monitoring, the call stack, as a key data point recording the code execution path, is crucial evidence for diagnosing core issues such as high CPU usage, ANR (Application Not Responding) errors, and memory leaks. However, current mainstream call stack collection methods have significant technical flaws that limit their effectiveness.

[0024] The main problems with existing solutions are threefold: First, some methods perform symbolization synchronously during sampling, leading to periodic CPU peak loads and continuously negatively impacting application runtime performance. Second, other solutions using delayed symbolization lack global coordination, requiring different monitoring modules such as CPU, ANR, and memory to implement their own symbolization processing logic, resulting in system redundancy, inconsistent behavior, and increased maintenance complexity. Third, regarding backtracking depth, existing strategies often use fixed configurations, failing to flexibly adapt to different scenarios. This either leads to unnecessary performance losses due to excessive backtracking under normal monitoring conditions, or fails to obtain a complete call chain for in-depth analysis when anomalies are triggered due to shallow backtracking.

[0025] To address the aforementioned technical challenges, this application significantly reduces routine monitoring overhead through "address-based data collection + delayed unified symbolization"; it achieves a balance between routine and trigger-period monitoring by combining shallow and deep backtracking; and it improves system consistency and maintainability by avoiding redundant implementation across multiple modules through a unified symbolization interface. Ultimately, it achieves lightweight routine operation, integrity guarantees during triggering, and unified cross-module reporting.

[0026] Reference manual attached Figure 1 As shown, this application provides an embodiment of a call stack address acquisition and processing method, which specifically includes the following steps: S100 performs shallow backtracking of the call stack on the target monitoring thread at a preset period and collects the shallow backtracking address.

[0027] S200, and at the same time determine whether the target monitoring thread meets the preset abnormal triggering conditions.

[0028] S300, if the preset exception triggering condition is met, the target monitoring thread is subjected to deep call stack backtracking, and the deep backtracking address is obtained.

[0029] S400, the shallow backtracking address and the deep backtracking address form a candidate address set; the candidate address set is parsed, and an exception report is generated based on the parsed stack information.

[0030] In some alternative embodiments, the preset abnormality triggering conditions described in this application include, but are not limited to, issues such as CPU abnormalities, ANR stuttering, and memory abnormalities.

[0031] In this embodiment, the system determines whether the system belongs to a normal phase (where the preset exception triggering condition is not triggered) or an exception phase (where the preset exception triggering condition is triggered) by judging whether the preset exception triggering condition is met. Based on the normal and exception phases, shallow and deep backtracking of the call stack are set accordingly. In the normal phase, shallow backtracking only extracts the return address, does not perform symbolization operations, does not suspend threads, and retains only a small number of stack frames, achieving call stack address collection with extremely low overhead on mobile devices. In the exception phase, on the one hand, the recently cached shallow backtracking address sequence is extracted, and on the other hand, a deeper call stack backtracking is performed to obtain a more complete deep backtracking address sequence, providing complete evidence in case of an exception.

[0032] This application provides another embodiment of the call stack address collection and processing method. Based on the above embodiment, in step S100, shallow call stack backtracking is performed on the target monitoring thread at a preset period to collect the shallow backtracking address, which specifically includes the following sub-steps: S110, obtain a preset first backtracking depth threshold, wherein the first backtracking depth threshold is the maximum number of backtracking frames for shallow backtracking.

[0033] S120, perform call stack backtracking on the target monitoring thread based on the first backtracking threshold.

[0034] Specifically, during the normal phase, the sampler performs shallow backtracking on the target thread at a preset period, extracting only the return address (PC / LR, etc.) and writing it into a circular buffer in address form. It does not perform symbolization operations or suspend the target thread, but only collects the shallow backtracking address sequence. The shallow backtracking retains only a small number of stack frames to avoid the overhead of suspending the thread and parsing.

[0035] In some alternative implementations, shallow call stack backtracking is performed by setting the first backtracking depth threshold.

[0036] Specifically, the backtracking depth at this stage is relatively small, retaining only a few stack frames. For example, the first backtracking threshold can be set to backtrack 2-15 levels. The shallow backtracking call stack provides a continuous "stream of execution samples." When a system suddenly encounters an anomaly, multiple shallow backtracking records from the instant before the anomaly occurs can be immediately retrieved from the circular buffer, revealing what the program was doing before the crash. This process does not retrieve the complete call chain, thus maintaining extremely low sampling overhead.

[0037] This application provides another embodiment of the call stack address collection and processing method. Based on the above embodiment, step S200: determining whether the target monitoring thread meets the preset exception triggering condition, specifically includes the following sub-steps: S210, based on each of the monitoring modules, continuously analyze the runtime data stream collected from the target monitoring thread.

[0038] S220, the runtime data stream is matched with a preset abnormal feature threshold to determine whether the abnormal triggering condition is met.

[0039] In this embodiment, the thread monitoring cycle is to perform shallow backtracking on the target monitoring thread at regular intervals under normal monitoring conditions. This records the time trajectory before the anomaly occurs with a small fixed time cost, thereby determining whether the target monitoring thread meets the preset anomaly triggering conditions.

[0040] This application provides another embodiment of the call stack address acquisition and processing method. Based on the above embodiment, step S300, which involves performing a deep call stack backtracking on the target monitoring thread and obtaining the deep backtracking address, specifically includes the following sub-steps: S310, obtain a preset second backtracking depth threshold, wherein the second backtracking depth threshold is the maximum number of backtracking frames for deep backtracking, and the second backtracking depth threshold is greater than the first backtracking depth threshold.

[0041] S320, perform call stack backtracking on the target monitoring thread based on the second backtracking threshold.

[0042] In this embodiment, the second backtracking depth threshold is greater than the first backtracking depth threshold to distinguish between shallow and deep backtracking. Based on the first backtracking depth threshold, normal write-only addresses are implemented, significantly reducing the impact of sampling on performance and achieving low overhead. The second backtracking depth threshold ensures that complete data is obtained when an anomaly is triggered.

[0043] Specifically, when the monitoring module determines that the abnormal triggering conditions are met, it enters the triggering phase. At this time, the system extracts the shallow backtracking addresses of recent caches from the circular buffer, and performs a deep backtracking on the target thread, that is, a deeper call stack backtracking, to obtain a more complete address sequence.

[0044] In some implementations, the second backtracking depth threshold is set to the maximum depth of the target monitoring thread. Deep backtracking provides the complete call chain at the time the problem occurred, showing the complete execution path from the program entry point to the crash point, which is crucial for locating specific lines of abnormal code.

[0045] In other implementations, the method further includes: extracting the return address and writing it into a circular buffer in address form, and further includes: extracting the shallow backtracking address sequence from the circular buffer.

[0046] This application provides another embodiment of the call stack address collection and processing method. Based on any of the above embodiments, this application provides a unified symbolization service interface to perform centralized symbol resolution for each monitoring module, thereby avoiding redundant implementation of symbolization logic in each monitoring module.

[0047] Step S400: Parsing the candidate address set and generating an exception report based on the parsed stack information, specifically includes: S410, the candidate address set is parsed in one go through the unified symbolization interface, and the address is converted into a function symbol stack.

[0048] Specifically, the shallow backtracking address series and the deep backtracking address sequence are merged to form a candidate address set. Before reporting, the candidate address set is uniformly parsed through a symbolic interface and converted into a readable function symbol stack.

[0049] This application merges the deep backtracking address sequence and the shallow backtracking address into a candidate address set, realizing deep backtracking and merging history at the same time when triggered, thus preserving the context before and after the trigger and obtaining a more complete call chain.

[0050] S420: Calculate fingerprint feature values ​​for each function symbol stack, generate a unique identifier, and suppress duplicate events and adjust the reporting frequency according to the annealing strategy.

[0051] Specifically, after symbolization is completed and clear function call stack information is obtained, this information is not immediately reported in its entirety. Instead, it enters a fingerprinting and annealing intelligent filtering logic. The fingerprint refers to generating a unique identifier for each unique call stack to identify whether it contains completely identical or similar exceptions. Optionally, the annealing strategy uses this fingerprint to determine whether the current exception call stack has been recently reported or whether it belongs to a known problem that can be temporarily ignored.

[0052] S430, determine whether the current exception meets the preset release conditions based on the stack information.

[0053] S440, if the condition is met, an exception report is generated based on the function symbol stack and reported.

[0054] Specifically, if the system determines that the exception meets the release conditions, then it will be packaged into a complete exception report and submitted to the server for reporting.

[0055] In some implementations, the unified symbolic interface is an interface that can be shared by various monitoring modules such as CPU, ANR, and memory.

[0056] Based on the shared symbolic interface of various monitoring modules such as CPU, ANR, and memory, the candidate address set is parsed in one go through the unified symbolic interface, and a function symbol stack is generated. This avoids the duplication of implementation by multiple modules, realizes the sharing of parsing results by multiple modules, enhances system consistency and maintainability, and combines shallow backtracking and deep backtracking to realize an overall scheme of normal address-based collection, abnormal deep collection, and delayed unified symbolic collection. It takes into account the low cost of sampling period and the integrity of triggers. While decoupling collection and parsing, it reduces the resource consumption caused by periodic symbolic collection, and forms a lightweight, modular, and long-term runnable mobile terminal call stack collection and reporting mechanism.

[0057] In another embodiment, step S410 further includes: cleaning and optimizing the obtained original call stack, for example, removing noise based on the function symbol stack.

[0058] Specifically, the raw function call stack directly collected from the system's underlying layer typically contains a large number of system-level function calls, i.e., system frames, that are unrelated to the application's own code. Directly using these unprocessed call stacks would complicate problem analysis. Therefore, this embodiment simplifies the call stack to only the parts most relevant to the application logic through a noise filtering process, thereby focusing on the root cause of the problem and significantly improving the clarity, readability, and accuracy of the exception report and subsequent analysis.

[0059] This application provides another embodiment of the call stack address acquisition and processing method, see attached specification. Figure 2 The technical details of this application are described below. Figure 2 The diagram illustrates the complete call stack address acquisition and processing method. "Periodic backtracking" in the diagram refers to the shallow backtracking of the call stack for the target monitoring thread in step S200. "depth: 15" represents the first backtracking depth threshold. "Abnormal trigger deep backtracking" refers to the deep backtracking of the call stack for the target monitoring thread in step S300.

[0060] "Reading PC / LR" after "periodic backtracking" and "exception-triggered deep backtracking" refers to reading the program counter and link register, and obtaining the shallow backtracking address sequence and deep backtracking address sequence, respectively. Then, candidate address set generation, unified symbolization, noise removal, and exception reporting operations are performed in sequence.

[0061] Based on the same concept, this application also discloses a call stack address acquisition and processing device. The processing device is used to implement the steps described in any of the above method embodiments. The processing device includes, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices, etc., and this application does not specifically limit it.

[0062] Specifically, one embodiment of the call stack address acquisition and processing device of this application includes: The first address acquisition module is used to perform shallow backtracking of the call stack of the target monitored thread at a preset period and collect the shallow backtracking address. An exception triggering judgment module is used to simultaneously determine whether the target monitoring thread meets the preset exception triggering conditions; The second address acquisition module is used to perform a deep backtracking of the call stack of the target monitoring thread and obtain the deep backtracking address if the preset abnormal triggering condition is met. The symbolic reporting module is used to form a candidate address set by the shallow backtracking address and the deep backtracking address; parse the candidate address set, and generate an exception report based on the parsed stack information.

[0063] This application provides another embodiment of the call stack address acquisition and processing device, wherein the first address acquisition module is specifically used to: obtain a preset first backtracking depth threshold, wherein the first backtracking depth threshold is the maximum number of backtracking frames for shallow backtracking; and perform call stack backtracking on the target monitoring thread based on the first backtracking threshold.

[0064] The aforementioned anomaly triggering judgment module is specifically used to continuously analyze the runtime data stream collected from the target monitoring thread based on each of the monitoring modules; and match the runtime data stream with a preset anomaly feature threshold to determine whether the anomaly triggering condition is met.

[0065] The second address-based acquisition module is specifically used for: obtaining a preset second backtracking depth threshold, wherein the second backtracking depth threshold is the maximum number of backtracking frames for deep backtracking, and the second backtracking depth threshold is greater than the first backtracking depth threshold; and performing call stack backtracking on the target monitoring thread based on the second backtracking threshold.

[0066] This application provides another embodiment of a call stack address acquisition and processing device, wherein the symbolic reporting module specifically includes: The parsing submodule is used to parse the candidate address set in one go through a unified symbolization interface, converting the addresses into function symbol stacks; The annealing submodule is used to calculate fingerprint feature values ​​for each function symbol stack, generate a unique identifier, and suppress repeated events and adjust the reporting frequency according to the annealing strategy. The release judgment submodule is used to judge the stack information to determine whether the current exception meets the preset release conditions; The reporting submodule is used to generate an exception report based on the function symbol stack and report it if the condition is met.

[0067] In one embodiment, a unified symbolization service interface is provided to perform centralized symbol resolution for each monitoring module, thereby avoiding redundant implementation of symbolization logic in each monitoring module.

[0068] It should be noted that the information interaction and execution process between the above modules are based on the same concept as the method embodiments of this application. For details on their specific functions and technical effects, please refer to the method embodiments section, which will not be repeated here.

[0069] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is merely an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above. The functional units and modules in the embodiments can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit. Furthermore, the specific names of the functional units and modules are only for easy differentiation and are not intended to limit the scope of protection of this application. The specific working process of the units and modules in the above system can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here.

[0070] Based on the same technical concept, this application also provides a network device, which includes: at least one processor, a memory, and a computer program stored in the memory and executable on the at least one processor, wherein the processor executes the computer program to implement the steps in any of the above method embodiments.

[0071] Based on the same technical concept, this application also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in the above-described method embodiments.

[0072] This application provides a computer program product that, when run on a mobile terminal, enables the mobile terminal to implement the steps described in the above-described method embodiments.

[0073] In the above embodiments, the descriptions of each embodiment have different focuses. For parts that are not described in detail or recorded in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0074] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

Claims

1. A call stack address collection processing method, characterized by, The method comprises: Performing call stack shallow backtracking on a target monitoring thread at a preset period, collecting shallow backtracking addresses; simultaneously judging whether the target monitoring thread meets a preset exception triggering condition; If the preset exception triggering condition is met, performing call stack deep backtracking on the target monitoring thread, and obtaining deep backtracking addresses; The shallow backtracking addresses and the deep backtracking addresses form a candidate address set; the candidate address set is parsed, and an exception report is generated based on the parsed stack information.

2. The call stack address collection processing method according to claim 1, wherein The parsing of the candidate address set and the generation of the exception report based on the parsed stack information specifically comprise: The candidate address set is parsed through a unified symbolization interface for one-time parsing, and the addresses are converted into function symbol stacks; Fingerprint feature value calculation is performed for each function symbol stack to generate a unique identifier, and repeated event suppression and reporting frequency regulation are performed according to an annealing strategy; Judging whether the stack information meets a preset release condition; If the preset release condition is met, an exception report is generated based on the function symbol stack and is reported.

3. The call stack address collection processing method according to claim 2, wherein Further comprising: Providing a unified symbolization service interface to centrally parse symbols for each monitoring module, avoiding redundant implementation of the monitoring modules in the symbolization logic.

4. The call stack address collection processing method according to claim 3, wherein The judgment of whether the target monitoring thread meets the preset exception triggering condition comprises: Based on each monitoring module, continuously analyzing runtime data streams collected from the target monitoring thread; Matching the runtime data streams with a preset exception feature threshold to determine whether the exception triggering condition is met.

5. The call stack address collection processing method according to claim 1, wherein The shallow backtracking of the target monitoring thread at a preset period to collect shallow backtracking addresses comprises: Obtaining a preset first backtracking depth threshold, wherein the first backtracking depth threshold is the maximum backtracking frame number of shallow backtracking; Performing call stack backtracking on the target monitoring thread based on the first backtracking threshold.

6. The call stack address collection processing method according to claim 5, wherein The deep backtracking of the target monitoring thread to obtain deep backtracking addresses comprises: Obtaining a preset second backtracking depth threshold, wherein the second backtracking depth threshold is the maximum backtracking frame number of deep backtracking, and the second backtracking depth threshold is greater than the first backtracking depth threshold; Performing call stack backtracking on the target monitoring thread based on the second backtracking threshold.

7. A call stack address collection processing apparatus characterized by comprising: The device comprises: A first address collection module for performing call stack shallow backtracking on a target monitoring thread at a preset period to collect shallow backtracking addresses; An exception triggering judgment module for simultaneously judging whether the target monitoring thread meets a preset exception triggering condition; A second address collection module for performing call stack deep backtracking on the target monitoring thread to obtain deep backtracking addresses if the preset exception triggering condition is met; A symbolization reporting module for parsing the candidate address set based on the parsed stack information to generate an exception report.

8. The call stack address harvesting processing apparatus according to claim 7, wherein The symbolization reporting module specifically comprises: An analysis submodule for parsing the candidate address set through a unified symbolization interface for one-time parsing to convert addresses into function symbol stacks; An annealing submodule is configured to calculate a fingerprint feature value for each function symbol stack, generate a unique identifier, and perform repeated event suppression and report frequency regulation according to an annealing strategy; A release judgment submodule is configured to judge whether the stack information meets preset release conditions. A report submodule is configured to generate and report an exception report based on the function symbol stack if the stack information meets the preset release conditions. 9.A computer device, comprising a memory and a processor, wherein the memory stores a computer program, and the computer device is configured to perform the method according to any one of claims 1-8 when the computer program is executed by the processor. The processor executes the computer program to implement the steps of the method in any one of claims 1 to 6.

10. A computer-readable storage medium having stored thereon a computer program, characterized in that, The computer program is executed by the processor to implement the steps of the method in any one of claims 1 to 6.

Images