CN115114138A

CN115114138A - Software diagnosis system starting method and system, equipment and storage medium thereof

Info

Publication number: CN115114138A
Application number: CN202110287688.6A
Authority: CN
Inventors: 潘武; 吴惠敏
Original assignee: Zhejiang Dahua Technology Co Ltd
Current assignee: Zhejiang Dahua Technology Co Ltd
Priority date: 2021-03-17
Filing date: 2021-03-17
Publication date: 2022-09-27

Abstract

The application discloses a software diagnosis system starting method, a system, equipment and a storage medium thereof, wherein the software diagnosis system starting method is applied to an occurrence domain in a system software diagnosis system, and the occurrence domain comprises an event processing source, an information block generator, a first line catcher and a first line diagnostor, wherein the event processing source is respectively connected with the information block generator and the first line catcher, and the first line catcher is connected with the first line diagnostor; the software diagnosis system starting method comprises the following steps: sequentially starting an event processing source, a first-line catcher and a first-line diagnostor according to a preset sequence; starting an information block generator to complete the starting of the occurrence domain; wherein, the information block generator adopts the information timer provided by the event processing source when starting. By the method, the objects in the occurrence domain are started one by one and in sequence, so that data generation and processing abnormity caused by sequence is avoided in the starting process, and the stability of the occurrence domain is improved.

Description

Software diagnosis system starting method and system, equipment and storage medium thereof

Technical Field

The present application relates to the field of computer application technologies, and in particular, to a software diagnostic system starting method, a software diagnostic system starting system, a software diagnostic system starting device, and a storage medium.

Background

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

Currently, for a diagnostic system of software activity, a typical separate structure of "acquisition" and "analysis" is adopted, that is, the acquisition is independent and the analysis is independent, and the acquisition adopts a "complete" mode and the analysis adopts an "offline" mode. The existing generation domain system structure and starting mode responsible for collection often cause data generation and processing to be abnormal due to disorder of starting sequence.

Disclosure of Invention

The application provides a software diagnosis system starting method, a system, equipment and a storage medium thereof.

The technical scheme provided by the application is as follows: providing a software diagnosis system starting method, wherein the software diagnosis system starting method is applied to an occurrence domain in a system software diagnosis system, and the occurrence domain comprises an event processing source, an information block generator, a line catcher and a line diagnostor, wherein the event processing source is respectively connected with the information block generator and the line catcher, and the line catcher is connected with the line diagnostor;

the software diagnosis system starting method comprises the following steps:

the event processing source, the first-line catcher and the first-line diagnostor are sequentially started according to a preset sequence;

starting the information block generator to complete the starting of the occurrence domain;

wherein, the information block generator adopts the information timer provided by the event processing source when starting.

Another technical solution provided by the present application is: providing a system software diagnostic system, the system software diagnostic system comprising:

at least one occurrence domain, which is used for recording the event triggered by the software activity and carrying out diagnosis once on the event;

the generation domain includes:

an event processing source for recording and processing event sources of the software activities;

the information block generator is connected with the event processing source and used 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 first-line diagnotor for diagnosing the log information block or the event information block and generating a diagnosis report based on the diagnosis result;

and the front-line catcher is connected with the event processing source and the front-line diagnotor and is used for realizing the information interface of the event processing source and the front-line diagnotor and carrying out information filtering on the record information block or the event information block and/or the diagnosis report.

Another technical solution provided by the present application is: there is provided a terminal device comprising a processor and a memory, the memory having stored therein a computer program, the processor being configured to execute the computer program to implement the steps of the software diagnostic system startup method described above.

Another technical scheme adopted by the application is as follows: there is provided a computer readable storage medium, wherein the computer readable storage medium stores a computer program, which when executed implements the steps of the software diagnostic system startup method described above.

Different from the prior art, the beneficial effects of this application lie in: the software diagnosis system starting method is applied to an occurrence domain in a system software diagnosis system, wherein the occurrence domain comprises an event processing source, an information block generator, a first line catcher and a first line diagnotor, the event processing source is respectively connected with the information block generator and the first line catcher, and the first line catcher is connected with the first line diagnotor; the software diagnosis system starting method comprises the following steps: sequentially starting an event processing source, a first-line catcher and a first-line diagnostor according to a preset sequence; starting an information block generator to complete the starting of the occurrence domain; wherein, the information block generator adopts the information timer provided by the event processing source when starting. By the method, the objects in the occurrence domain are started one by one and in sequence, so that data generation and processing abnormity caused by sequence is avoided in the starting process, and the stability of the occurrence domain is improved.

Drawings

In order to more clearly illustrate the technical solutions in the embodiments of the present invention, the drawings needed to be used in the description of the embodiments are briefly introduced below, and it is obvious that the drawings in the following description are only some embodiments of the present invention, and it is obvious for those skilled in the art to obtain other drawings based on these drawings without creative efforts.

FIG. 1 is a schematic block diagram of an embodiment of a system software diagnostic system provided herein;

FIG. 2 is a schematic block diagram of another embodiment of a system software diagnostic system provided herein;

FIG. 3 is a schematic diagram of an embodiment of a processing domain provided herein;

