A software diagnostic system

Abstract

The application discloses a software diagnosis system, which comprises at least one occurrence domain for recording events triggered by software activities and performing diagnosis on the events; the occurrence domain comprises an event processing source for recording and processing event sources of the software activities; an information block generator connected to the event processing source for generating recording information blocks or event information blocks and sending the recording information blocks or the event information blocks to the event processing source; a primary diagnosis device for performing diagnosis on the recording information blocks or the event information blocks and generating a diagnosis report based on the diagnosis result; and a primary capture device connected to the event processing source and the primary diagnosis device for realizing information docking between the event processing source and the primary diagnosis device and performing information filtering on the recording information blocks or the event information blocks and / or the diagnosis report. Through the above method, the software diagnosis system provided by the application can realize dynamic collection and real-time diagnosis.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of computer application, in particular to a software diagnosis system. BACKGROUND

[0002] When the program code of software is completed, the software must be diagnosed, which is to test whether the program execution result meets the original design requirements. At this time, the software designer must determine whether the input and output data of each individual function mode meet the original requirements, in addition to testing the overall performance of the system. Even if the function meets the needs, if the execution speed is very slow, the software cannot meet the needs of the user.

[0003] The current software activity diagnosis system adopts a typical "collection" and "analysis" separation structure, that is, independent collection and independent analysis, and the collection adopts a "complete" mode and the analysis adopts an "offline" mode. In the complete collection mode, a lot of computing resources are often needed, and the data volume is large. In the offline analysis mode, complete data is often relied on, and the diagnosis may have outdated problems, and real-time diagnosis cannot be performed according to the needs of data collection. SUMMARY

[0004] The present application provides a software diagnosis system.

[0005] One technical scheme provided by the present application is to provide a software diagnosis system, which comprises:

[0006] At least one occurrence domain, used for recording events triggered by the software activity and performing a diagnosis on the events;

[0007] The occurrence domain comprises:

[0008] An event processing source, used for recording and processing an event source of the software activity;

[0009] An information block generator, connected to the event processing source, used for generating a record information block or an event information block, and sending the record information block or the event information block to the event processing source;

[0010] A first-line diagnosis device, used for diagnosing the record information block or the event information block, and generating a diagnosis report based on the diagnosis result;

[0011] A first-line capture device, connected to the event processing source and the first-line diagnosis device, used for realizing information docking between the event processing source and the first-line diagnosis device, and performing information filtering on the record information block or the event information block and / or the diagnosis report.

[0012] The beneficial effects of the application are that the diagnostic system provided by the application comprises at least one occurrence domain for recording events triggered by software activities and performing a diagnosis on the events; the occurrence domain comprises an event processing source for recording and processing event sources of the software activities; an information block generator connected to the event processing source for generating a recording information block or an event information block and sending the recording information block or the event information block to the event processing source; a primary diagnostic device for diagnosing the recording information block or the event information block and generating a diagnostic report based on the diagnosis result; and a primary capture device connected to the event processing source and the primary diagnostic device for realizing information docking between the event processing source and the primary diagnostic device and information filtering on the recording information block or the event information block and / or the diagnostic report. Through the above method, the application can realize dynamic collection and real-time diagnosis by providing a software diagnostic system. BRIEF DESCRIPTION OF DRAWINGS

[0013] In order to more clearly illustrate the technical solutions in the embodiments of the application, the drawings needed in the embodiment description will be briefly introduced. Obviously, the drawings in the following description are only some embodiments of the application, and other drawings can be obtained by those skilled in the art without creative effort based on these drawings.

[0014] Figure 1 FIG. 1 is a structural schematic diagram of an embodiment of the software diagnostic system provided by the application;

[0015] Figure 2 FIG. 2 is a structural schematic diagram of another embodiment of the software diagnostic system provided by the application;

[0016] Figure 3 FIG. 3 is a structural schematic diagram of an embodiment of the processing domain provided by the application;

[0017] Figure 4 FIG. 4 is a structural schematic diagram of still another embodiment of the software diagnostic system provided by the application;

[0018] Figure 5 FIG. 5 is a connection schematic diagram of the occurrence domain and the processing domain provided by the application;

[0019] Figure 6 FIG. 6 is a flow schematic diagram of an embodiment of the software diagnostic system starting method provided by the application;

[0020] Figure 7 FIG. 7 is a logic system diagram of the occurrence domain starting provided by the application;

[0021] Figure 8 FIG. 8 is a logic system diagram of the occurrence service module starting provided by the application;

[0022] Figure 9is a logic system diagram of the information block generator provided by the present application starting up;

[0023] Figure 10 is a flow diagram of another embodiment of the software diagnosis system starting method provided by the present application;

[0024] Figure 11 is a system diagram of the memory leakage embodiment provided by the present application;

[0025] Figure 12 is a flow diagram of an embodiment of the software diagnosis system loading method provided by the present application;

[0026] Figure 13 is a structure diagram of another embodiment of the processing domain provided by the present application;

[0027] Figure 14 is a logic system diagram of the processing domain working provided by the present application;

[0028] Figure 15 is a logic system diagram of the processing domain starting up provided by the present application;

[0029] Figure 16 is a structure diagram of an embodiment of the terminal device provided by the present application;

[0030] Figure 17 is a structure diagram of an embodiment of the computer readable storage medium provided by the present application. DETAILED DESCRIPTION

