CN109446034B - Method and device for reporting crash event, computer equipment and storage medium - Google Patents
Method and device for reporting crash event, computer equipment and storage medium Download PDFInfo
- Publication number
- CN109446034B CN109446034B CN201811185447.5A CN201811185447A CN109446034B CN 109446034 B CN109446034 B CN 109446034B CN 201811185447 A CN201811185447 A CN 201811185447A CN 109446034 B CN109446034 B CN 109446034B
- Authority
- CN
- China
- Prior art keywords
- exit
- main process
- event
- event object
- instruction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Active
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/30—Monitoring
- G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
- G06F11/324—Display of status information
- G06F11/327—Alarm or error message display
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
- Retry When Errors Occur (AREA)
Abstract
The invention discloses a method and a device for reporting a crash event, computer equipment and a storage medium, and belongs to the technical field of computers. The method comprises the following steps: when the auxiliary process is started, initiating a call request of the global mutex created and occupied by the main process; when the global mutex released by the main process is called, determining an exit state type of the main process, wherein the exit state type is abnormal exit or normal exit; and when the exit state type is abnormal exit, reporting a crash event of the main process. By adopting the invention, the instantaneity and comprehensiveness of reporting the crash event can be improved.
Description
Technical Field
The present invention relates to the field of computer technologies, and in particular, to a method and an apparatus for reporting a crash event, a computer device, and a storage medium.
Background
When the computer device runs software, the crash event needs to be monitored so as to report the crash event to the computer device server and provide the crash event for a technician to analyze.
Currently, computer devices monitor crash events through an auxiliary process. If the process for running the software is called a main process, after the main process is started, the corresponding auxiliary processes are also started successively to monitor the main process, and when the main process normally exits, the auxiliary processes can be closed. The computer device records the state of each process in the process table, such as running state, sleeping state, etc. When the main process crashes, the main process exits abnormally, and normal business logic cannot be executed, namely the auxiliary process cannot be closed during exiting. Therefore, the auxiliary process can inquire whether the main process runs or not by periodically polling the process table. When the auxiliary process inquires that the main process operates, the auxiliary process is regarded as a normal condition; when the auxiliary process inquires that the main process is not running, the crash event is determined to be monitored.
In the process of implementing the invention, the inventor finds that the prior art has at least the following problems:
the crash event can be monitored only when the auxiliary process initiates a query, and if the main process crashes and the auxiliary process does not initiate a query, the crash event cannot be reported at the first time, and the instantaneity of reporting the crash event is low. And if the user restarts the software to make the main process run again, and the main process crashes to the rerun just in the gap between two adjacent queries of the auxiliary process, the crash event is missed.
Disclosure of Invention
The embodiment of the invention provides a method, a device, computer equipment and a storage medium for reporting a crash event, which can improve the instantaneity and comprehensiveness of the reported crash event. The technical scheme is as follows:
in one aspect, a method for reporting a crash event is provided, where the method is applied to an auxiliary process, and the method includes:
when the auxiliary process is started, initiating a call request of the global mutex created and occupied by the main process;
when the global mutex released by the main process is called, determining an exit state type of the main process, wherein the exit state type is abnormal exit or normal exit;
and when the exit state type is abnormal exit, reporting a crash event of the main process.
Optionally, the determining the exit state type of the host process when the global mutex released by the host process is called includes:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state, determining that the exit state type of the main process is normal exit, and if the first event object is in a triggered state, determining that the exit state type of the main process is abnormal exit.
Optionally, the method further includes:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state and the second event object is in a triggered state, acquiring attribute data corresponding to an abnormal event recorded by the main process, and reporting the attribute data when a crash event of the main process is reported.
In one aspect, a method for reporting a crash event is provided, where the method is applied to a host process, and the method includes:
when the main process is started, creating a global mutex, and keeping the occupation of the global mutex in the running process of the main process;
starting an auxiliary process;
and when the exit instruction is executed, releasing the global mutex.
Optionally, the exit instruction of the host process includes an abnormal exit instruction and a normal exit instruction, and the method further includes:
when the main process is started, a first event object is created;
when executing an exit instruction, if the exit instruction is a normal exit instruction, before the releasing the global mutex, the method further includes:
setting the first event object to a trigger state.
Optionally, the exception exit instruction includes multiple types of exception exit instructions, and the method further includes:
when the main process is started, a second event object is created;
when the abnormal event of the main process is detected, recording attribute data corresponding to the abnormal event, and executing an abnormal exit instruction of a target type, wherein the abnormal exit instruction of the target type is used for indicating that the attribute data corresponding to the abnormal event is recorded before the main process exits;
when executing an exit instruction, if the exit instruction is an abnormal exit instruction of the target type, before the releasing the global mutex, the method further includes:
and setting the second event object to be in a trigger state.
In one aspect, an apparatus for reporting a crash event is provided, where the apparatus is applied to an auxiliary process, and the apparatus includes:
the calling module is used for initiating a calling request of the global mutex created and occupied by the main process when the auxiliary process is started;
the determining module is used for determining the exit state type of the main process when the global mutex released by the main process is called, wherein the exit state type is abnormal exit or normal exit;
and the reporting module is used for reporting the crash event of the main process when the exit state type is abnormal exit.
Optionally, the invoking module is configured to:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state, determining that the exit state type of the main process is normal exit, and if the first event object is in a triggered state, determining that the exit state type of the main process is abnormal exit.
Optionally, the reporting module is further configured to:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state and the second event object is in a triggered state, acquiring attribute data corresponding to an abnormal event recorded by the main process, and reporting the attribute data when a crash event of the main process is reported.
In one aspect, an apparatus for reporting a crash event is provided, where the apparatus is applied to a host process, and the apparatus includes:
the creating module is used for creating a global mutex when the main process is started and keeping the occupation of the global mutex in the running process of the main process;
the starting module is used for starting the auxiliary process;
and the releasing module is used for releasing the global mutex when the quitting instruction is executed.
Optionally, the exit instruction of the host process includes an abnormal exit instruction and a normal exit instruction, and the creating module is further configured to: when the main process is started, a first event object is created;
when executing the quit instruction, if the quit instruction is a normal quit instruction, the release module is further configured to: setting the first event object to a trigger state.
Optionally, the exception exit instruction includes multiple types of exception exit instructions, and the creating module is further configured to: when the main process is started, a second event object is created;
the device further comprises a recording module, configured to record, when an exception event of the host process is detected, attribute data corresponding to the exception event, and execute an exception exit instruction of a target type, where the exception exit instruction of the target type is used to indicate that the attribute data corresponding to the exception event is recorded before the host process exits;
when executing an exit instruction, if the exit instruction is an abnormal exit instruction of the target type, the releasing module is further configured to: and setting the second event object to be in a trigger state.
In one aspect, a computer device is provided, where the computer device includes a processor and a memory, where the memory stores at least one instruction, and the at least one instruction is loaded and executed by the processor to implement any one of the above methods for reporting a crash event.
In one aspect, a computer-readable storage medium is provided, where at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement any one of the above methods for reporting a crash event.
The technical scheme provided by the embodiment of the invention has the following beneficial effects:
in the embodiment of the invention, the main process and the auxiliary process establish contact through a system kernel, the effect of notification is achieved by utilizing the global mutex, and once the main process releases the global mutex, the auxiliary process can know that the main process exits and determine whether the main process exits abnormally. Because the global mutex is a kernel object and cannot be influenced by process crash, the auxiliary process can determine the business logic of the exit state type of the main process at the first time by calling the global mutex, and the instantaneity of acquiring and reporting crash events is improved.
And no matter the main process is normally exited or abnormally exited, the auxiliary process can acquire the global mutex to determine the exit state type of the main process, so that the condition of missing crash events can be avoided, and the comprehensiveness of reporting the crash events 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 will be 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 diagram of an implementation environment provided by an embodiment of the invention;
fig. 2 is a flowchart of a method for reporting a crash event according to an embodiment of the present invention;
FIG. 3 is a diagram illustrating a relationship between a primary process and a secondary process according to an embodiment of the present invention;
fig. 4 is a flowchart of a method for reporting a crash event according to an embodiment of the present invention;
fig. 5 is a flowchart of a method for reporting a crash event according to an embodiment of the present invention;
fig. 6 is a schematic diagram of an apparatus for reporting a crash event according to an embodiment of the present invention;
fig. 7 is a schematic diagram of an apparatus for reporting a crash event according to an embodiment of the present invention;
fig. 8 is a schematic structural diagram of a computer device according to an embodiment of the present invention.
Detailed Description
In order to make the objects, technical solutions and advantages of the present invention more apparent, embodiments of the present invention will be described in detail with reference to the accompanying drawings.
The embodiment of the invention provides a method for reporting a crash event, which can be realized by computer equipment.
Fig. 1 is a diagram of an implementation environment provided by an embodiment of the invention. The implementation environment may include a plurality of computer devices 101, a server 102 for providing services to the plurality of computer devices 101, the server 102 may be a single server or a group of servers. A plurality of computer devices 101 are connected to a server 102 through a wireless or wired network. Various software can be installed in the computer device 101, and the server 102 can provide background services for the software.
When the software is started, a process may be started in the computer device 101 to perform each function in the software, and the process is referred to as a main process in the embodiment of the present invention. In the embodiment of the invention, another process is introduced to monitor whether the main process is abnormally exited or not, and the process is called an auxiliary process. When the secondary process monitors that the primary process is abnormally exited, a corresponding crash event may be reported to the server 102.
The method will be described with reference to the flowchart of the method for reporting a crash event shown in fig. 2, where the processing flow of the method may include the following steps:
in step 201, when the host process starts, a global mutex, a first event object, and a second event object are created, and the global mutex is kept occupied during the running of the host process.
The global MUTEX, the first event and the second event may be kernel objects, which allow cross-process use, for example, the global MUTEX may be a MUTEX object, and the name may be a masterMutex; the first EVENT object and the second EVENT object may be EVENT objects, the name of the first EVENT object may be a closeEvent, and the name of the second EVENT object may be a creatent.
The global mutex is allowed to be used by only one process at a time. The first event object may be used to indicate that the host process normally exits, and may be triggered when the host process executes a normal exit instruction. The second event object may be used to indicate that the host process is to abort, and may be triggered when the host process executes an abort instruction.
When the software is started in the computer equipment, the corresponding main process can be started. In addition to the functions that the software needs to perform, the host process may create a global mutex, a first event object, and a second event object. The first event object and the second event object are set to be in an triggerless state by default when the creation is completed.
And in the running process of the main process, the global mutex is kept not to be released, namely the global mutex keeps an occupied state in the running process of the main process.
In step 202, the primary process starts the secondary process.
After the host process creates the global mutex, the first event object, and the second event object, the host process may start a secondary process. And after the creation, the auxiliary process is started, so that the auxiliary process can normally call the global mutex, the first event object and the second event object.
In step 203, when the auxiliary process is started, a call request for a global mutex created and occupied by the main process is initiated, and the first event object and the second event object are monitored.
When the auxiliary process is started, an asynchronous task can be created, and the global mutex is called in the asynchronous task, that is, a call request for the global mutex is initiated to the system kernel. Because the main process always occupies the global mutex in the operation process, and the auxiliary process cannot use the global mutex, the auxiliary process can be in a blocking state when the main process occupies the global mutex, and waits for the main process to release the global mutex.
The auxiliary process can also monitor the first event object and the second event object, and wait for the trigger signals of the first event and the second event so as to carry out different business logics.
In step 204, when the host process executes the normal exit instruction, the first event object is set to the trigger state, and the global mutex is released.
The exit instructions that the host process may execute include an exception exit instruction and a normal exit instruction. For example, a normal exit instruction may be to call an exit function; the abort instruction may be a call about function. Correspondingly, the exit state type of the main process may include an abnormal exit and a normal exit.
When the main process normally exits, the business logic of the normal exit instruction can be executed. The first event object can be set to be in a trigger state, namely, the first event object is triggered, then the global mutex is released, the auxiliary process is prevented from acquiring the trigger signal of the first event object after the subsequent service logic is executed, and the service logic of the auxiliary process can be normally executed.
In step 205, when the global mutex released by the main process is called, if the first event object is in the trigger state, the auxiliary process determines that the exit state type of the main process is normal exit.
When the main process normally exits, the auxiliary process may first acquire a trigger signal of the first event object, and then acquire the global mutex released by the main process. When the global mutex is acquired, the secondary process may transition from the blocking state to the executing state. Then, the auxiliary process may determine that the exit status type of the main process is normal exit according to the trigger signal of the first event object.
Optionally, after determining that the exit state type of the main process is normal exit, the auxiliary process may execute processing of an exit instruction, that is, close the auxiliary process, so as to avoid an influence on restarting the main process.
The above describes the case of normal exit of the host process, and the following describes the case of abnormal exit. In the embodiment of the present invention, the abnormal exit may be divided into two cases, the first case is as described in step 206 and step 208 below, and the host process may trigger the second event object; in the second case, as described in steps 209-210 below, the host process cannot trigger the second event object.
The following describes the first abnormal exit:
in step 206, when the exception event of the host process is detected, the host process records the attribute data corresponding to the exception event, and executes the exception exit instruction of the target type.
The attribute data may be used to analyze the exception event, for example, the attribute data may be a software identifier, a generation time, an instruction, and the like for generating an exception.
The abort instruction may include multiple types of abort instructions, i.e., the host process may execute different abort instructions upon generating different exceptions. The target type exception exit instruction may be used to indicate that the attribute data corresponding to the exception event is recorded before the host process exits, that is, in the embodiment of the present invention, the exception exit instruction executed after the attribute data corresponding to the exception event is recorded is referred to as the target type exception exit instruction.
The host process may have the function of detecting an exception. In the process of running the main process, if an abnormal event is generated and the main process detects an abnormality through the above functions, the corresponding attribute data can be acquired and can be stored in the computer device. Alternatively, the process of acquiring the target data may be performed by one thread. For example, the host process may obtain the attribute data of the host process crash by registering the crash callback function SetUnhandledExceptionFilter.
In step 207, when the host process executes the target type exception instruction, the second event object is set to the trigger state, and the global mutex is released.
The host process may obtain the attribute data, indicating that the exception does not affect the part of the service logic, for example, the thread that realizes obtaining the target data is not affected. After obtaining the attribute data, the host process may execute an exception exit instruction of the target type, first set the second event object to a trigger state, that is, trigger the second event object, and then release the global mutex. Like step 204, the processing of step 207 can ensure that the business logic of the auxiliary process can be executed normally.
In step 208, upon invoking the global mutex released by the main process, if the first event object is in the non-triggered state and the second event object is in the triggered state, the secondary process determines that the exit state type of the main process is a first exception exit.
The first exception exit may be used to indicate that the host process exits abnormally and obtain attribute data of the exception event.
The auxiliary process may first acquire the trigger signal of the second event object, and then acquire the global mutex released by the main process. When the global mutex is acquired, the secondary process may transition from the blocking state to the executing state. Then, the auxiliary process may determine that the exit state type of the main process is the first abnormal exit according to the trigger signal of the second event object.
The second abnormal exit case is described below:
in step 209, when the host process executes an abort instruction other than the target type, the global mutex is released.
When the main process is abnormal, if the influence of the abnormality is wide, the main process may not perform the service logic for detecting the abnormal event, and further, the second event object may not be triggered. The embodiment of the present invention does not limit the specific situation that the second event object cannot be triggered.
Furthermore, when the main process executes an abnormal exit instruction except the target type, the second event object is not triggered, and the global mutex is released.
In step 210, when the global mutex released by the main process is called, if both the first event object and the second event object are in the non-triggered state, the auxiliary process determines that the exit state type of the main process is a second abnormal exit.
The second exception exit may be used to indicate that the host process exits abnormally and does not obtain the attribute data of the exception event.
At this time, when the auxiliary process acquires the global mutex released by the main process, the trigger signal of the first event object or the second event object is not acquired. Further, the secondary process may determine that the exit status type of the primary process is a second exception exit.
In step 211, when the exit status type of the main process is abnormal exit, the auxiliary process reports a crash event of the main process.
The states of the first and second exception exits described above may each be referred to as an exception exit state. When the auxiliary process determines that the exit state of the main process is abnormal exit, a corresponding crash event can be generated and reported to the server. Optionally, after the auxiliary process reports the crash event of the main process, the auxiliary process may execute processing of the exit instruction, that is, close the auxiliary process.
Optionally, when the global mutex released by the host process is called, if the first event object is in an un-triggered state and the second event object is in a triggered state, the attribute data corresponding to the abnormal event recorded by the host process is acquired, and when the crash event of the host process is reported, the attribute data is reported.
And after acquiring the attribute data, the main process stores the attribute data in a preset identifier or a preset storage address so that the auxiliary process can acquire the attribute data according to the preset identifier or the preset storage address. The embodiment of the invention does not limit the specific processing of the auxiliary process for acquiring the attribute data.
That is, when the exit state type of the main process is the first abnormal exit, the auxiliary process reports the crash event and reports the attribute data corresponding to the abnormal event.
Thus, the server may receive crash events that collected attribute data and crash events that did not collect attribute data. Technicians can analyze the crash events according to the attribute data and obtain the reasons of the crash events so as to correspondingly update the software. Of course, the technician may also gauge the operational status of the software based on the total number of crash events, and so forth. In the embodiment of the present invention, how to use the reported crash event is not limited.
As shown in fig. 3, in the embodiment of the present invention, the main process and the auxiliary process establish a relationship through a system kernel, and achieve an effect of notification by using the global mutex, and once the main process releases the global mutex, the auxiliary process can know that the main process exits and determine whether the main process exits abnormally. Because the global mutex is a kernel object and cannot be influenced by process crash, the auxiliary process can determine the business logic of the exit state type of the main process at the first time by calling the global mutex, and the instantaneity of acquiring and reporting crash events is improved.
And no matter the main process is normally exited or abnormally exited, the auxiliary process can acquire the global mutex to determine the exit state type of the main process, so that the condition of missing crash events can be avoided, and the comprehensiveness of reporting the crash events is improved.
In the embodiment of the invention, whether the crash event exits abnormally is distinguished by using the first event object, and whether the attribute data of the abnormal event is acquired is also distinguished by using the second event object, so that the accuracy of dividing the crash event is improved, and the analysis efficiency can be improved when a technician analyzes the crash event.
The method for reporting the crash event by using the global mutex, the first event object and the second event object is introduced in the embodiments of the present invention, however, the technical scheme related to the second event object is an optional scheme, and the process of reporting the crash event can also be implemented by using the global mutex and the first event object. The method will be described with reference to the flowchart of the method for reporting a crash event shown in fig. 4:
in step 401, when the host process starts, a global mutex and a first event object are created, and the global mutex is kept occupied during the running process of the host process.
In step 402, the primary process starts a secondary process.
In step 403, when the auxiliary process is started, a call request for the global mutex created and occupied by the main process is initiated, and the first event object is monitored.
The specific processing in step 401-.
In step 404, when the host process executes the normal exit instruction, the first event object is set to a trigger state, and the global mutex is released.
In step 405, when the global mutex released by the main process is called, if the first event object is in a trigger state, the auxiliary process determines that the exit state type of the main process is normal exit.
The determination process for normal exit of the host process may be the same as the above step 204 and 205, and is not described herein again.
In step 406, when the host process executes the abort instruction, the global mutex is released.
Since the first event object can be used to indicate that the host process normally exits, when the host process exits abnormally, the first event object is not triggered, and the global mutex is released.
In step 407, when the global mutex released by the main process is called, if the first event object is in an un-triggered state, the auxiliary process determines that the exit state type of the main process is abnormal exit.
When the main process exits abnormally, the auxiliary process does not acquire the trigger signal of the first event object when acquiring the global mutex, and then the exit state type of the main process can be determined to be abnormal exit.
In step 408, when the exit status type of the main process is abnormal exit, the auxiliary process reports a crash event of the main process.
In the embodiment of the invention, the main process and the auxiliary process establish contact through a system kernel, the effect of notification is achieved by utilizing the global mutex, and once the main process releases the global mutex, the auxiliary process can know that the main process exits and determine whether the main process exits abnormally. Because the global mutex is a kernel object and cannot be influenced by process crash, the auxiliary process can determine the business logic of the exit state type of the main process at the first time by calling the global mutex, and the instantaneity of acquiring and reporting crash events is improved.
And no matter the main process is normally exited or abnormally exited, the auxiliary process can acquire the global mutex to determine the exit state type of the main process, so that the condition of missing crash events can be avoided, and the comprehensiveness of reporting the crash events is improved.
In the embodiment of the invention, whether the host process exits abnormally is distinguished by utilizing the first event object, and when the first event object is triggered, the host process can be determined to exit normally; when the first event object is not triggered, the abnormal exit of the main process can be determined, and the efficiency of acquiring and reporting the crash event can be improved.
In the above embodiment of the present invention, whether to exit abnormally is distinguished by using the first event object, and certainly, whether to exit abnormally may be determined based on other methods, for example, as shown in a flowchart of a method for reporting a crash event in fig. 5, a processing flow of the method may include the following steps:
in step 501, when the host process starts, a global mutex is created, and the host process keeps occupying the global mutex during running.
In step 502, the primary process starts the secondary process.
In step 503, when the auxiliary process is started, a call request for the global mutex created and occupied by the main process is initiated.
In step 504, the global mutex is released when the host process executes an exit instruction.
In step 505, the secondary process determines the exit state type of the primary process when a global mutex released by the primary process is invoked.
In addition to the method described in the foregoing embodiment of the present invention, the exit state type of the main process may be determined based on other methods, for example, if the auxiliary process is closed when the normal service processing logic of the main process is normal exit, and the auxiliary process obtains the global mutex released by the main process, which indicates that the main process has exited but the auxiliary process is not closed, the auxiliary process may determine that the exit state type of the main process is abnormal exit. The embodiment of the present invention does not limit the specific process of determining the exit state type of the host process.
In step 506, when the exit status type of the primary process is abnormal exit, the secondary process reports a crash event of the primary process.
The specific processing of steps 501-506 may be the same as that of the above embodiments of the invention, and will not be described herein again.
In the embodiment of the invention, the main process and the auxiliary process establish contact through a system kernel, the effect of notification is achieved by utilizing the global mutex, and once the main process releases the global mutex, the auxiliary process can know that the main process exits and determine whether the main process exits abnormally. Because the global mutex is a kernel object and cannot be influenced by process crash, the auxiliary process can determine the business logic of the exit state type of the main process at the first time by calling the global mutex, and the instantaneity of acquiring and reporting crash events is improved.
And no matter the main process is normally exited or abnormally exited, the auxiliary process can acquire the global mutex to determine the exit state type of the main process, so that the condition of missing crash events can be avoided, and the comprehensiveness of reporting the crash events is improved.
Based on the same technical concept, an embodiment of the present invention further provides a device for reporting a crash event, where the device may be configured in the computer device, and is configured to implement the auxiliary process. As shown in fig. 6, the apparatus includes:
a calling module 610, configured to initiate a call request for a global mutex created and occupied by a main process when the auxiliary process is started;
a determining module 620, configured to determine an exit state type of the host process when the global mutex released by the host process is called, where the exit state type is abnormal exit or normal exit;
a reporting module 630, configured to report a crash event of the host process when the exit status type is abnormal exit.
Optionally, the invoking module 610 is further configured to:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state, determining that the exit state type of the main process is normal exit, and if the first event object is in a triggered state, determining that the exit state type of the main process is abnormal exit.
Optionally, the reporting module 630 is further configured to:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state and the second event object is in a triggered state, acquiring attribute data corresponding to an abnormal event recorded by the main process, and reporting the attribute data when a crash event of the main process is reported.
Based on the same technical concept, an embodiment of the present invention further provides a device for reporting a crash event, where the device may be configured in the computer device, and is configured to implement the main process. As shown in fig. 7, the apparatus includes:
a creating module 710, configured to create a global mutex when the main process is started, and keep the global mutex occupied during the running process of the main process;
a starting module 720, configured to start an auxiliary process;
a releasing module 730, configured to release the global mutex when the exit instruction is executed.
Optionally, the exit instruction of the main process includes an abnormal exit instruction and a normal exit instruction, and the creating module 710 is further configured to: when the main process is started, a first event object is created;
when executing the exit instruction, if the exit instruction is a normal exit instruction, the releasing module 730 is further configured to: setting the first event object to a trigger state.
Optionally, the exception exit instruction includes multiple types of exception exit instructions, and the creating module 710 is further configured to: when the main process is started, a second event object is created;
the apparatus further includes a recording module 740, configured to, when an exception event of the host process is detected, record attribute data corresponding to the exception event, and execute an exception exit instruction of a target type, where the exception exit instruction of the target type is used to indicate that the attribute data corresponding to the exception event is recorded before the host process exits;
when executing the exit instruction, if the exit instruction is an abnormal exit instruction of the target type, the releasing module 730 is further configured to: and setting the second event object to be in a trigger state.
With regard to the apparatus in the above-described embodiment, the specific manner in which each module performs the operation has been described in detail in the embodiment related to the method, and will not be elaborated here.
In the embodiment of the invention, the main process and the auxiliary process establish contact through the system kernel, the effect of notification is achieved by using the global mutex, and once the main process releases the global mutex, the auxiliary process can know that the main process exits and determine whether the main process exits abnormally. Because the global mutex is a kernel object and cannot be influenced by process crash, the auxiliary process can determine the business logic of the exit state type of the main process at the first time by calling the global mutex, and the instantaneity of acquiring and reporting crash events is improved.
And no matter the main process is normally exited or abnormally exited, the auxiliary process can acquire the global mutex to determine the exit state type of the main process, so that the condition of missing crash events can be avoided, and the comprehensiveness of reporting the crash events is improved.
It should be noted that: in the device for reporting a crash event provided in the foregoing embodiment, only the division of the functional modules is used for illustration when reporting a crash event, and in practical applications, the function distribution may be completed by different functional modules as needed, that is, the internal structure of the computer device is divided into different functional modules to complete all or part of the functions described above. In addition, the apparatus for reporting a crash event and the method for reporting a crash event provided in the foregoing embodiments belong to the same concept, and specific implementation processes thereof are detailed in the method embodiments and will not be described herein again.
Fig. 8 is a schematic structural diagram of a computer device 800 according to an embodiment of the present invention, where the computer device 800 may generate a relatively large difference due to different configurations or performances, and may include one or more processors (CPUs) 801 and one or more memories 802, where the memory 802 stores at least one instruction, and the at least one instruction is loaded and executed by the processor 801 to implement the method steps of reporting the crash event of the secondary process or the primary process.
In an exemplary embodiment, a computer-readable storage medium, such as a memory including instructions executable by a processor in a computer device, to perform a method of reporting a crash event for an auxiliary process or a primary process is also provided. For example, the computer readable storage medium may be a ROM, a Random Access Memory (RAM), a CD-ROM, a magnetic tape, a floppy disk, an optical data storage device, and the like.
It will be understood by those skilled in the art that all or part of the steps of implementing the above embodiments may be implemented by hardware, or may be implemented by a program instructing relevant hardware, where the program may be stored in the above computer-readable storage medium, and the above storage medium may be a read-only memory, a magnetic disk, an optical disk, or the like.
The above description is only for the purpose of illustrating the preferred embodiments of the present invention and is not to be construed as limiting the invention, and any modifications, equivalents, improvements and the like that fall within the spirit and principle of the present invention are intended to be included therein.
Claims (14)
1. A method for reporting crash events, the method being applied to an auxiliary process, the method comprising:
when the auxiliary process is started, initiating a call request of the global mutex created and occupied by the main process;
when the global mutex released by the main process is called, determining an exit state type of the main process, wherein the exit state type is abnormal exit or normal exit;
when the exit state type is abnormal exit, reporting a crash event of the main process;
when a main process is started, the global mutex, a first event object and a second event object are created, wherein the global mutex, the first event object and the second event object are kernel objects which are allowed to be used across processes, the first event object is used for indicating the main process to normally exit, and the second event object is used for indicating the main process to abnormally exit.
2. The method of claim 1, wherein determining the exit state type of the host process when invoking the global mutex released by the host process comprises:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state, determining that the exit state type of the main process is normal exit, and if the first event object is in a triggered state, determining that the exit state type of the main process is abnormal exit.
3. The method of claim 2, further comprising:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state and the second event object is in a triggered state, acquiring attribute data corresponding to an abnormal event recorded by the main process, and reporting the attribute data when a crash event of the main process is reported.
4. A method for reporting crash events, the method being applied to a host process, the method comprising:
when the main process is started, creating a global mutex, a first event object and a second event object, and keeping the occupation of the global mutex in the running process of the main process, wherein the global mutex, the first event object and the second event object are kernel objects which are allowed to be used across processes, the first event object is used for indicating the normal exit of the main process, and the second event object is used for indicating the abnormal exit of the main process;
starting an auxiliary process;
and when the exit instruction is executed, releasing the global mutex.
5. The method of claim 4, wherein the exit instructions of the host process include an exception exit instruction and a normal exit instruction, the method further comprising:
when executing an exit instruction, if the exit instruction is a normal exit instruction, before the releasing the global mutex, the method further includes:
setting the first event object to a trigger state.
6. The method of claim 5, wherein the exception exit instruction comprises multiple types of exception exit instructions, the method further comprising:
when the abnormal event of the main process is detected, recording attribute data corresponding to the abnormal event, and executing an abnormal exit instruction of a target type, wherein the abnormal exit instruction of the target type is used for indicating that the attribute data corresponding to the abnormal event is recorded before the main process exits;
when executing an exit instruction, if the exit instruction is an abnormal exit instruction of the target type, before the releasing the global mutex, the method further includes:
and setting the second event object to be in a trigger state.
7. An apparatus for reporting a crash event, the apparatus being applied to an auxiliary process, the apparatus comprising:
the calling module is used for initiating a calling request of the global mutex created and occupied by the main process when the auxiliary process is started;
the determining module is used for determining the exit state type of the main process when the global mutex released by the main process is called, wherein the exit state type is abnormal exit or normal exit;
a reporting module, configured to report a crash event of the host process when the exit status type is abnormal exit;
when a main process is started, the global mutex, a first event object and a second event object are created, wherein the global mutex, the first event object and the second event object are kernel objects which are allowed to be used across processes, the first event object is used for indicating the main process to normally exit, and the second event object is used for indicating the main process to abnormally exit.
8. The apparatus of claim 7, wherein the invoking module is configured to:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state, determining that the exit state type of the main process is normal exit, and if the first event object is in a triggered state, determining that the exit state type of the main process is abnormal exit.
9. The apparatus of claim 8, wherein the reporting module is further configured to:
when the global mutex released by the main process is called, if the first event object is in an un-triggered state and the second event object is in a triggered state, acquiring attribute data corresponding to an abnormal event recorded by the main process, and reporting the attribute data when a crash event of the main process is reported.
10. An apparatus for reporting a crash event, the apparatus being applied to a host process, the apparatus comprising:
the system comprises a creating module, a judging module and a judging module, wherein the creating module is used for creating a global mutex, a first event object and a second event object when the main process is started, and keeping the occupation of the global mutex in the running process of the main process, the global mutex, the first event object and the second event object are kernel objects which are allowed to be used across processes, the first event object is used for indicating the normal exit of the main process, and the second event object is used for indicating the abnormal exit of the main process;
the starting module is used for starting the auxiliary process;
and the releasing module is used for releasing the global mutex when the quitting instruction is executed.
11. The apparatus of claim 10, wherein the exit instructions of the host process comprise an exception exit instruction and a normal exit instruction, and when executing the exit instruction, if the exit instruction is the normal exit instruction, the releasing module is further configured to: setting the first event object to a trigger state.
12. The apparatus according to claim 11, wherein the exception exit instruction includes multiple types of exception exit instructions, the apparatus further includes a recording module, configured to record attribute data corresponding to the exception event when the exception event of the host process is detected, and execute a target type of exception exit instruction, where the target type of exception exit instruction is used to indicate that the attribute data corresponding to the exception event is recorded before the host process exits;
when executing an exit instruction, if the exit instruction is an abnormal exit instruction of the target type, the releasing module is further configured to: and setting the second event object to be in a trigger state.
13. A computer device comprising a processor and a memory, wherein at least one instruction is stored in the memory, and wherein the at least one instruction is loaded and executed by the processor to implement the method for reporting a crash event of any one of claims 1 to 3 or the method for reporting a crash event of any one of claims 4 to 6.
14. A computer-readable storage medium, wherein at least one instruction is stored in the storage medium, and the at least one instruction is loaded and executed by a processor to implement the method for reporting a crash event according to any one of claims 1 to 3, or the method for reporting a crash event according to any one of claims 4 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811185447.5A CN109446034B (en) | 2018-10-11 | 2018-10-11 | Method and device for reporting crash event, computer equipment and storage medium |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN201811185447.5A CN109446034B (en) | 2018-10-11 | 2018-10-11 | Method and device for reporting crash event, computer equipment and storage medium |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| CN109446034A CN109446034A (en) | 2019-03-08 |
| CN109446034B true CN109446034B (en) | 2022-02-18 |
Family
ID=65545244
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN201811185447.5A Active CN109446034B (en) | 2018-10-11 | 2018-10-11 | Method and device for reporting crash event, computer equipment and storage medium |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN109446034B (en) |
Families Citing this family (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN112052098A (en) * | 2020-09-02 | 2020-12-08 | 北京微步在线科技有限公司 | Process protection method and device |
| CN114257573B (en) * | 2020-09-22 | 2023-09-19 | ***通信集团广东有限公司 | Method and device for detecting VOLTE voice function abnormality |
Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2288467T3 (en) * | 1999-10-26 | 2008-01-16 | Iontas Limited | SUPERVISION OF THE USE OF COMPUTERS. |
| CN102200941A (en) * | 2010-03-25 | 2011-09-28 | 杭州华三通信技术有限公司 | Method and unit for monitoring process state |
| CN106874126A (en) * | 2017-01-24 | 2017-06-20 | 厦门天锐科技股份有限公司 | Host process method for detecting abnormality in a kind of software development |
-
2018
- 2018-10-11 CN CN201811185447.5A patent/CN109446034B/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| ES2288467T3 (en) * | 1999-10-26 | 2008-01-16 | Iontas Limited | SUPERVISION OF THE USE OF COMPUTERS. |
| CN102200941A (en) * | 2010-03-25 | 2011-09-28 | 杭州华三通信技术有限公司 | Method and unit for monitoring process state |
| CN106874126A (en) * | 2017-01-24 | 2017-06-20 | 厦门天锐科技股份有限公司 | Host process method for detecting abnormality in a kind of software development |
Also Published As
| Publication number | Publication date |
|---|---|
| CN109446034A (en) | 2019-03-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN106856489B (en) | Service node switching method and device of distributed storage system | |
| CN111324423B (en) | Method and device for monitoring processes in container, storage medium and computer equipment | |
| US9104480B2 (en) | Monitoring and managing memory thresholds for application request threads | |
| WO2020024376A1 (en) | Method and device for processing operation and maintenance monitoring alarm | |
| CN108038039B (en) | Method for recording log and micro-service system | |
| CN108287769B (en) | Information processing method and device | |
| CN108508874B (en) | Method and device for monitoring equipment fault | |
| CN109446034B (en) | Method and device for reporting crash event, computer equipment and storage medium | |
| CN110266544B (en) | Device and method for positioning reason of cloud platform micro-service failure | |
| KR20200078328A (en) | Systems and methods of monitoring software application processes | |
| CN109586989B (en) | State checking method, device and cluster system | |
| WO2023083079A1 (en) | System, method and apparatus for monitoring third-party system, and device and storage medium | |
| CN111813646A (en) | Method and device for injecting application probe in docker container environment | |
| CN113220535A (en) | Method, device and equipment for processing program exception and storage medium | |
| CN112068935A (en) | Method, device and equipment for monitoring deployment of kubernets program | |
| CN109062718B (en) | Server and data processing method | |
| CN111722917A (en) | Resource scheduling method, device and equipment for performance test task | |
| CN113064765B (en) | Node exception handling method, device, electronic equipment and machine-readable storage medium | |
| CN114490237A (en) | Operation and maintenance monitoring method and device based on multiple data sources | |
| CN113791950A (en) | Information processing method and device of service program, server and storage medium | |
| CN111143127B (en) | Method, device, storage medium and equipment for supervising network equipment | |
| CN105511848B (en) | Detection method and device for dynamic link library | |
| CN111857689A (en) | Framework, function configuration method of framework, terminal and storage medium | |
| CN114253825A (en) | Memory leak detection method and device, computer equipment and storage medium | |
| CN113760485A (en) | Scheduling method, device and equipment of timing task and storage medium |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| PB01 | Publication | ||
| PB01 | Publication | ||
| SE01 | Entry into force of request for substantive examination | ||
| SE01 | Entry into force of request for substantive examination | ||
| GR01 | Patent grant | ||
| GR01 | Patent grant |