FIG. 4 is a schematic block diagram of another embodiment of a system software diagnostic system provided in the present application;

FIG. 5 is a schematic diagram of the connection of a generation domain and a processing domain provided herein;

FIG. 6 is a flowchart illustrating an embodiment of a software diagnostic system booting method provided herein;

FIG. 7 is a logical system diagram of domain launching as provided herein;

FIG. 8 is a system diagram of the logic provided herein for service module initiation;

FIG. 9 is a diagram of a logical system for the initiation of a chunk generator as provided herein;

FIG. 10 is a schematic flow chart diagram illustrating another embodiment of a software diagnostic system startup method provided herein;

FIG. 11 is a system diagram illustrating an embodiment of a memory leak provided herein;

FIG. 12 is a flowchart illustrating an embodiment of a software diagnostic system loading method provided herein;

FIG. 13 is a schematic diagram of another embodiment of a processing domain provided herein;

FIG. 14 is a logical system diagram of the operation of the processing domains provided herein;

FIG. 15 is a logical system diagram of the processing domain startup provided herein;

fig. 16 is a schematic structural diagram of an embodiment of a terminal device provided in the present application;

FIG. 17 is a schematic structural diagram of an embodiment of a computer-readable storage medium provided in the present application.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

Referring to fig. 1, fig. 1 is a schematic structural diagram of an embodiment of a system software diagnostic system provided in the present application.

The system software diagnosis system 100 of the embodiment of the present disclosure includes at least one occurrence Domain 11(DMO ═ Domain interrupt), where the occurrence Domain 11 may exist in the form of an independent process, that is, the whole terminal device only needs one occurrence Domain 11 to complete the diagnosis of software activities.

In particular, the occurrence domain 11 serves as the place where the event or record occurred and was captured first, the occurrence domain 11 may be the place where the event or record first triggered the action, and the triggering of all actions within the occurrence domain 11 may take the form of a function call. Thus, the occurrence domain 11 can take the shortest path, the fastest, most efficient processing means to complete the diagnosis of software activity.

The occurrence domain 11 of the present application is classified according to the type of the collected information, such as a call tracking class, a ProcFS information collection class, and a NetStat statistics class. The staff can design a plurality of varieties according to different requirements, and is suitable for the generation domain 11 generated by different information acquisition.

The existence of the occurrence domain 11 can be realized by taking a process as a unit and generating one or more occurrence domain 11 instances in each process according to requirements, wherein the same occurrence domain 11 can only have one instance in a certain process. For example, the diagnosis of function call tracing needs to collect information about the entry and exit of each function, so each process needs to call an instance of the trace-class occurrence domain 11, that is, the same-type occurrence domain 11 has multiple instances in multiple processes.

In addition, the occurrence domain 11 can also exist in an independent process form, for example, the occurrence domain 11 collects kernel events, the whole software system only needs one instance, and when the occurrence domain 11 is required to collect events, only the instance of the process in which the occurrence domain 11 is located needs to be found.

The generation domain 11 of the embodiment of the present disclosure is suitable for independent collection and aggregation of multiple instances of the same type in multiple processes, and is also suitable for collection as required by the whole system, and collection and sharing of information in independent processes.

Specifically, the occurrence domain 11 of the embodiment of the present disclosure further includes an event processing source 111, an information block generator 112, a line diagnoser 114, a line catcher 113, and an occurrence service module 115.

Among them, an Event processing Source (ARES) 111, an Event Source for recording and processing 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, ensuring that the single thread mode is adopted for design and implementation in the occurrence domain 11.

The context here on the one hand serves as a timer for the information block generator 112, periodically calling a timer function for the information block generator 112. Specifically, the information collected and generated by the information block generator 112 first occurs to the event processing source 111, is transmitted by the event processing source 111 to the line catcher 113 for processing, and finally is individually given to the line diagnoser 114 by the line catcher 113 for diagnostic processing. The context here, on the other hand, provides the occurrence service module 115 with a timer for periodically checking commands sent downstream.

In addition, when the first-line capturer 113 and the first-line diagnoser 114 process information, a report of processing information is generated, the report is generated in the middle of processing, the report is cached at the event processing source 111, and the event processing source 111 finally maintains the time sequence of the information and the report and pushes the information and the report to the downstream of subscription through the occurrence service module 115.

An information block Generator (GEN) 112 connected to the event processing source 111 for generating and transmitting the recording information block or the event information block to the event processing source.

The information block generator 112 may collect and generate non-standardized information, and format the information into an internal unified data format. The information block generator 112 relies on the timer provided by the event processing source 111 as context.

The First-Tier Catcher (FTC) 113 is connected to the event processing source 111 and the First-Tier diagnostor 114, and is configured to interface the event processing source 111 with the First-Tier diagnostor 114 and filter the recorded information block or the event information block and/or the diagnostic report.

The first line catcher 113 can realize the information interface between the event processing source 111 and the first line diagnoser 114, and realize the unified management of the first line diagnoser 114. The first line catcher 113 serves as a filter before the first line diagnoser 114 processes the information, and the first line catcher 113 serves as a filter before the first line diagnoser 114 generates the report.