[0031] The technical solutions in the embodiments of the present application will be described clearly and completely below with reference to the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments of the present application. Based on the embodiments in the present application, all the other embodiments obtained by those skilled in the art without creative work fall within the scope of protection of the present application.

[0032] Please refer to Figure 1 , Figure 1 is a structure diagram of an embodiment of the software diagnosis system provided by the present application.

[0033] The software diagnosis system 100 of the embodiments of the present disclosure at least includes one occurrence domain 11 (DMO = Domain Occur), wherein the occurrence domain 11 here can exist in the form of an independent process, that is, the entire terminal device only needs one occurrence domain 11 to complete the diagnosis of software activities.

[0034] Specifically, the occurrence domain 11 is the place where the event or record occurs and is first captured, and can be the place where the event or record first triggers an action. The triggering of all actions within the occurrence domain 11 can be in the form of a function call. Therefore, the occurrence domain 11 can take the shortest path, the fastest, and the most effective means of processing to complete the diagnosis of software activities.

[0035] In the present application, the occurrence domain 11 is classified according to the type of collected information, such as call tracking, ProcFS information collection, and NetStat statistics, etc. The staff can design multiple varieties of occurrence domains 11 according to different needs to suit the generation of different information collection.

[0036] The occurrence domain 11 can exist in the form of a process, and one or more instances of the occurrence domain 11 can be generated in each process according to needs, wherein the same occurrence domain 11 can only exist in one instance in a process. For example, the diagnosis of function call tracking requires the collection of information on each function entry and exit, so each process needs to call the instance of the call tracking class occurrence domain 11. That is, the same type of occurrence domain 11 has multiple instances in multiple processes.

[0037] In addition, the occurrence domain 11 can also exist in the form of an independent process, for example, the occurrence domain 11 for collecting kernel events, which only needs one instance for the entire software system. When the occurrence domain 11 is needed for collection, only the instance of the process where the occurrence domain 11 is located needs to be found.

[0038] The occurrence domain 11 of the present application is suitable for both multiple instances of the same type in multiple processes, independent collection and summarization, and on-demand collection of the entire system, independent process collection and information sharing.

[0039] Specifically, the occurrence domain 11 of the present application further includes an event processing source 111, an information block generator 112, a first-line diagnostic 114, a first-line capture 113, and an occurrence service module 115.

[0040] The event processing source (ARES, Activity Record / Event Source) 111 is used to record and process the event source of software activities. The event processing source 111 is the core of the occurrence domain 11, provides the runtime context of the occurrence domain 11, and only provides a unique context to ensure that the design and implementation of the occurrence domain 11 adopts a single-threaded mode.

[0041] The context here serves as a timer for the information block generator 112, which periodically invokes the timer function of the information block generator 112. Specifically, the information collected and generated by the information block generator 112 is first sent to the event handling source 111, then transmitted by the event handling source 111 to the first-tier catcher 113 for processing, and finally processed by the first-tier catcher 113 one by one to the first-tier diagnostic 114 for diagnostic processing. On the other hand, the context here provides a timer for the occurrence service module 115 to periodically check the commands sent downstream.

[0042] In addition, when the first-tier catcher 113 and the first-tier diagnostic 114 process information, they also generate reports on the processing of the information, which are generated during processing and cached at the event handling source 111, which ultimately maintains the chronological order of the information and the reports and pushes them to the subscribed downstream through the occurrence service module 115.

[0043] The information block generator (GEN, Generator) 112 is connected to the event handling source 111 and is used to generate and send record information blocks or event information blocks to the event handling source.

[0044] The information block generator 112 can complete the collection and generation of non-standardized information and format it into an internal unified data format. The information block generator 112 relies on the timer provided by the event handling source 111 as the context.

[0045] The first-tier catcher (FTC, First-Tier Catcher) 113 is connected to the event handling source 111 and the first-tier diagnostic 114, and is used to implement the information interface between the event handling source 111 and the first-tier diagnostic 114, as well as to filter record information blocks or event information blocks and / or diagnostic reports.

[0046] The first-tier catcher 113 can implement the information interface between the event handling source 111 and the first-tier diagnostic 114, and implement the unified management of the first-tier diagnostic 114. The first-tier catcher 113 serves as a filter before the first-tier diagnostic 114 processes information, and the first-tier catcher 113 also serves as a filter before the first-tier diagnostic 114 generates and outputs reports.

[0047] The first-tier diagnostic (FTA, First-Tiler Algorithm / Action) 114 is used to diagnose record information blocks or event information blocks, and generate diagnostic reports based on the diagnostic results.

[0048] The first-line diagnostic device 114 is designed to implement diagnostic algorithms in the occurrence domain 11. The first-line diagnostic device 114 is specially designed to implement only simple and urgent diagnostic algorithms. The input of the first-line diagnostic device 114 comes from the information filtered by the first-line capture device 113. The output of the first-line diagnostic device 114 can be a report, which is returned to the occurrence domain 11 and flows downstream, or the first-line diagnostic device 114 can take private diagnostic actions, i.e. micro and necessary actions.

[0049] The service module (Service) 115 is connected to the event processing source and is used to provide services to the downstream of the entire occurrence domain 11, and is used to provide the information block of the event processing source and / or the diagnostic report to the downstream.