Wherein, a First-line diagnoser (FTA) 114 is used for diagnosing the recording information block or the event information block and generating a diagnosis report based on the diagnosis result.

The first line diagnostics 114 is where the diagnostic algorithms in the generation domain 11 are implemented, and the first line diagnostics 114 is specifically designed to implement only simple but urgent diagnostic algorithms. The input to the first line diagnoser 114 is the information filtered from the first line capturer 113, the output of the first line diagnoser 114 can be a report, which continues back to the field of occurrence 11 and flows downstream, or the diagnostic actions proprietary to the first line diagnoser 114, i.e., micro, required actions, can be taken.

The occurrence Service module (Service)115, as a Service provided by the entire occurrence domain 11 to the downstream, is connected to the event processing source, and is configured to provide the information block and/or the diagnosis report of the event processing source to the downstream.

In an embodiment of the present disclosure, a system software diagnostic system includes: at least one occurrence domain, which is used for recording the event triggered by the software activity and carrying out primary diagnosis on the event; the occurrence domain includes: an event processing source for recording and processing event sources of software activities; the information block generator is connected with the event processing source and used 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 first-line diagnotor for diagnosing the log information block or the event information block and generating a diagnosis report based on the diagnosis result; and the first-line catcher is connected with the event processing source and the first-line diagnotor and is used for realizing the information interface between the event processing source and the first-line diagnotor and carrying out information filtering on the recorded information block or the event information block and/or the diagnosis report. By the method, dynamic acquisition and real-time diagnosis can be realized by providing the system software diagnosis system.

On the basis of the above system software diagnostic system embodiment, the present application also provides another system software diagnostic system, specifically refer to fig. 2, and fig. 2 is a schematic structural diagram of another embodiment of the system software diagnostic system provided by the present application.

The system software diagnostic system 200 of the embodiment of the present disclosure includes an occurrence domain 21, a processing domain 22, and an information database 23. Wherein, at least one processing domain 22 is connected with the occurrence domain 21 and the information database 23, and is used for performing secondary diagnosis on the event of the occurrence domain 21 and storing the event and the secondary diagnosis result in the information database 23.

Specifically, the processing domain 22 serves as a place where event information or recorded information is collected, forwarded, subjected to secondary diagnosis, and subjected to secondary action. Processing event information or log information in the field 22, which has been delayed compared to the occurrence field 21, is not suitable for taking intervention actions requiring real-time performance; however, the processing domain 22 has moved out of the context of the occurrence domain 21, and more complex diagnostic processing can be performed in the processing domain 22. Event information or record information in the processing domain 22 is collected to generate Set [ InfoEvt, InfoRec ], which are suitable for batch operation and improve the efficiency of forwarding and processing. The processing domains 22 may implement a cascade of processing domains 22 through a cascade of set forwarders.

It should be noted that at most one occurrence domain 21 can only be connected to 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 at most one processing domain 22 can be connected out of one processing domain 22. In addition, in some special cases, the occurrence field 21 may exist alone.

With reference to fig. 3, fig. 3 is a schematic structural diagram of an embodiment of the processing domain provided in the present application. As shown in fig. 3, the processing domain 22 of the embodiment of the present disclosure specifically includes a set forwarder 221, a two-wire diagnotor 222, a two-wire diagnostic algorithm module 223, and a processing service module 224.

Among them, an aggregation forwarder (ICR) 221 is configured to receive an event from the upstream occurrence domain 21 or a Command from the downstream processing domain 22. The functions of the aggregation forwarder 221 of the disclosed embodiment include, but are not limited to:

(1) as the core of the processing domain 22, the basic processing domain 22 only needs to be provided with one runtime context by the set forwarder 221.

(2) The generation domain 21 or the processing domain 22 connected to the upstream may be connected to a plurality of upstream.

(3) Information from upstream is received and forwarded to the two-line diagnotor 222 for local diagnostic algorithms.

(4) Commands from downstream are received and a decision is made to forward to some object locally or to an upstream DMx.

(5) The chronological order between the information upstream and the report in the two-line diagnostic algorithm module 223 is ensured and pushed downstream.

Wherein, the Second line diagnostor (STD) 222 is connected to the set repeater 221 and the Second line diagnostic algorithm module 223, and is used for implementing information docking between the set repeater 221 and the Second line diagnostic algorithm module 223, and integrating the diagnostic reports of all the Second line diagnostic algorithm modules 223 to perform comprehensive diagnosis.

Specifically, the two-wire diagnotor 222, as a place for information gathering and filtering before the two-wire diagnostic algorithm module 223 within the processing domain 22, may implement a comprehensive diagnostic algorithm with respect to the incoming information, as well as the reports generated by the two-wire diagnostic algorithm module 223.

Wherein, a two-line diagnostic Algorithm module (STA: Second-Tier Algorithm)223 is used to diagnose the events received by the set repeater 221 and generate a diagnostic report based on the diagnostic result.