[0050] In the embodiment of the present disclosure, the software diagnostic system comprises at least one occurrence domain, which is used to record events triggered by software activities and perform a first diagnosis on the events. The occurrence domain comprises an event processing source, which is used to record and process the event source of the software activities; an information block generator, which is connected to the event processing source and is used to generate a record information block or an event information block and send the record information block or the event information block to the event processing source; a first-line diagnostic device, which is used to diagnose the record information block or the event information block and generate a diagnostic report based on the diagnostic result; and a first-line capture device, which is connected to the event processing source and the first-line diagnostic device and is used to realize information connection between the event processing source and the first-line diagnostic device and perform information filtering on the record information block or the event information block and / or the diagnostic report. Through the above method, the software diagnostic system provided by the present application can realize dynamic collection and real-time diagnosis.

[0051] On the basis of the above-mentioned embodiment of the software diagnostic system, the present application further provides another software diagnostic system, which is specifically described in Figure 2 , Figure 2 is a structural schematic diagram of another embodiment of the software diagnostic system provided by the present application.

[0052] The software diagnostic system 200 of the embodiment of the present disclosure comprises an occurrence domain 21, a processing domain 22 and an information database 23. At least one processing domain 22 is connected to the occurrence domain 21 and the information database 23, and is used to perform a second diagnosis on the events of the occurrence domain 21 and store the events and the second diagnosis result in the information database 23.

[0053] Specifically, the processing domain 22 is the place where the event information or record information is collected, forwarded, secondarily diagnosed, and secondarily acted. The event information or record information in the processing domain 22 has a time delay compared with the occurrence domain 21, and thus is not suitable for taking an intervention action with real-time requirement; however, the processing domain 22 is out of the context of the occurrence domain 21, and thus more complex diagnosis processing can be performed in the processing domain 22. The event information or record information in the processing domain 22 is generated as Set[InfoEvt,InfoRec] after being collected, and they are suitable for batch operation, improving the efficiency of forwarding and processing. The processing domain 22 can be cascaded through the cascade of the collection forwarders, to realize the cascade of the processing domains 22.

[0054] It should be noted that one occurrence domain 21 can be connected to at most one processing domain 22, and one processing domain 22 can be connected to multiple occurrence domains 21; the processing domains 22 can be cascaded, and one processing domain 22 can be connected to at most one processing domain 22. In addition, in some special cases, the occurrence domain 21 can also exist alone.

[0055] The specific structure of the processing domain 22 will be described below Figure 3 , Figure 3 is a structural schematic diagram of an embodiment of the processing domain provided in the present application. As shown in Figure 3 , the processing domain 22 of the embodiment of the present disclosure specifically includes a collection forwarder 221, a second-line diagnostic device 222, a second-line diagnostic algorithm module 223, and a processing service module 224.

[0056] The collection forwarder (ICR, Info-Command-Router) 221 is used to receive events from the upstream occurrence domain 21 or commands from the downstream processing domain 22. The functions of the collection forwarder 221 of the embodiment of the present disclosure include but are not limited to:

[0057] (1) As the core of the processing domain 22, the basic processing domain 22 only needs to provide a runtime context by the collection forwarder 221.

[0058] (2) Connected to the upstream occurrence domain 21 or processing domain 22, and can be connected to multiple upstreams.

[0059] (3) Receiving information from the upstream, and forwarding to the second-line diagnostic device 222 for local diagnostic algorithm.

[0060] (4) Receiving commands from the downstream, and deciding to forward to a certain object locally or to the upstream DMx.

[0061] (5) Ensuring the time sequence between the upstream information and the report in the second-line diagnostic algorithm module 223, and pushing to the downstream.

[0062] The second-tier diagnostician 222 is connected with the collection forwarder 221 and the second-tier diagnostic algorithm module 223, and is used to realize the information docking between the collection forwarder 221 and the second-tier diagnostic algorithm module 223, and to comprehensively diagnose based on the diagnostic reports of all the second-tier diagnostic algorithm modules 223.

[0063] Specifically, the second-tier diagnostician 222 is used to realize the comprehensive diagnostic algorithm based on the information flowing in and the reports generated by the second-tier diagnostic algorithm module 223, and is used as the information collection and filtering place before the second-tier diagnostic algorithm module 223 in the processing domain 22.

[0064] The second-tier diagnostic algorithm module 223 is used to diagnose the events received by the collection forwarder 221, and to generate diagnostic reports based on the diagnostic results.

[0065] Specifically, the second-tier diagnostic algorithm module 223 is used to design and realize the complex diagnostic algorithm based on the information transmitted by the second-tier diagnostician 222, and is used as the diagnostic algorithm realization place in the processing domain 22. The diagnostic structure of the second-tier diagnostic algorithm module 223 can be transmitted to the second-tier diagnostician 222 in the form of a report, and the second-tier diagnostician 222 can comprehensively diagnose based on the reports of all the second-tier diagnostic algorithm modules 223.

[0066] The processing service module 224 is connected with the collection forwarder 221, and is used to store the events or diagnostic reports of the collection forwarder 221 in the information database 23, or to forward the commands of the collection forwarder 221 to the downstream processing domain 22.

[0067] The following will be described in combination with Figure 4 Further, the cascade logic of the software diagnostic system 200 is described as follows, Figure 4 is a structural schematic diagram of another embodiment of the software diagnostic system provided by the present application. The cascade logic rules of the software diagnostic system 200 are summarized as follows:

[0068] (1) One occurrence domain 21 can be connected with at most one processing domain 22.

[0069] (2) In a special case, the occurrence domain 21 can exist alone.

[0070] (3) One processing domain 22 can be connected with multiple occurrence domains 21.

[0071] (4) The processing domains 22 can be cascaded.

[0072] (5) One processing domain 22 can be connected with at most one processing domain 22.

[0073] Specifically, the connection between the occurrence domain 21 and the processing domain 22, and the connection between the processing domain 22 and the processing domain 22, adopts a service module, i.e., Service. The upstream of Service is Publisher (referred to as SrvPub), and the downstream of Service is Subscriber (referred to as SrvSub).

[0074] The connection mode between the occurrence domain 21 and the processing domain 22 is described in detail in Figure 5 , Figure 5 FIG. 1 is a schematic diagram of the connection between the occurrence domain and the processing domain provided by the present application.

[0075] As shown in Figure 5 , each SrvPub can receive at most one SrvSub. Only when the SrvPub is idle, the SrvSub can subscribe, i.e., cannot preempt the existing subscription. The present application ensures that the cascading function will not become the source of new problems through this connection rule.

[0076] Specifically, the DMz connects to the publisher by calling the Connect method of the SrvSub, and starts the subscription. If the SrvPub already has an SrvSub in place, the subscription fails (Busy). When connecting to the SrvPub, the protocol parameters for starting the SrvPub to publish matching need to be provided. The DMz subscribes to the publication of DMx, and generates a “publish-subscribe session (SrvPub-SrvSub-Dialog)”. This session includes an “information block channel (InfoChannel)” and a “command channel (CommandChannel)”.

[0077] The InfoChannel is a one-way simplex mode, and only DMx actively pushes information blocks to DMz. DMz cannot push information blocks to DMx through this channel. The CommandChannel is a one-way half-duplex mode, and only DMz actively sends commands to DMx. DMx feeds back the results of command execution to DMz. DMx cannot send commands to DMz through this channel.

[0078] Please continue to refer to Figure 6 and Figure 7 , Figure 6 FIG. 1 is a schematic diagram of the connection between the occurrence domain and the processing domain provided by the present application. Figure 7 FIG. 1 is a schematic diagram of the connection between the occurrence domain and the processing domain provided by the present application.

[0079] As shown in Figure 6As shown, the software diagnosis system startup method of the embodiment of the present disclosure specifically comprises the following steps:

[0080] Step S11: Start the event processing source, the first-line capturer and the first-line diagnostic device in sequence according to the preset order.

[0081] As shown, each occurrence domain has a unique startup method, and the first step of startup is to complete the startup work of the occurrence domain itself Figure 7

[0082] Specifically, the startup method of the occurrence domain sequentially calls the startup methods of the event processing source (ARES), the information block generator (GEN), the first-line capturer (FTC), the first-line diagnostic device (FTA) and the occurrence service module (Service) in the occurrence domain, and strictly follows the startup order to ensure that there is no data generation and processing exception caused by the order in the startup process. Figure 7

[0083] It should be noted that Figure 7 only shows the startup order of a certain occurrence domain, and there may be multiple occurrence domains in the actual system, which are isolated from each other, but each maintains the same startup content and order.

[0084] Specifically, there is only one event processing source in each occurrence domain, and the startup method of the event processing source is called after the occurrence domain completes its own startup work. The event processing source first completes its own startup work, because the event processing source is the core object in the occurrence domain, therefore, the key mechanism and function of the occurrence domain are actually implemented by the event processing source.

[0085] There is only one first-line capturer object in each event processing source, and the startup method of the first-line capturer is called after the event processing source completes its own startup work. The first-line capturer first completes its own startup work, and the first-line capturer and the first-line diagnostic device are optional items, and the reason for their existence is that there is a local fast diagnostic action or algorithm in the occurrence domain. There is a group of first-line diagnostic devices in each first-line capturer, and the startup methods of the first-line diagnostic devices are sequentially called according to the preset order of the first-line diagnostic devices in the first-line capturer.

[0086] It should be noted that there is only one occurrence service module in each event processing source, and the occurrence service module is an optional item in the event processing source, and only needs to be started when cascade and command control are needed.

[0087] Specifically, please refer to Figure 8 , Figure 8 is the logic system diagram of the startup of the occurrence service module provided by the present application. As shown in Figure 8 ​​As shown, the event processing source starts a timer in the event processing source scope, named CmdTimer, after calling the start method of the occurrence service module.

[0088] The CmdTimer is used to receive commands from the occurrence service module, and the CmdTimer shares a root timer with other information generators of the event processing source, so that there is only one running context of the timer in the event processing source.

[0089] The timer of the CmdTimer of the event processing source expires, and the RecvCmd_F method of the occurrence service module is called to receive the queued command. The event processing source parses the doorplate information in the newly received command, finds the destination of the occurrence service module, the line sniffer / line diagnostic device, the information block generator or the event processing source itself, and returns the result of the command execution to the occurrence service module, and finally occurs to the sender of the corresponding command.

[0090] Step S12: Start the information block generator to complete the start of the occurrence domain.

[0091] Each event processing source has a group of information block generator objects, and the start method of each object is called. Because the information block generator is the real information input source in the occurrence domain, as a required option in the event processing source, the start of the information block generator must be the last, to ensure that other objects are ready to process the standard information generated by the information block generator, and to avoid algorithm misjudgment caused by inconsistent information during the start process.