Specifically, the two-wire diagnostic algorithm module 223 is used as a diagnostic algorithm implementation site of the processing domain 22, and the two-wire diagnostic algorithm module 223 can perform complex diagnostic algorithm design and implementation according to the information transmitted by the two-wire diagnoser 222. The diagnostic structure of the two-line diagnostic algorithm module 223 may be transmitted to the two-line diagnotor 222 in the form of a report, and the two-line diagnotor 222 synthesizes all the reports of the two-line diagnostic algorithm module 223 to perform a comprehensive diagnosis.

The processing service module 224 is connected to the aggregation forwarder 221, and is configured to store the event or diagnosis report of the aggregation forwarder 221 in the information database 23, or forward the command of the aggregation forwarder 221 to the downstream processing domain 22.

The cascade logic of the system software diagnostic system 200 is further described below with reference to fig. 4, and fig. 4 is a schematic structural diagram of another embodiment of the system software diagnostic system provided in the present application. Summarizing the cascading logic rules of the system software diagnostic system 200 are as follows:

(1) a generation domain 21 can only tap out at most one processing domain 22.

(2) In special cases, the occurrence field 21 may exist alone.

(3) One processing domain 22 may access multiple generation domains 21.

(4) The processing domains 22 may be cascaded.

(5) A processing domain 22 can only be tapped off at most one processing domain 22.

Specifically, the generation domain 21 and the processing domain 22, and the processing domain 22 are connected by using a Service module, i.e., a Service. The upstream of Service is Publisher, SrvPub for short, and the downstream of Service is Subscriber, SrvSub for short.

Referring to fig. 5, fig. 5 is a schematic diagram illustrating a connection between a generation domain 21 and a processing domain 22.

As shown in fig. 5, each SrvPub can only receive one SrvSub at most, and SrvSub can subscribe only when SrvPub is idle, that is, the existing subscription cannot be preempted.

Specifically, DMz connects to the publisher by calling the Connect method of SrvSub, initiating the subscription. If SrvPub already has SrvSub in place, then this subscription fails (Busy). When the SrvPub is connected, the protocol parameters of SrvPub starting to issue matching need to be provided. DMz subscribes to the successful release of DMx, and generates a "release subscription session (SrvPub-SrvSub-Dialog)" which contains an "information block channel (InfoChannel)" and a "command channel (CommandChannel)".

The InfoChannel is a unidirectional simplex mode, only DMx actively pushes the information block to DMz, and DMz cannot push the information block to DMx through the channel. The Commandchannel is in a unidirectional half-duplex mode, only the DMz actively sends a command to the DMx, and the DMx feeds back a result of command execution to the DMz, so that the DMx cannot send the command to the DMz through the channel.

Referring to fig. 6 and fig. 7, fig. 6 is a schematic flowchart of an embodiment of a software diagnostic system boot method provided in the present application, and fig. 7 is a logic system diagram of domain boot provided in the present application. The software diagnostic system starting method of the embodiment of the disclosure is applied to the occurrence domain in the system software diagnostic system of the embodiment, and the specific structure of the occurrence domain is not described herein again.

As shown in fig. 6, the software diagnostic system starting method according to the embodiment of the present disclosure specifically includes the following steps:

step S11: and starting the event processing source, the first-line catcher and the first-line diagnostor in sequence according to a preset sequence.

As shown in FIG. 7, each occurrence domain has a unique starting method, and the first step of starting is to complete the starting work of the occurrence domain itself

Specifically, the starting method of the occurrence domain calls the starting methods of the objects in the occurrence domain, such as the event processing source (ARES), the information block Generator (GEN), the first line capturer (FTC), the first line diagnoser (FTA), the occurrence Service module (Service), and the like, one by one and in sequence, and strictly follows the starting sequence of fig. 7, so that no data generation and processing exception caused by the sequence exists in the starting process.

It should be noted that fig. 7 only illustrates the starting sequence of a certain occurrence domain, and in an actual system, there may be multiple occurrence domains, which are isolated from each other, but each of which maintains the same starting content and sequence.

Specifically, each occurrence domain has only one event processing source, and after the occurrence domain completes its own startup work, the occurrence domain calls the startup method of the event processing source. The event processing source first completes its own startup work because the event processing source is a core object in the occurrence domain, and therefore, the key mechanism and function of the occurrence domain are actually realized by the event processing source.

Each event processing source only has one line catcher object, and the starting method of the line catcher is called after the event processing source completes the starting work of the event processing source. The line catcher completes its own start-up first, and the line catcher and line diagnoser are optional items, and exist because there is a local quick diagnostic action or algorithm inside the domain. Each line trap has a set of line diagnostics, and the start-up method of the line diagnostics is called one by one according to the predetermined sequence of the line diagnostics in the line trap.

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

Specifically, please refer to fig. 8, fig. 8 is a logic system diagram of the service module initiation. As shown in fig. 8, after calling the start method of the occurrence service module, the event processing source also starts a timer in the range of the event processing source, which is named CmdTimer.

The CmdTimer is specially used for receiving a command from the occurrence service module, and shares one root Timer with other information generators of the event processing source, so that only one Timer runtime context in the event processing source is realized.