[0092] Specifically, please refer to Figure 9 , Figure 9 is the logical system diagram of the start of the information block generator provided by the present application. As shown in Figure 9 , the information block generator calls the StartTimer method of the event processing source, which indirectly calls the timer determined when the event processing source is started.

[0093] The information generated in the information block generator needs to be transmitted to the event processing source for processing. The present application uses the method of providing a timer by the event processing source, and one or more timers are started by the information block generator as needed.

[0094] By using the above method, the timers of the entire occurrence domain are the same, and the StartTimer method provided by the event processing source is provided for the information block generator, so that all the timers to be started by the information block generators in the occurrence domain are managed by the event processing source. The event processing source ensures that there is only one running context in the entire occurrence domain, so as to realize the non-concurrent running environment of the occurrence domain, reduce the design and implementation complexity of the occurrence domain, and achieve the requirements of simplicity, efficiency and stability of the occurrence domain.

[0095] In addition, after the start of the occurrence domain is completed, the following continues to introduce how the occurrence domain completes the diagnosis of software activities, please refer to Figure 10 , Figure 10 is a flowchart of another embodiment of the software diagnosis system startup method provided by the present application.

[0096] As Figure 10 shown, the software diagnosis system startup method of the embodiment of the present application specifically includes the following steps:

[0097] Step S21: when the information timer of the information block generator expires, wake up the event processing source.

[0098] Among them, when the timer registered by the information block generator in the occurrence domain expires, wake up the event processing source. The timer here is managed by the event processing source, and the StartTimer of the event processing source called by the information block generator will also be merged into the timer, ensuring that the event processing source has unique management of the timers in the occurrence domain.

[0099] Step S22: generate the information block of the pre-set standard data type through the information block generator.

[0100] Among them, the event processing source calls the Timer_F method of the information block generator. In the Timer_F method of the information block generator, if there is information generation, the standard data type (iADS_Info_T) of the diagnosis system is generated. Then, directly call the ProcessInfo_F method of the event processing source to process the newly generated information. Among them, iADS_Info_T here is the standard normalized data structure of the diagnosis system of the present application, which solves the problem that the original information at the input end of the information block generator is too diverse. These various information must be normalized to a standard data structure before entering the diagnosis system.

[0101] Step S23: call the event processing source to process the information block.

[0102] Among them, in the ProcessInfo_F method of the event processing source, the information to be processed is cached first, and then the ProcessInfo_F method of the first-line catcher is called. The ProcessInfo_F method will call the ProcessInfo_F method of the first-line diagnostic device in turn. The above methods are all object running methods, and the calling party calls according to the method name of the object. The efficiency of function call can reach the highest, which can achieve the effect of fast diagnosis through the indirect call of the information block generator to the first-line diagnostic device through the event processing source.

[0103] In the process of ProcessInfo_F method of the line capturer and the line diagnostician, the diagnostic report, i.e. iADS_Report_T, can be generated, and in the process, the PostReport_F method of the event handler source can be called directly or indirectly. The PostReport_F method of the event handler source temporarily caches the report generated by the line capturer and the line diagnostician. The return of the PostReport_F method of the event handler source is equivalent to the completion of the current Timer_F process of the information block generator.

[0104] The event handler source sequentially calls the PostInfo_F method and the PostReport_F method of the occurrence service module according to the order of the cached information and report, and pushes them to the downstream.

[0105] For example, as shown in the system diagram of memory leakage Figure 11 After the GEN_meminfo and the FTAction_MemLeak in the DMO_USpace_ProcFS call the Start method, they are switched to the Running state, i.e. they automatically start the system-level MemLeak diagnostic behavior.

[0106] The GEN_meminfo takes the meminfo file under the directory of the PROC file system as the information source, and periodically (for example, 60 seconds) reads the information (for example, "MemTotal" and "MemFree") that can be used by the FTAction_MemLeak for diagnosing the system-level memory leakage.

[0107] Any GEN or ACTION related to MemLeak in the iADS system, whether it has called the Start method or not, will not be switched to the Running state, and needs to be sent the RUN command. In addition, the STAction_MemLeak needs to be sent the LOAD command first, and then the RUN command.

[0108] The tool iADS_Utility sends the "DiagMemLeak" item diagnostic behavior to the DMP_USpace, manually starts the MemLeak diagnostic behavior of all domains governed by this DMP.

[0109] 1) DMP_USpace first sends a RUN command to GEN_PID_status of DMO_USpace_ProcFS and STAction_MemLeak of DMP_USpace_ProcFS, and STAction_MemLeak finds which PID is possibly in MemLeak according to the record information of GEN_meminfo and GEN_PID_status.

[0110] If DMP_USpace_ProcFS::STAction_MemLeak can preliminarily determine which PID is in MemLeak, it sends a Report to DMP_USpace::STAction_MemLeak, reporting that the PID is a suspected process of MemLeak.

[0111] The occurrence domain of the diagnostic system requires complete data collection and simple processing. To require simple processing, the occurrence domain cannot be cascaded with the upstream, and the occurrence domain can only be the terminal point on the cascade line, only generating data for preliminary diagnosis and pushing to the downstream. If multiple diagnostic nodes need to be cascaded and complex diagnosis is required, the processing domain designed in the present application needs to be used to achieve the complex diagnosis.