The CmdTimer timer of the event processing source expires, calling the RecvCmd _ F method of the occurrence service module, receiving the command that has come in queue. The event processing source analyzes the doorplate information in the newly received command, finds out the doorplate information with the purpose of an occurrence service module, a first-line catcher/first-line diagnostor, an information block generator or the event processing source, returns the result of executing the command to the occurrence service module, and finally sends the result to the sender of the corresponding command.

Step S12: the information block generator is started to complete the start of the occurrence field.

Wherein, each event processing source has a group of information block generator objects, and the starting method is called one by one. Because the information block generator is a real information input source in the occurrence domain and is a necessary option in the event processing source, the information block generator must be started at the end, so that other objects are ensured to be ready to process the standard information generated by the information block generator, and the misjudgment of the algorithm caused by the inconsistency of the information in the starting process is avoided.

Specifically, referring to fig. 9, fig. 9 is a logic system diagram of the start of the information block generator provided in the present application. As shown in fig. 9, the information block generator calls the StartTimer method of the event processing source, and indirectly calls the timer determined when the event processing source is started.

The information generated in the information block generator needs to be able to be transmitted to the event processing source for processing, and the method of the application adopts a method of providing a timer by the event processing source, and the information block generator starts one or a plurality of timers according to the needs.

By adopting the method, the timers of the whole occurrence domain are the same, and the StartTimer method provided by the event processing source is provided for the information block generator to be used, so that all the timers to be started by the information block generator in the occurrence domain are managed by the event processing source. The event processing source ensures that the whole occurrence domain has only one context which runs simultaneously, so that the non-concurrent running environment of the occurrence domain is realized, the design and implementation complexity of the occurrence domain is reduced, and the requirements of conciseness, high efficiency and stability of the occurrence domain are met.

In addition, after the initiation of the occurrence domain is completed, how the occurrence domain completes the diagnosis of the software activity is described below, specifically referring to fig. 10, fig. 10 is a flowchart illustrating another embodiment of the initiation method of the software diagnosis system provided by the present application.

As shown in fig. 10, the software diagnostic system starting method according to the embodiment of the present disclosure specifically includes the following steps:

step S21: when the message timer of the message block generator expires, the event processing source is awakened.

Wherein, when the timer registered by the information block generator in the domain expires, the event processing source is awakened. The timer is managed by the event processing source, and the StartTimer of the information block generator for calling the event processing source is also merged into the timer, so that the event processing source can be ensured to have unique management on the timer in the occurrence domain.

Step S22: the information block of the preset standard data type is generated by an information block generator.

Wherein, the event processing source calls the Timer _ F method of the information block generator. The information block generator generates the standard data type (iasd _ Info _ T) of the diagnostic system in the Timer _ F method if any information is generated. Then, the processInfo _ F method of the event processing source is directly called, and the newly generated information is processed. The iasd _ Info _ T is a standard normalized data structure of the diagnostic system of the present application, and it is necessary to normalize the various information, which is entered into the diagnostic system, into a standard data structure.

Step S23: and calling the event processing source to process the information block.

In the ProcessInfo _ F method of the event processing source, firstly, the information to be processed is cached, then the ProcessInfo _ F method of the line catcher is called, and the ProcessInfo _ F method can sequentially call the ProcessInfo _ F method of the line diagnotor. The method is an object operation method, the calling party calls according to the method name of the object, the efficiency of function calling can reach the highest, the method that the information block generator indirectly calls the first-line diagnotor through the event processing source can be achieved, and the effect of rapid diagnosis is achieved.

During the ProcessInfo _ F method of the line grabber and the line diagnoser, a diagnostic Report may be generated, i.e., iADS _ Report _ T, and during processing, the PostReport _ F method of the event processing source may be directly or indirectly called. The PostReport _ F method of the event processing source temporarily caches reports generated by the line grabber and line diagnoser. The return of the PostReport _ F method of the event processing source is equivalent to the completion of the current Timer _ F processing of the information block generator.

And the event processing source calls the cached information and the report respectively according to the order to a PostInfo _ F method and a PostReport _ F method of the service generation module and pushes the information and the report to the downstream.

For example, as shown in the system diagram of memory leak shown in fig. 11, GEN _ memnfo and FTAction _ MemLeak in DMO _ USpace _ ProcFS call the Start method, and then switch to Running state, that is, it automatically starts system level MemLeak diagnostic behavior.

GEN _ meminfo takes the meminfo file in the PROC file system mount directory as the information source, and periodically (e.g., 60 seconds) reads the information in it (e.g., "MemTotal" and "MemFree") that can be used by FTAction _ MemLeak to diagnose system-level memory leaks.

Other DMOs and DMPs in the iADS system, and any GEN or ACTION related to MemLeak, which have or have not called the Start method, will not switch to Running status, and need to show that send RUN command, and part of the state _ MemLeak also needs to send LOAD command first and then RUN command.

The tool iaads _ Utility sends a "DiagMemLeak" diagnostic action to DMP _ USpace, and manually initiates a MemLeak diagnostic action for all domains governed by this DMP.

1) DMP _ USspace first sends RUN command to GEN _ PID _ status of DMO _ USspace _ ProcFS and STATION _ MemLeak of DMP _ USspace _ ProcFS, and STATION _ MemLeak looks for which PID may be MemLeak according to the recorded information of GEN _ meminfo and GEN _ PID _ status.