[0112] The processing domain can be cascaded with the upstream occurrence domain or another processing domain, and can be interfaced with another processing domain or operation and maintenance software downstream. The mutual forwarding of upstream and downstream data or the diagnosis of upstream push information and the corresponding processing of downstream issued commands can be achieved.

[0113] For details, please continue to refer to Figure 12 and Figure 13 , Figure 12 is a flowchart of an embodiment of the software diagnostic system loading method provided by the present application, Figure 13 is a structural schematic diagram of another embodiment of the processing domain provided by the present application. The software diagnostic system loading method of the embodiment of the present application is applied to the processing domain in the software diagnostic system of the above embodiment.

[0114] As shown in Figure 13 , the processing domain of the embodiment of the present application is a place for secondary diagnosis or forwarding of event or record information sets, and the processing domain can perform complex processing actions. The upstream of the processing domain can be interfaced with the occurrence domain or the processing domain, to achieve the cascade of the processing domain. Specifically, the processing domain includes a set forwarder, a two-line diagnostic device, a two-line diagnostic algorithm module, and a processing service module.

[0115] Among them, the set forwarder (ICR, Info-Command-Router) is responsible for receiving the information or records published by the upstream, can call the second-tier diagnostician to process or generate a diagnostic report, and publish it to the downstream; or forward the information or records from the upstream to the downstream. Meanwhile, the corresponding node can be found through the routing information in the control command issued by the downstream, and the corresponding processing action is performed.

[0116] The second-tier diagnostician (STD) has a default "log" capability, and also has the capability of calling the second-tier diagnostic algorithm module. The second-tier diagnostician also provides a registration mechanism to support the dynamic registration of the second-tier diagnostic algorithm module. The second-tier diagnostician also has the capability of generating a "report". Here, the report refers to a diagnostic report for a certain period of time, certain selected events or record information of the processing domain.

[0117] The second-tier diagnostic algorithm module (STA) can perform complex diagnostic processing. The second-tier diagnostic algorithm module can be specified at static compilation time or registered at dynamic runtime. That is, the second-tier diagnostic algorithm module implements the iADS_STA_ExecCommand, iADS_STA_ProcessInfoSet, iADS_STA_Start, iADS_STA_Stop, and iADS_STA_DoorplateInfoGet interfaces, is compiled into an so file, and when needed, the second-tier diagnostician responds to the command issued by the downstream, is dynamically loaded, reads the interface implementation address, and then implements the dynamic second-tier diagnostic algorithm module startup and running.

[0118] The processing domain is connected by using a processing service module, and the upstream of the processing service module is a Publisher, referred to as SrvPub, and the downstream of the processing service module is a Subscriber, referred to as SrvSub.

[0119] In an embedded device, for some memory-constrained environments, if the processing domain is started, all static second-tier diagnostic algorithm modules are loaded, which may cause process startup failure and abnormal functions. To solve this problem, the application designs a dynamic loading scheme for the second-tier diagnostic algorithm module. Based on the logical system diagram of the structure and Figure 14 The software diagnostic system loading method provided by the embodiment of the present disclosure specifically includes the following steps:

[0120] Step S31: Obtain the command for loading the dynamic second-tier diagnostic algorithm module received by the processing service module, wherein the command includes doorplate information and address information of the dynamic second-tier diagnostic algorithm module.

[0121] As shown in Figure 14 The downstream SvrSub issues a command to the SrvPub of the corresponding processing domain node to load the dynamic two-line diagnosis algorithm model of the specified processing domain, and the command carries the address information of the dynamic two-line diagnosis algorithm module.

[0122] Specifically, since the processing domain can be cascaded, the processing domain is further divided into a collection forwarder, a two-line diagnostic device, a two-line diagnosis algorithm module, an SrvPub module, and an SrvSub module. The control command needs to be issued to a specific module for execution, and the doorplate information needs to be carried in the command message to enable the collection forwarder to find the specific module for processing. The doorplate includes the following three types of information: function domain information, entity information, and process thread information.

[0123] The function domain information mainly indicates whether it is a domain or a processing domain, or a specific implementation category in the domain or the processing domain. The following encoding can be used as a reference: the memory domain is encoded as 1, the CPU domain is encoded as 2, and the thread domain is encoded as 3. The memory processing domain is encoded as 0x81, the CPU processing domain is encoded as 0x82, and the thread processing domain is encoded as 0x83.

[0124] The entity information mainly distinguishes different modules in the same domain. The following encoding can be used as a reference: the ICR is encoded as 1, the STD is encoded as 2, and the SrvPub is encoded as 3.

[0125] The process thread information may be deployed in different processes A and B in the same function domain, and a command may only need to be processed by process A. The process ID of process A is filled in the process thread information to ensure that the command is executed by process A and not by process B.

[0126] Step S32: Check whether there is received data through the start thread of the processing service module and the connection established with the domain or other processing domain.

[0127] Among them, the thread started by the SrvPub under the corresponding processing domain node periodically checks whether there is data from the established connection, and if there is data, it enters step S33.

[0128] Step S33: Copy the received data through the processing thread through the message mechanism.

[0129] Step S34: Check whether there is a message of copied data through the collection forwarder.

[0130] Wherein, the receiving thread of the collection forwarder periodically calls the OpRecvCmd_F (receive data method) of the collection forwarder to check whether there is a stolen data message, and if so, calls the OpRecvCmd_F with the OpExecCmd_F (execute command method) as the input parameter, so that it steals the data and then calls the OpExecCmd_F to process the data.