If DMP _ USpace _ ProcFS:: STATION _ MemLeak can preliminarily determine which PID is in MemLeak, then it sends a Report to DMP _ USpace:: STATION _ MemLeak, reporting that the PID is a suspected process of MemLeak.

The generation domain of the diagnosis system requires complete data acquisition and simple processing. The requirement processing is simple, the generation domain can not be cascaded with the upstream, the generation domain can only be used as the terminal point on the cascade line, and only data is generated for preliminary diagnosis and then is pushed to the downstream. If cascade connection of a plurality of diagnosis nodes is needed, complex diagnosis is needed, and the processing domain designed by the application is needed to realize the complex diagnosis.

The processing domain may be cascaded with an upstream generation domain or another processing domain and may interface 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 issuing commands are realized.

With specific reference to fig. 12 and fig. 13, fig. 12 is a schematic flowchart of an embodiment of a software diagnostic system loading method provided by the present application, and fig. 13 is a schematic structural diagram of another embodiment of a processing domain provided by the present application. The software diagnosis system loading method of the embodiment of the disclosure is applied to the processing domain in the system software diagnosis system of the embodiment.

As shown in fig. 13, the processing domain of the embodiment of the present disclosure is a place for secondary diagnosis or forwarding of an event or a recorded information set, and the processing domain may perform complex processing actions. The upstream of the processing domain can be connected with the generation domain and the processing domain, so as to realize the cascade connection of the processing domains. Specifically, the processing domain includes a set forwarder, a two-wire diagnostics algorithm module, and a processing services module.

The set-repeater (ICR) is responsible for receiving information or records issued upstream, and can call a two-line diagnotor to process or generate a diagnostic report and issue the diagnostic report to downstream; information from upstream may also be forwarded or recorded to 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 executed.

The Second-line Diagnostician (STD) defaults to Log (Log) capability and calls the Second-line Diagnostician module, and the Second-line Diagnostician provides a registration mechanism to support the dynamic registration of the Second-line Diagnostician module. The two-wire diagnotor also has the ability to generate a "Report," where a Report refers to a diagnostic Report for a certain period of time, for certain selected events, or for recorded information for the processing domain.

A two-wire diagnostic Algorithm module (STA) is capable of performing complex diagnostic processes. The two-wire diagnostic algorithm module can be specified during static compiling and can also be registered during dynamic running, namely the two-wire diagnostic algorithm module realizes an iADS _ STA _ Execummand, iADS _ STA _ ProcessInfoSet, iADS _ STA _ Start, iADS _ STA _ Stop and iADS _ STA _ DoorplatTenfoGet interface and compiles the interface into so files, and when the system runs, the two-wire diagnostic device responds to commands issued downstream when needed, dynamically loads the commands, and the interface realizes the starting and running of the dynamic two-wire diagnostic algorithm module after the address is read.

The processing domains are connected with each other externally by adopting a processing service module, wherein the upstream of the processing service module is Publisher, SrvPub for short, and the downstream of the processing service module is Subscriber, SrvSub for short.

In the embedded device, for some environments with a relatively tight memory, if the processing domain is started, all static two-wire diagnostic algorithm modules are loaded, which may cause a process starting failure and a function abnormality. In order to solve the problem, a scheme for dynamically loading a two-wire diagnostic algorithm module is designed. Based on the structure of the processing domain and the logic system diagram of fig. 14, the software diagnosis system loading method provided by the embodiment of the present disclosure specifically includes the following steps:

step S31: and acquiring a command for loading the dynamic two-wire diagnostic algorithm module, which is received by the processing service module, wherein the command comprises doorplate information and address information of the dynamic two-wire diagnostic algorithm module.

As shown in fig. 14, the downstream SvrSub issues a command for specifying the processing domain to load the dynamic link two-wire diagnostic algorithm model to the SrvPub of the corresponding processing domain node, where the command carries the doorplate information and the address information of the dynamic two-wire diagnostic algorithm module.

Specifically, as the processing domains can realize cascade connection, a set transponder, a two-line diagnotor, a two-line diagnostic algorithm module, a SrvPub module and a SrvSub module are divided in one processing domain. The control command is issued and finally needs to be executed by a specific module, and the command message needs to carry doorplate information, so that the set repeater finds the specific module to process. The doorplate comprises the following three types of information: functional domain information, entity information, and process thread information.

The function domain information mainly indicates whether the domain is a generation domain or a processing domain, or a specific implementation category in the generation domain or the processing domain. In use, reference may be made to the following coding: the memory occurrence field code is 1, the CPU occurrence field code is 2, and the thread occurrence field code is 3. The memory processing domain code is 0x81, the CPU processing domain code is 0x82, and the thread processing domain code is 0x 83.

Entity information, which mainly distinguishes different modules in the same domain. In use, reference may be made to the following coding: ICR is coded as 1, STD is coded as 2, SrvPub is coded as 3.

The process thread information, the same functional domain, may be deployed in different processes a and B, and a certain command may only need to be processed by the process a, and the process ID of the process a is filled in through the process thread information. It can be guaranteed that the a process is executing instead of the B process.