[0131] OpExecCmd_F checks through the doorplate that it is sent to the second-line diagnostic instrument, and calls the ExecCmd_F of the second-line diagnostic instrument for processing, and the processing steps are as follows:

[0132] (1) The dlopen function loads the so file of the second-line diagnostic algorithm module under the path information carried by the command.

[0133] (2) The dlsym interface is called to obtain the start method represented by iADS_STA_Start and saved.

[0134] (3) The dlsym interface is called to obtain the stop method represented by iADS_STA_Stop and saved.

[0135] (4) The dlsym interface is called to obtain the ExecCmd_F method of executing downstream commands represented by iADS_STA_ExecCommand and saved.

[0136] (5) The dlsym interface is called to obtain the ProcessInfoSet method of processing upstream push information represented by iADS_STA_ProcessInfoSet and saved.

[0137] (6) The dlsym interface is called to obtain the address of the iADS_STA_DoorplateInfoGet interface and called to save the doorplate information of the dynamic second-line diagnostic algorithm module, so that the address can be successfully addressed when the downstream issued command is processed subsequently.

[0138] (7) After calling the start method to start the second-line diagnostic algorithm module, the dynamic second-line diagnostic algorithm module can be normally used. The upstream information is processed by calling the ProcessInfoSet method, and the downstream command is processed by calling the ExecCmd_F method.

[0139] Step S35: Based on the doorplate information, the dynamic second-line diagnostic algorithm module corresponding to the address information is called by the second-line diagnostic instrument to perform secondary diagnosis on the data.

[0140] Wherein, before loading the dynamic second-line diagnostic algorithm module, the processing domain needs to be started first. The specific logic of starting the processing domain is described in Figure 15 , Figure 15is a logical system diagram provided by the application.

[0141] As shown in Figure 15 each processing domain has a unique starting method, and there is only one collection forwarder in the processing domain, and the starting method of the collection forwarder is called to complete the starting of the entire processing domain.

[0142] Specifically, there can be multiple SvrSub objects in each collection forwarder, responsible for communication with the upstream occurrence domain or cascaded processing domain. During starting, the control blocks of the SvrSub objects are traversed, and the starting method of SvrSub is called with the control block as the input parameter, and according to the protocol type configured by the input parameter, the SvrSub object triggers connection to the corresponding upstream SvrPub using different protocols. According to the corresponding protocol type configured, the corresponding protocol message receiving, sending and processing method is saved to the control block of each SvrSub object.

[0143] There is only one SvrPub object in each collection forwarder, responsible for receiving data transmission after the downstream connection request. During starting, the starting method of SvrPub is called to start a thread to listen to the connection event, and if data is received after the connection is established, the processing thread is notified through the message mechanism (such as semaphore synchronization).

[0144] There is only one two-line diagnostic instrument in each collection forwarder, and the starting interface of the two-line diagnostic instrument is called to start the diagnostic logic.

[0145] There can be multiple two-line diagnostic algorithm modules in each collection forwarder, and the starting method of the statically linked two-line diagnostic algorithm module is called to start one by one. For the starting of the dynamically linked two-line diagnostic algorithm module, it is triggered in response to the command during running.

[0146] The collection forwarder needs an independent thread context to run. When the processing domain starts, the control block information of the processing domain is called as the input parameter to start the starting method of the collection forwarder. The collection forwarder stores these different processing domain control block information in a list, and then starts a processing thread to periodically traverse the linked list nodes, obtain the processing domain control block information of each processing domain, and call the processing method of the control block to process data.

[0147] Finally, after the starting method of the collection forwarder is called, the processing domain is successfully started.

[0148] Those skilled in the art can understand that in the above method of the specific implementation, the writing order of each step does not mean a strict execution order and does not constitute any limitation on the implementation process, and the specific execution order of each step should be determined by its function and possible internal logic.

[0149] In order to realize the control method of the software diagnosis system of the above-mentioned embodiments, including the software diagnosis system starting method and the software diagnosis system loading method, the application provides a terminal device, and the specific embodiments are described below Figure 16 , Figure 16 is a structural schematic diagram of an embodiment of the terminal device provided by the application.

[0150] As shown in Figure 16 , the terminal device 500 of the embodiment includes a processor 51, a memory 52, an input / output device 53, and a bus 54.

[0151] The processor 51, the memory 52, and the input / output device 53 are connected to the bus 54, respectively. The memory 52 stores a computer program, and the processor 51 is configured to execute the computer program to realize the software diagnosis system starting method and / or the software diagnosis system loading method of the above-mentioned embodiments.

[0152] In the embodiment, the processor 51 can also be referred to as a CPU (Central Processing Unit). The processor 51 can be an integrated circuit chip with signal processing capability. The processor 51 can also be a general-purpose processor, a DSP (Digital Signal Processor), an ASIC (Application-Specific Integrated Circuit), an FPGA (Field-Programmable Gate Array) or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components. The processor 51 can also be a GPU (Graphics Processing Unit), also known as a display core, a visual processor, or a display chip, which is a microprocessor specially designed for image operation on personal computers, workstations, game consoles, and some mobile devices (such as tablets, smartphones, etc.). The purpose of the GPU is to convert the display information required by the computer system and drive it to the display, control the correct display of the display, and is an important element connecting the display and the mainboard of the personal computer, and is one of the important devices for "man-machine dialogue". As an important part of the computer host, the display card undertakes the task of outputting display graphics, which is very important for people engaged in professional graphic design. The general-purpose processor can be a microprocessor, or the processor 51 can be any conventional processor, etc.