Step S32: the connection established with the origin domain or other processing domain is checked by the start-up thread of the processing service module for the presence of received data.

The SrvPub-initiated thread cycle under the corresponding processing domain node checks whether there is data coming from the established connection, and if so, the process goes to step S33.

Step S33: the received data is copied by the processing thread through the messaging mechanism.

Step S34: the call set forwarder checks if there is a message to copy the data.

Wherein, the receiving thread cycle of the set repeater calls OpRecvCmd _ F (received data method) of the set repeater to check whether a message for copying data exists, if yes, the OpRecvCmd _ F is called to take OpExecCmd _ F (execution command method) as an entry parameter, and the OpExecCmd _ F is called to process data after the data is copied.

The OpExeccmd _ F is sent to the two-line diagnotor through the doorplate check, and the Execcmd _ F processing of the two-line diagnotor is called, and the processing steps are as follows:

(1) and loading a so file of a two-line diagnostic algorithm module carried by the command carrying the path information by the dlopen function.

(2) And calling the dlsym interface to acquire and save the Start method represented by the iADS _ STA _ Start.

(3) And calling the dlsym interface to acquire a Stop method represented by the iADS _ STA _ Stop and store the Stop method.

(4) The dlsym interface is called to acquire and save an executcmd _ F method for executing a downstream command, which is indicated by iasd _ STA _ executcommand.

(5) And calling the dlsym interface to acquire and store a ProcessInfoSet method for processing the upstream push information indicated by the iADS _ STA _ ProcessInfoSet.

(6) And calling the dlsym interface to acquire the address of the iADS _ STA _ DoorplatInfoGet interface and calling so as to store the doorplate information of the dynamic two-line diagnostic algorithm module, and when a command issued downstream is processed subsequently, the addressing can be successful.

(7) After the starting method is called to start the two-line diagnostic algorithm module, the dynamic two-line diagnostic algorithm module can be normally used. The upstream information calls ProcessInfoSet method processing, and the downstream command calls Execcmd _ F method processing.

Step S35: and calling a dynamic two-line diagnosis algorithm module corresponding to the address information loaded by the two-line diagnosis device based on the doorplate information so as to perform secondary diagnosis on the data.

Before loading the dynamic two-wire diagnostic algorithm module, the processing domain needs to be started, and for the specific logic of starting the processing domain, refer to fig. 15, where fig. 15 is a logic system diagram of the processing domain start provided in the present application.

As shown in fig. 15, each processing domain has a unique start method, there is only one aggregation forwarder in the processing domain, and the start method of the aggregation forwarder is called to complete the start of the whole processing domain.

Specifically, there may be multiple SvrSub objects in each set forwarder, responsible for communicating with upstream generation domains or cascaded processing domains. When starting, traversing the control block of each SvrSub object, taking the control block as an entry parameter, calling the starting method of the SvrSub, and triggering the SvrSub object to initiate connection to the corresponding upstream SvrPub by using different protocols according to the protocol type configured by the entry parameter. And storing corresponding protocol message receiving, sending and processing methods to the control blocks of each Svrsub object according to the configured corresponding protocol type.

Each set forwarder only has one SvrPub object which is responsible for receiving and sending data after receiving a downstream connection request. When starting, calling the starting method of the SvrPub, starting a thread, monitoring a connection event, and notifying a processing thread through a message mechanism (such as semaphore synchronization) if data is received after connection is established.

Each set transponder only has one two-line diagnotor, and the starting interface of the two-line diagnotor is started and called to realize the starting of the diagnosis logic.

Each set of repeaters may have a plurality of two-wire diagnostic algorithm modules therein, and the startup method of the statically linked two-wire diagnostic algorithm modules is called one by one to start. The two-wire diagnostic algorithm module is activated in response to a command trigger at run time.

The set forwarder operates requiring an independent thread context. When the processing domain is started, the control block information of the processing domain is used as the starting method of the input reference calling set forwarder to be started. The set forwarder stores the control block information of the different processing domains into a list, then starts a processing thread, periodically traverses the linked list nodes, acquires the control block information of each processing domain, and calls a processing method of the control block to process data.

Finally, the processing domain is successfully started after the starting method of the set forwarder is called.

It will be understood by those skilled in the art that in the method of the present invention, the order of writing the steps does not imply a strict order of execution and any limitations on the implementation, and the specific order of execution of the steps should be determined by their function and possible inherent logic.

In order to implement the control method of the system software diagnostic system according to the foregoing embodiment, including a software diagnostic system starting method and a software diagnostic system loading method, the present application provides a terminal device, and specifically refer to fig. 16, where fig. 16 is a schematic structural diagram of an embodiment of the terminal device provided in the present application.

As shown in fig. 16, the terminal device 500 of the present embodiment includes a processor 51, a memory 52, an input-output device 53, and a bus 54.

The processor 51, the memory 52, and the input/output device 53 are respectively connected to the bus 54, the memory 52 stores a computer program, and the processor 51 is configured to execute the computer program to implement the software diagnostic system starting method and/or the software diagnostic system loading method according to the above embodiments.