[0153] The application further provides a computer-readable storage medium, as shown in Figure 17 , the computer-readable storage medium 600 is configured to store a computer program 61, and the computer program 61 is configured to realize the method described in the software diagnosis system starting method and / or the software diagnosis system loading method of the application when executed by the processor.

[0154] The method involved in the embodiments of the software diagnosis system starting method and / or the software diagnosis system loading method exists in the form of a software function unit in implementation and is sold or used as an independent product, and can be stored in a device, such as a computer readable storage medium. Based on such an understanding, the technical solutions of the present application, essentially or in other words, the part that contributes to the prior art or the whole or part of the technical solutions can be embodied in the form of a software product. The computer software product is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to execute all or part of the steps of the method described in the various embodiments of the present application. The aforementioned storage medium includes: a U disk, a mobile hard disk, a read-only memory (ROM, Read-Only Memory), a random access memory (RAM, Random Access Memory), a magnetic disk or an optical disk, and various media that can store program codes.

[0155] The above description is only an embodiment of the present application, and does not limit the patent scope of the present application. Any equivalent structure or equivalent process transformation, or direct or indirect application in other related technical fields, based on the content of the specification and drawings of the present application, are also included in the patent protection scope of the present application.

Claims

1. A software diagnostic system, characterized by, The software diagnosis system comprises: at least one occurrence domain for recording events triggered by software activities and performing primary diagnosis on the events; the occurrence domain comprises: an event processing source for recording and processing event sources of the software activities; an information block generator connected to the event processing source for generating recording information blocks or event information blocks and sending the recording information blocks or the event information blocks to the event processing source; a primary diagnosis device for diagnosing the recording information blocks or the event information blocks and generating diagnosis reports based on diagnosis results; a primary capture device connected to the event processing source and the primary diagnosis device for realizing information docking between the event processing source and the primary diagnosis device and information filtering on the recording information blocks or the event information blocks and / or the diagnosis reports.

2. The software diagnostic system of claim 1, wherein, The occurrence domain further comprises: an occurrence service module connected to the event processing source for providing information blocks and / or diagnosis reports of the event processing source to downstream.

3. The software diagnostic system of claim 1, wherein, The software diagnosis system further comprises: an information database; at least one processing domain connected to the occurrence domain and the information database for performing secondary diagnosis on events of the occurrence domain and storing the events and secondary diagnosis results in the information database.

4. The software diagnostic system of claim 3, wherein, The software diagnosis system comprises the information database, the primary processing domain, the secondary processing domain and the occurrence domain; wherein the primary processing domain is connected to the information database and cascaded with the secondary processing domain; and the secondary processing domain is connected to at least one occurrence domain.

5. The software diagnostic system of claim 3, wherein, The processing domain comprises: a collection forwarder for receiving events from upstream occurrence domains or commands from downstream processing domains; a secondary diagnosis algorithm module for diagnosing events received by the collection forwarder and generating diagnosis reports based on diagnosis results; a secondary diagnosis device connected to the collection forwarder and the secondary diagnosis algorithm module for realizing information docking between the collection forwarder and the secondary diagnosis algorithm module and comprehensively diagnosing diagnosis reports of all the secondary diagnosis algorithm modules.

6. The software diagnostic system of claim 5, wherein, The processing domain further comprises: a processing service module connected to the collection forwarder for storing events or diagnosis reports of the collection forwarder in the information database or forwarding commands of the collection forwarder to downstream processing domains.

7. The software diagnosis system according to claim 6, wherein: the secondary diagnosis algorithm module comprises a dynamic secondary diagnosis algorithm module and a static secondary diagnosis algorithm module; the processing service module is configured to receive a command for loading the dynamic secondary diagnosis algorithm module, wherein the command comprises doorplate information and address information of the dynamic secondary diagnosis algorithm module; and the collection forwarder is configured to check, by a start thread of the processing service module, whether data received from a connection established with an occurrence domain or another processing domain exists, and copy the received data by a processing thread through a message mechanism when the data exists. The collection forwarder is further configured to check whether there is a message copying data, and if so, call the second-line diagnostic device to load a dynamic second-line diagnostic algorithm module corresponding to the address information based on the house number information, so as to perform secondary diagnosis on the data. 8.The software diagnosis system of claim 7, wherein, The collection forwarder is further configured to load a dynamic link library of the dynamic second-line diagnostic algorithm module corresponding to the address information, call a preset interface to obtain a starting method of the dynamic second-line diagnostic algorithm module, and start the dynamic second-line diagnostic algorithm module by calling the starting method. 9.The software diagnosis system of claim 1, wherein, The occurrence domain is configured to sequentially start the event processing source, the first-line catcher, the first-line diagnostic device, and the information block generator in a preset order, so as to complete the starting of the occurrence domain. The information block generator uses the information timer provided by the event processing source when starting. 10.The software diagnosis system of claim 9, wherein, The occurrence domain is further configured to wake up the event processing source when the information timer of the information block generator expires, generate an information block of a pre-set standard data type by the information block generator, and call the event processing source to process the information block.

Images