In the present embodiment, the processor 51 may also be referred to as a CPU (Central Processing Unit). The processor 51 may be an integrated circuit chip having signal processing capabilities. The processor 51 may also be a general purpose processor, a Digital Signal Processor (DSP), an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components. The processor 51 may also be a GPU (Graphics Processing Unit), which is also called a display core, a visual processor, and a display chip, and is a microprocessor specially used for image operation on a personal computer, a workstation, a game machine, and some mobile devices (such as a tablet computer, a smart phone, etc.). The purpose of the GPU is to convert and drive display information required by a computer system, provide a line scanning signal to a display, control the correct display of the display, and be an important element for connecting the display and a personal computer motherboard, and also be one of important devices for "man-machine conversation". The display card is an important component in the computer host, takes on the task of outputting display graphics, and is very important for people engaged in professional graphic design. A general purpose processor may be a microprocessor or the processor 51 may be any conventional processor or the like.

The present application also provides a computer-readable storage medium, as shown in fig. 17, the computer-readable storage medium 600 is used for storing a computer program 61, and when being executed by a processor, the computer program 61 is used for implementing the method as described in the embodiments of the software diagnostic system startup method and/or the software diagnostic system loading method of the present application.

The methods involved in the embodiments of the software diagnostic system starting method and/or the software diagnostic system loading method of the present application, when implemented, exist in the form of software functional units and are sold or used as independent products, and may be stored in a device, such as a computer readable storage medium. Based on such understanding, the technical solutions of the present application, which are essential or contributing to the prior art, or all or part of the technical solutions may be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for causing a computer device (which may be a personal computer, a server, a network device, or the like) or a processor (processor) to execute all or part of the steps of the methods according to the embodiments of the present invention. And the aforementioned storage medium includes: a U-disk, a removable hard disk, a Read-Only Memory (ROM), a Random Access Memory (RAM), a magnetic disk or an optical disk, and other various media capable of storing program codes.

The above description is only an embodiment of the present invention, and not intended to limit the scope of the present invention, and all modifications of equivalent structures and equivalent processes performed by the present specification and drawings, or directly or indirectly applied to other related technical fields, are included in the scope of the present invention.

Claims

1. A software diagnosis system starting method is characterized in that the software diagnosis system starting method is applied to an occurrence domain in a system software diagnosis system, and the occurrence domain comprises an event processing source, an information block generator, a line catcher and a line diagnostor, wherein the event processing source is respectively connected with the information block generator and the line catcher, and the line catcher is connected with the line diagnostor;

the software diagnosis system starting method comprises the following steps:

2. The software diagnostic system startup method of claim 1, characterized in that the software diagnostic system startup method further comprises:

when the information timer of the information block generator expires, waking the event processing source;

generating an information block of a preset standard data type by the information block generator;

and calling the event processing source to process the information block.

3. The SOFT DIAGNOSIS SYSTEM START-UP METHOD as recited in claim 2,

the step of calling the event processing source to process the information block comprises the following steps:

calling the event processing source to cache the information block;

calling the first-line catcher and the first-line diagnoser to perform one-time diagnosis on the information block and generate a diagnosis report;

and calling the event processing source to cache the diagnosis report.

4. The software diagnostic system starting method according to claim 3, wherein the occurrence domain further comprises an occurrence service module, and the occurrence service module is connected with the event processing source;

after the step of calling the event processing source to cache the diagnosis report, the software diagnosis system starting method further includes:

and calling the occurrence service module to push the information block cached by the event processing source and the diagnosis report to a downstream processing domain.

5. The software diagnostic system startup method of claim 4,

before the step of starting the information block generator, the software diagnostic system starting method further includes:

and starting the generation service module when the cascade control information and/or the command control information are detected.

6. The software diagnostic system startup method of claim 4,

the software diagnosis system starting method further comprises the following steps:

starting a service timer in the control range of the event processing source, which is used for receiving a command from the occurrence service module, wherein the service timer and the information timer of the information block generator share a root timer of the event processing source;

when the service timer expires, invoking the occurrence service module to receive a queued command;

calling the event processing source to analyze the doorplate information in the command;

calling the event processing source, the occurrence service module, the information block generator or the front-line diagnotor corresponding to the doorplate information to execute the command;

and calling the occurrence service module to return the execution result of the command to the sender of the command.

7. A system software diagnostic system, the system software diagnostic system comprising:

at least one occurrence field for recording events triggered by the software activities and performing a diagnosis on the events;

the generation domain includes:

8. The system software diagnostic system of claim 7, further comprising:

an information database;

and the processing domain is connected with the occurrence domain and the information database and is used for carrying out secondary diagnosis on the event of the occurrence domain and storing the event and a secondary diagnosis result in the information database.

9. A terminal device, characterized in that the terminal device comprises a processor and a memory; the memory stores a computer program, and the processor is used for executing the computer program to realize the steps of the software diagnosis system starting method according to any one of claims 1-6.

10. A computer-readable storage medium, characterized in that the computer-readable storage medium stores a computer program which, when executed, implements the steps of the software diagnostic system startup method according to any one of claims 1 to 6.