CN115934390A - Method and system for processing application program crash and device for running application program - Google Patents

Method and system for processing application program crash and device for running application program Download PDF

Info

Publication number
CN115934390A
CN115934390A CN202211409719.1A CN202211409719A CN115934390A CN 115934390 A CN115934390 A CN 115934390A CN 202211409719 A CN202211409719 A CN 202211409719A CN 115934390 A CN115934390 A CN 115934390A
Authority
CN
China
Prior art keywords
crash
application
information
configuration table
application program
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.)
Pending
Application number
CN202211409719.1A
Other languages
Chinese (zh)
Inventor
王哲
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Mercedes Benz Group AG
Original Assignee
Mercedes Benz Group AG
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Mercedes Benz Group AG filed Critical Mercedes Benz Group AG
Priority to CN202211409719.1A priority Critical patent/CN115934390A/en
Publication of CN115934390A publication Critical patent/CN115934390A/en
Priority to PCT/EP2023/025441 priority patent/WO2024099586A1/en
Pending legal-status Critical Current

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079Root cause analysis, i.e. error or fault diagnosis
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0793Remedial or corrective actions

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Stored Programmes (AREA)

Abstract

The invention relates to a method for handling application crashes, comprising: monitoring whether an application program crash occurs; if the crash is monitored, acquiring the crash information of the application program; judging whether the crash information of the application program exists in a configuration table of an application program crash processing strategy or not, wherein the configuration table comprises a mapping relation between the stored crash information of the application program and the crash processing strategy; and if the crash information of the application program exists, performing crash processing based on a crash processing strategy corresponding to the crash information of the application program in the configuration table. The invention also relates to a device for running an application, a system for handling application crashes and a computer program product. According to the invention, the crash processing strategy can be automatically matched and executed according to the crash information of the application program without the participation of a user, thereby improving the efficiency of crash processing of the application program and the running stability of the application program.

Description

Method and system for processing application program crash and device for running application program
Technical Field
The present invention relates to the field of computer technology, and in particular, to a method for handling an application crash, an apparatus for running an application, a system for handling an application crash, and a computer program product for performing the steps of the method.
Background
More and more applications (apps) are being developed and deployed on intelligent terminals (e.g., computers, mobile terminals, car-in-vehicle systems of intelligent networked cars, etc.). For example, with the development of intelligent networked automobiles, more and more applications are developed and deployed on users' mobile terminals and/or vehicles (car machines) to provide or support various functions or services related to the vehicles. During the use of these applications, the applications may crash for various reasons. This presents challenges to the stability of the application.
The solutions proposed in the prior art for application crashes deal primarily with application crashes in some single or fixed way: for example, after a program crash is monitored, the user data is cleared for recovery or reboot. However, a single or fixed processing method (e.g. clearing user data and restarting an application) cannot flexibly and effectively solve different types of application crashes, and has a great application limitation, especially in the case that the program crash cannot be eliminated after repeatedly clearing user data and restarting the program, even uninstalling and reinstalling the program.
Therefore, how to flexibly and effectively handle various application crash problems becomes a technical problem to be solved at present.
Disclosure of Invention
It is an object of the present invention to provide a method for handling an application crash, a device for running an application, a system for handling an application crash and a computer program product for performing the steps of said method to at least partly solve the problems of the prior art. The invention is based on the following basic idea: the method comprises the steps that a configuration table of an application program crash processing strategy is stored in a configuration table stored in a client device locally in advance, and the crash processing strategy matched with the generated application program crash is selected and executed when the application program crash is monitored by continuously monitoring the generation of the application program crash. According to some embodiments of the invention, the crash processing strategy can be automatically matched and executed according to the crash information of the application program without the participation of a user, so that the efficiency of crash processing of the application program and the running stability of the application program are improved.
According to a first aspect of the present invention, there is provided a method of handling an application crash, the method comprising:
monitoring whether an application program crash occurs;
if the crash of the application program is monitored, acquiring the crash information of the application program;
judging whether the crash information of the application program exists in a configuration table of an application program crash processing strategy or not, wherein the configuration table comprises a mapping relation between the stored crash information of the application program and the crash processing strategy; and
and if the crash information of the application program exists in the configuration table, performing crash processing based on a crash processing strategy corresponding to the crash information of the application program in the configuration table.
According to an alternative embodiment of the present invention, the crash processing may be performed based on a crash processing policy corresponding to crash information of the application program in the configuration table, in particular, automatically without being based on an input by a user.
According to an alternative embodiment of the present invention, the configuration table of the application crash handling policy may be stored locally at the client device running the application, and optionally the configuration table may be updated remotely through a backend server.
According to an optional embodiment of the present invention, after the application program is started and/or when the application program crash processing policy configuration table stored in the client local storage module does not have the crash information of the application program, the backend server may be queried whether there is an updated application program crash processing policy configuration table. If the backend server is inquired that the updated configuration table of the application program crash processing strategy exists, the updated configuration table can be downloaded from the backend server and the local configuration table of the client device where the application program is located can be updated. In this way, it can be ensured that the latest configuration table is involved in the matching, thereby avoiding the failure of matching of crash processing policies caused by not updating the configuration table in time.
According to an alternative embodiment of the present invention, the crash information of the application program may include, for example, type information and/or identification information of the application program crash, wherein the type information includes, for example, a crash type, and the identification information includes, for example, a full class name, a method name and/or a file name, wherein the full class name includes a class name and/or a package name.
According to an alternative embodiment of the invention, the method may further comprise:
monitoring whether the application program crashes for a preset number of times within a preset time period after the application program crashes is subjected to crash processing; and
and if the application program crashes for a preset number of times within a preset time period, stopping executing the crash processing and reporting to the back-end server.
According to an alternative embodiment of the present invention, the matching of the acquired crash information of the application program and the crash information of the application program in the configuration table may be performed by fuzzy judgment, wherein the judgment based on the fuzzy judgment may be dynamically adjusted, in particular added and/or removed, according to the acquired crash information of the application program and/or the crash information of the application program in the configuration table according to a parameter, thereby improving flexibility and reliability of the matching.
According to an alternative embodiment of the invention, the crash handling policy may for example comprise one or more of the following policies:
no operation is performed;
displaying an error page and guiding a user to clear user data;
displaying an upgrade page and guiding a user to upgrade an application program;
displaying a page to show a recommended solution;
performing an automatic restart;
performing an automatic reboot and cleaning up local user data;
displaying a page to show an application crash report;
logging out and logging in the application program again;
reinitializing the software development kit without restarting the application;
a first demotion policy and a first promotion policy corresponding to the first demotion policy; and
a second destage policy and a second promotion policy corresponding to the second destage policy.
According to an optional embodiment of the present invention, the crashed sub-function of the application program may be determined based on the crash information of the application program, and the crashed sub-function of the application program may be closed based on the first downgrading policy until the closed sub-function is restarted based on the first upgrading policy after the application program is restarted and/or the execution of the first downgrading policy is stopped. And performing degradation processing on the application program by closing the crashed sub-function of the application program, so that the user can continue to use other sub-functions which are not crashed.
According to the optional embodiment of the invention, whether the times of the crashes of the application programs of the same type in the preset time period exceed a preset threshold value is judged; if the number of times of the same type of application program crash in a preset time period exceeds a preset threshold, judging whether the determined sub-function belongs to a preset sub-function or not based on the crash information of the application program; and if the determined sub-functions belong to the preset sub-functions, closing the sub-functions of the application program, which are crashed, based on the second downgrading strategy until the application program finishes upgrading or the back-end service provided by the back-end server finishes updating, and then re-opening the closed sub-functions based on the second upgrading strategy. And when the important subfunctions are monitored to be frequently broken down, the important subfunctions are closed until the application program is upgraded or the back-end service provided by the back-end server is updated, and the user can continue to use other important subfunctions which are not broken down.
According to an alternative embodiment of the invention, the method may further comprise: acquiring a configuration table of an application program crash processing strategy adapted to parameters from a back-end server based on the parameters of the client, and synchronously updating the configuration table stored in the local part of the client; the parameters of the client include, for example, an operating system type, an operating system version, an application version, and/or a device model of the client.
According to an alternative embodiment of the invention, the method may further comprise:
judging whether the application program crash is a main thread crash or a sub thread crash based on the monitored thread information of the application program crash;
if the application program crash is sub-thread crash, recording crash information of the sub-thread;
and if the application program is a main thread crash, performing crash processing on the main thread crash.
According to a second aspect of the invention, there is provided an apparatus for running an application. The apparatus may comprise the following components:
the application program crash monitoring module is configured to monitor occurrence of application program crash and acquire crash information of the application program;
an application crash protection management module configured to enable and/or disable respective application crash handling functions and to enable and/or disable remote update functions of the configuration table based on crash information of the application and a configuration table of application crash handling policies;
a crash processing module configured to process the application crash based on a crash processing policy corresponding to the acquired crash information of the application; and
a client local storage module configured to locally store the configuration table, the configuration table including a mapping relationship between crash information of an application and a crash handling policy.
According to an alternative embodiment of the present invention, the crash processing module may be configured to perform the crash processing based on a crash processing policy corresponding to crash information of the application program in the configuration table automatically, without being based on input from a user.
According to an optional embodiment of the present invention, a configuration table of the application crash processing policy may be stored in the client local storage module, and optionally, the stored configuration table may be updated remotely through a backend server.
According to an optional embodiment of the present invention, the application crash protection management module may be configured to query whether the backend server has a configuration table of the updated application crash handling policy after the application is started and/or when the configuration table of the application crash handling policy stored in the client local storage module does not have the crash information of the application; and if the configuration table of the updated application program crash processing strategy exists in the rear-end server, downloading the updated configuration table from the rear-end server and updating the configuration table stored in the local storage module of the client.
According to an alternative embodiment of the present invention, the crash information of the application program may include type information and/or identification information of the crash of the application program, wherein the type information includes, for example, a crash type, and the identification information includes, for example, a full class name including, for example, a class name and/or a package name, a method name, and/or a file name.
According to an optional embodiment of the present invention, the application crash protection management module may be configured to monitor whether a preset number of times of application crashes occur within a preset time period, and stop executing the crash processing and report to the back-end server when the preset number of times of application crashes occur within the preset time period.
According to an alternative embodiment of the present invention, the application crash protection management module may be configured to perform matching of the acquired crash information of the application and the crash information of the application in the configuration table by fuzzy judgment, wherein the judgment based on the fuzzy judgment can be dynamically adjusted, especially added and/or removed, according to the acquired crash information of the application and/or the crash information of the application in the configuration table according to parameters, thereby improving flexibility and reliability of the matching.
According to an alternative embodiment of the invention, the crash handling policy may comprise one or more of the following policies:
no operation is performed;
displaying an error page and guiding a user to clear user data;
displaying an upgrade page and guiding a user to upgrade an application program;
displaying a page to show a recommended solution;
performing an automatic restart;
performing an automatic reboot and cleaning up local user data;
displaying a page to show an application crash report;
logging out and logging in the application program again;
reinitializing the software development kit without restarting the application;
a first demotion policy and a first promotion policy corresponding to the first demotion policy; and
a second destage policy and a second promotion policy corresponding to the second destage policy.
According to an optional embodiment of the present invention, the crash processing module may be configured to determine a crashed sub-function of the application based on the crash information of the application, and to close the crashed sub-function of the application based on the first downgrading policy, until the closed sub-function is restarted based on the first upgrading policy after the application is restarted and/or the execution of the first downgrading policy is stopped.
According to an optional embodiment of the present invention, the crash processing module may be configured to determine whether a number of times that the same type of application crashes within a preset time period exceeds a preset threshold; if the number of times of the same type of application program crash in a preset time period exceeds a preset threshold, judging whether the determined sub-function belongs to a preset sub-function or not based on the crash information of the application program; and if the determined sub-functions belong to the preset sub-functions, closing the sub-functions of the application program, which are crashed, based on the second downgrading strategy until the application program finishes upgrading or the back-end service provided by the back-end server finishes updating, and then re-opening the closed sub-functions based on the second upgrading strategy.
According to an optional embodiment of the present invention, the crash processing module may be configured to obtain, from the backend server, a configuration table of the application crash processing policy adapted to the parameter based on the parameter of the client, and perform synchronous update on the configuration table stored locally at the client; the parameters of the client include, for example, an operating system type, an operating system version, an application version, and/or a device model of the client.
According to the optional embodiment of the invention, the application crash monitoring module judges whether the application crash is a main thread crash or a sub thread crash based on the monitored thread information of the application crash; and if the application program is a main thread crash, performing crash processing on the main thread crash.
According to a third aspect of the present invention, there is provided a system for handling an application crash, said system being arranged to perform the method according to the present invention. The system may include the following components:
the application program crash monitoring module is configured to monitor occurrence of application program crash and acquire crash information of the application program;
an application crash protection management module configured to enable and/or disable respective application crash processing functions and to enable and/or disable remote update functions of the configuration table based on crash information of the application and a configuration table of application crash processing policies;
a crash processing module configured to process the application crash based on a crash processing policy corresponding to the acquired crash information of the application;
a client local storage module configured to store the configuration table locally at a client running the application program, wherein the configuration table comprises a mapping relationship between information of program crash and a degradation policy; and
a back-end server configured to enable remote updating of the configuration table in the client local storage module.
According to a fourth aspect of the invention, a computer program product, for example a computer-readable program carrier, is provided, containing computer program instructions which, when executed by a processor, at least auxiliarily implement the steps of the method according to the invention.
Drawings
The principles, features and advantages of the present invention may be better understood by describing the invention in more detail below with reference to the accompanying drawings. The figures show:
FIG. 1 illustrates a workflow diagram of a method for handling an application crash in accordance with an exemplary embodiment of the present invention;
FIG. 2 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention;
FIG. 3 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the invention;
FIG. 4 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention;
FIG. 5 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention;
FIG. 6 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention;
FIG. 7 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention;
FIG. 8 illustrates a block diagram of an apparatus for running an application according to an exemplary embodiment of the present invention;
FIG. 9 depicts a block diagram of a system for handling an application crash in accordance with an illustrative embodiment of the present invention; and
FIG. 10 shows a timing diagram for explaining the process of a program crash in accordance with an example embodiment of the present invention.
Detailed Description
In order to make the technical problems, technical solutions and advantageous effects of the present invention more apparent, the present invention will be described in further detail with reference to the accompanying drawings and exemplary embodiments. It should be understood that the specific embodiments described herein are merely illustrative of the invention and do not limit the scope of the invention.
FIG. 1 illustrates a workflow diagram of a method for handling an application crash in accordance with an exemplary embodiment of the present invention.
The method may comprise steps S1 to S4. In step S1, it is monitored whether an application crash occurs. In the current embodiment of the present invention, the application program may include a main thread program. Optionally, at least one child thread program may also be included. Here, the occurrence of a crash of the main thread program and/or the sub thread program may be monitored by calling the thread.
And if the application program is monitored to be crashed, acquiring the crash information of the application program in step S2. In this main thread program, a polling task, which is implemented by, for example, calling a loop () function and can be executed circularly, can be executed by the application crash monitoring module 11, thereby implementing continuous monitoring of the running state of the main thread program. After the main thread program is monitored to be crashed, the try catch () function can be called in time, and the crash information of the main thread crash can be captured through the try catch () function. Here, the crash information of the application may include, for example, type information of the crash of the application, the type information including, for example, a type of the crash; the crash information of the application may also include, for example, identification information of the crash of the application, including, for example, a full class name, a method name, and/or a file name, etc. Here, a program segment for executing each sub-function of the application program may be indicated by a method name. The full class name may include a class name and/or a package name by which the sub-functionality affected by the application crash may be determined.
Illustratively, the stack information of the main thread program in which the application crash occurs may be extracted by the application crash monitoring module 11 and resolved into the crash information B of the application by means of the resolving unit 16, which is passed to the application crash protection management module 12, as shown in the timing diagram of fig. 10.
In step S3, it is determined whether the crash information B of the program exists in a configuration table of the application crash processing policy, where the configuration table may include a mapping relationship between the stored crash information a of the application program and the crash processing policy. Here, the configuration table of the application crash handling policy may be stored locally on the client device running the application, and the application crash protection management module 12 may obtain the locally stored configuration table from the client local storage module 14 and parse the configuration table into the crash information a of the application included in the configuration table by means of the parsing unit 16. By traversing the crash information a of the application program in the configuration table, matching the acquired crash information B of the application program with the crash information a of the application program in the configuration table, thereby determining whether the acquired crash information B of the application program exists in the configuration table, and the determination result can be represented by, for example, a true determination value.
As exemplarily shown in Table 1, the configuration table may include one or more of the following crash handling policies:
policy sequence number Crash handling policy
1 Do nothing
2 Displaying error pages and guiding users to clean up user data
3 Displaying an upgrade page and guiding a user to perform an application upgrade
4 Displaying pages to show recommended solutions
5 Performing an automatic restart
6 Performing an automatic reboot and cleaning up local user data
7 Displaying a page to expose an application crash report
8 Logging out and re-logging in an application
9 Reinitializing a software development kit without restarting an application
10 A first demotion policy and a first promotion policy corresponding to the first demotion policy
11 A second demotion policy and a second promotion policy corresponding to the second demotion policy
Table 1 shows crash handling policies contained in a configuration table
In an alternative embodiment of the present invention, the matching between the acquired crash information B of the application program and the crash information a of the application program in the configuration table may be performed by fuzzy judgment. Here, the matching criterion of the fuzzy judgment may include one or more of a crash type, a full class name, a method name, and a file name. The following exemplarily shows a program code for performing the matching procedure. Here, the matching basis parameters include an crash type (exceptinetType), a class name (className), and a file name (fileName), and true value information (isNativemethod) about whether there is a matching crash processing policy in the configuration table can be obtained by fuzzy determination based on the matching basis parameters, and the matching policy number is obtained if the true value information is true.
Figure BDA0003936261410000101
Figure BDA0003936261410000111
Furthermore, the matching can be dynamically adjusted, in particular added and/or removed, depending on the obtained crash information B of the application and/or the crash information a of the application in the configuration table, thereby increasing the flexibility and reliability of the matching. For example, a method name may also be added to the matching dependency parameter, by means of which method name a program section with a crash can be indicated.
If the crash information B of the application exists in the configuration table (i.e., the determination truth information is true), in step S4, crash processing is performed based on a crash processing policy corresponding to the crash information B of the application in the configuration table. Here, the crash processing may be performed based on a crash processing policy corresponding to the crash information B of the application in the configuration table automatically without being based on an input by a user. In contrast, in the prior art, a message about application crash needs to be notified to a user, and the user selects an adaptive crash processing policy at his or her discretion, which not only reduces the processing efficiency of application crash, but also requires a certain processing experience of the user.
Here, most of the crash handling policies shown in table 1 (e.g., crash handling policies 2 through 6 and 8, 9, etc.) handle application crashes by cleaning user data, logging back into the application, automatically restarting the application, reinitializing the software development kit, etc. These application crashes typically occur during the launch of an updated application, where the user cannot use any sub-functionality in the application, and the application is normally used by executing such crash handling policies.
For example, part of the sub-functions in the application program are abnormal, especially show abnormal, which may be caused by that the application program crashes and the program code corresponding to the sub-functions is not executed. If the influence of the abnormal sub-function on the application program is small, for example, the content related to the abnormal sub-function in the page shows abnormal, the user can only not see the part of the content, and other content in the page still shows normal, especially other sub-functions of the application program can still be normally put into use, then the crash handling policy 1 may be adopted without any operation.
The page may also be displayed, for example, via crash handling policy 7, to expose a crash report that may be sent via email to development and testing personnel for analysis and reporting.
The crash handling policy further includes a downgrade policy and an upgrade policy corresponding to the downgrade policy. In the sense of the present invention, "degradation" can be understood as follows: when the application program is abnormal, in order to control the influence range of the abnormality, partial (for example, non-important) subfunctions in the application program are closed, thereby ensuring that the important subfunctions of the application program operate normally. The sub-functions of the application may be ranked based on their priority and/or dependency, for example if one sub-function has a high priority and/or a strong dependency on other sub-functions, the sub-function may be classified as an important sub-function, such as a function of a remote control vehicle.
In another optional embodiment of the present invention, for the first destaging policy and the first promotion policy corresponding to the first destaging policy, the step S4 may include steps S411 to S413, as shown in fig. 2. In step S411, the sub-function of the application program that crashed is determined based on the crash information B of the application program. The following shows a program code according to another alternative embodiment of the present invention, which may determine a program segment in an application program that is crashed according to a method name (methodName) in crash information B of the application program, determine a sub-function affected by the crash according to a class name (fileName) in the crash information B of the application program, then issue a switch (toggle) name corresponding to the sub-function to a client, and set the function to be turned on and/or turned off according to a state of the switch.
{"data":[{"exceptionType":"java.lang.RuntimeException",
"className":"io_realm_internal_OsSharedRealm",
"fileName":"io_realm_internal_OsSharedRealm.cpp",
"isNativeMethod":true,
"methodName":"nativeGetSharedRealm",
"downgradeStrategy":10,
"toggle":["ris-mystar-camera"],
"matchRules":["exceptionType","fileName","isNativeMethod",
"methodName"]}]}
In step S412, the crashed sub-function of the application program may be closed based on the first destage policy. In the current embodiment of the present invention, it may be determined that a crash processing policy 10 is to be adopted based on the analyzed crash information of the application program, and the switch state corresponding to the sub-function is set to be the closed state, so that the user entry of the sub-function is no longer shown in the display page of the application program, thereby closing the sub-function of the application program that crashes, and the user may continue to use other sub-functions that do not crash.
Until the application is restarted and/or the first downgrading strategy is stopped, the closed sub-functions may be restarted in step S413 based on the first upgrading strategy corresponding to the first downgrading strategy, so that all sub-functions of the application are recovered to normal.
In another optional embodiment of the present invention, for the second destaging policy and the second promotion policy corresponding to the second destaging policy, the step S4 may include steps S421 to S425, as shown in fig. 3. In step S421, it is determined whether the number of times of the crashes of the application programs of the same type occurring within the preset time period exceeds a preset threshold. Here, an application crash type may be determined based on the crash information B of the application, and the number of times the application crash type occurs within a preset time period is retrieved. If the application crash type is not retrieved, a crash record can be created for the application crash type so that the crash record can be queried the next time an application crash of the type occurs.
If the number of times of the same type of application crashes occurring within the preset time period exceeds the preset threshold, which means that the type of application crashes frequently occur, the sub-function of the application where the crash occurred may be determined based on the crash information B of the application in step S422. Similarly, the program section with the crash in the application program can be determined according to the method name in the crash information B of the application program, the sub-function influenced by the crash is determined according to the class name and/or the package name in the crash information B of the application program, and then the switch name corresponding to the sub-function is issued to the client.
After the determination of the subfunction, it is determined in step S423 whether the determined subfunction belongs to a predetermined subfunction, which includes, for example, a function of a remote control vehicle. If the determined sub-function belongs to the pre-given sub-function, it may be determined that crash handling policy 11 is to be taken, and then the crashed sub-function of the application is closed based on the second destage policy in step S424. Here, the switch state corresponding to the sub-function may be set to an off state, so that the important sub-function (e.g., a function of remotely controlling a vehicle) of the application program that is crashed is turned off, and the user may continue to use other important sub-functions that are not crashed. While the sub-function is turned off, optionally, a prompt message about that the current sub-function is unavailable may also be sent to the user through the back-end server 15.
Until the application is upgraded or the backend service provided by the backend server 15 is updated, the turned-off sub-functions are turned back on based on the second upgrade policy corresponding to the second downgrade policy in step S425. This is in contrast to executing the first upgrade policy until after the application is restarted and/or stopped from executing the first downgrade policy, because this type of application crash frequently occurs, and may continue to occur particularly after the application is restarted, so the second upgrade policy is not executed until the application's repair is completed by an upgrade or update of the backend service.
It will be appreciated that the crash handling policy can be adjusted as desired and is not limited to the above listed policies.
According to the current embodiment of the invention, the crash processing strategy can be automatically matched and executed according to the crash information of the application program without the participation of a user, so that the crash processing efficiency of the application program is improved, and the sub-functions of the application program which are not crashed are ensured to be available to use as much as possible.
FIG. 4 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention. Only the differences from the embodiment shown in fig. 1 are set forth below, and the description of the same steps is not repeated for the sake of brevity.
The method may further include steps S110 and S11. In step S110, it is determined whether the function of the application crash processing is activated. If the function of the application crash processing is turned on, the configuration table of the application crash processing policy is remotely updated through the backend server 15 in step S11. In another optional embodiment of the present invention, a configuration table that can be adjusted in real time according to actual requirements is stored in the back-end server 15, and a configuration table of an application crash processing policy adapted to parameters can be obtained from the back-end server 15 based on the parameters of the client, and the configuration table stored locally at the client is updated synchronously, where the parameters of the client may include, for example, an operating system type, an operating system version, an application version, and/or a device model of the client. It will be appreciated that the configuration table information required for different operating system types, operating system versions, application versions, and/or device models of the client may differ from one another.
It should be noted that the configuration table stored locally may be updated to the latest state after the application program is started, and the synchronous update may also be performed after step S3. As shown in fig. 5, the method may further include steps S10 and S11. If it is determined in step S3 that the crash information B of the application does not exist in the configuration table of the application crash processing policy stored in the client local storage module, it is queried in step S10 whether the backend server 15 has an updated configuration table of the application crash processing policy. If the backend server 15 is queried to have the updated configuration table of the application crash processing policy, in step S11, the updated configuration table is downloaded from the backend server 15 and the configuration table local to the client device where the application is located is updated. In this way, it can be ensured that the latest configuration table is involved in the matching, thereby avoiding the failure of matching of crash processing policies caused by not updating the configuration table in time.
FIG. 6 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention. Only the differences from the embodiment shown in fig. 1 are set forth below, and the description of the same steps is not repeated for the sake of brevity.
The method may further comprise steps S5 and S6. In step S5, after performing crash processing on the application crash, whether the application crash occurs a preset number of times within a preset time period is monitored. If the application crashes a preset number of times within a preset time period, the execution of the crash processing is stopped and reported to the back-end server 15 in step S6. In another alternative embodiment of the present invention, for example, if an application crash occurs three times in a one-minute period, it means that the application crash is difficult to repair through the crash handling policy in the current configuration table, so that it can be reported to the back-end server 15, and then the developer and/or maintenance personnel at the back-end can add a crash handling policy adapted to the application crash to the configuration table according to the content of the report. By the method, the unsolved application program crash can be timely reported to back-end personnel, so that the applicability of the crash processing strategy is improved.
FIG. 7 illustrates a workflow diagram of a method for handling an application crash in accordance with another exemplary embodiment of the present invention. Only the differences from the embodiment shown in fig. 1 are set forth below, and the same steps are not repeated for the sake of brevity.
The method may further comprise steps S12 and S13. In step S12, it is determined whether the application crash is a main thread crash or a sub thread crash based on the monitored thread information of the application crash. If the application program crash is a sub-thread crash, crash information of the sub-thread crash is recorded in step S13, and for example, buried point and log information may be obtained based on the crash information without performing crash processing on the sub-thread program; if the application program is a main thread crash, step S2 is entered to perform crash processing according to the present invention on the main thread crash. The reliability of application program crash monitoring can be effectively improved by simultaneously using two or more application program crash monitoring modes, and the crash occurring in the sub-thread program can be recorded.
In addition, it should be noted that the sequence numbers of the steps described herein do not necessarily represent a sequential order, but merely one kind of reference numeral, and the order may be changed according to circumstances as long as the technical object of the present invention can be achieved.
Fig. 8 shows a block diagram of an apparatus for running an application according to an exemplary embodiment of the present invention.
As shown in fig. 8, the apparatus 1 may comprise the following components: an application crash monitoring module 11 configured to monitor occurrence of an application crash and acquire crash information of the application; an application crash protection management module 12 configured to enable and/or disable corresponding application crash handling functions and to enable and/or disable remote update functions of the configuration table based on the application crash information and a configuration table of application crash handling policies; a crash processing module 13 configured to process the application crash based on a crash processing policy corresponding to the acquired crash information of the application; and a client local storage module 14 configured to locally store the configuration table, wherein the configuration table includes a mapping relationship between the crash information a of the application program and the crash processing policy. Optionally, the apparatus 1 further comprises a parsing unit 16 configured to parse stack information of an application program that crashes into crash information B of the application program and/or parse the configuration table into crash information a of the application program contained in the configuration table.
FIG. 9 illustrates a block diagram of a system for handling an application crash in accordance with an exemplary embodiment of the present invention. The system 10 may include the device 1 and a back-end server 15 configured to enable remote updating of the configuration table in the client local storage module. Here, the device 1 may also include an application crash monitoring module 11, an application crash protection management module 12, a crash processing module 13, and a client local storage module 14, as in the embodiment shown in fig. 8, and will not be described again here.
A timing diagram illustrating an application crash process according to an exemplary embodiment of the present invention is shown below in conjunction with figure 10.
After the application is started, in step S1, whether an application crash occurs is monitored, and in step S110, whether a function of the application crash processing is activated is determined. If the functionality of the application crash processing is turned on, the application crash protection management module 12 may send an on signal to the application crash monitoring module 11. After receiving the start signal, the application crash monitoring module 11 may monitor the occurrence of the application crash, and execute step S2 to obtain the crash information B of the application and send the obtained crash information to the application crash protection management module 12. After the application crash protection management module 12 receives the crash information B of the application, it may be determined in step S3 whether the crash information B of the application exists in the configuration table of the application crash processing policy stored in the client local storage module 14, and when the crash information B exists, the crash processing module 13 executes step S4, that is, performs crash processing based on the crash processing policy corresponding to the crash information B of the application in the configuration table.
Meanwhile, if it is determined in step S110 that the function of the application crash processing is activated, the configuration table of the application crash processing policy is remotely updated through the backend server 15 in step S11. Here, an enabling signal of the remote update function may be sent to the application crash protection management module 12, and the application crash protection management module 12, after receiving the enabling signal, obtains, from the backend server 15, a configuration table of the application crash handling policy adapted to the parameter based on the parameter of the client, and performs synchronous update on the configuration table stored in the client local storage module 14, where the parameter of the client may include, for example, an operating system type, an operating system version, an application version, and/or a device model of the client. The parsing unit 16 may parse the updated configuration table into the crash information a of the application program contained in the configuration table, and send the parsed crash information a to the application crash protection management module 12, so that the crash information B of the application program and the parsed crash information a may be matched in the application crash protection management module 12.
Although specific embodiments of the invention have been described herein in detail, they have been presented for purposes of illustration only and are not to be construed as limiting the scope of the invention. Various alternatives and modifications can be devised without departing from the spirit and scope of the present invention.

Claims (26)

1. A method of handling an application crash, the method comprising:
monitoring whether an application program crash occurs;
if the crash of the application program is monitored, acquiring crash information (B) of the application program;
judging whether the application program crash information (B) exists in a configuration table of an application program crash processing strategy, wherein the configuration table comprises a mapping relation between the stored crash information (A) of the application program and the crash processing strategy; and
if the crash information (B) of the application program exists in the configuration table, performing crash processing based on a crash processing policy corresponding to the crash information (B) of the application program in the configuration table.
2. The method of claim 1, wherein the crash processing is performed automatically based on a crash processing policy in the configuration table corresponding to the crash information (B) of the application, not based on input from a user.
3. The method of claim 1 or 2, wherein the configuration table of the application crash handling policy is stored locally at a client device running the application and is updated remotely via a backend server (15).
4. Method according to any of claims 1 to 3, characterized in that after application startup and/or when no crash information (B) of the application is present in the configuration table of application crash handling policies stored in the client local storage module, the backend server (15) is queried as to whether there is a configuration table of updated application crash handling policies; if there is an update, the updated configuration table is downloaded from the back-end server (15) and the configuration table local to the client device where the application is located is updated.
5. Method according to any of claims 1 to 4, wherein the crash information (A, B) of the application comprises type information and/or identification information of the application crash, wherein the type information comprises a crash type and the identification information comprises a full class name, a method name and/or a file name, wherein the full class name comprises a class name and/or a package name.
6. The method according to any one of claims 1 to 5, further comprising:
monitoring whether the application program is crashed for a preset number of times in a preset time period after the application program is crashed; and
and if the application program crashes for a preset number of times within a preset time period, stopping executing the crash processing and reporting to a back-end server (15).
7. Method according to any of claims 1 to 6, characterized in that the matching of the retrieved crash information (B) of the application with the crash information (A) of the application in the configuration table is performed by fuzzy judgment, wherein the judgment based on the fuzzy judgment can be dynamically adjusted depending on the retrieved crash information (B) of the application and/or the crash information (A) of the application in the configuration table depending on parameters.
8. The method of any of claims 1-7, wherein the crash handling policy comprises one or more of:
no operation is performed;
displaying an error page and guiding a user to clear user data;
displaying an upgrade page and guiding a user to upgrade an application program;
displaying a page to show a recommended solution;
performing an automatic restart;
performing an automatic reboot and cleaning up local user data;
displaying a page to show an application crash report;
logging out and logging in the application program again;
reinitializing the software development kit without restarting the application;
a first demotion policy and a first promotion policy corresponding to the first demotion policy; and
a second destage policy and a second promotion policy corresponding to the second destage policy.
9. Method according to any of claims 1 to 8, characterized in that the crashed sub-functionality of the application is determined based on the crash information (B) of the application and the crashed sub-functionality of the application is closed based on the first downgrading strategy until the closed sub-functionality is re-opened based on the first upgrade strategy after the restart of the application and/or the stop of the execution of the first downgrading strategy.
10. The method according to any one of claims 1 to 9, wherein it is determined whether the number of times of application crashes of the same type occurred within a preset time period exceeds a preset threshold; if the number of times of collapse of the application programs of the same type in a preset time period exceeds a preset threshold value, judging whether the determined sub-functions belong to preset sub-functions or not based on collapse information (B) of the application programs; and if the determined sub-function belongs to the preset sub-function, closing the sub-function of the application program, which is crashed, based on the second downgrading strategy until the application program finishes upgrading or the back-end service provided by a back-end server (15) finishes updating, and then re-opening the closed sub-function based on the second upgrading strategy.
11. The method according to any one of claims 1 to 10, further comprising: acquiring a configuration table of an application program crash processing strategy adapted to the parameters from a back-end server (15) based on the parameters of the client, and synchronously updating the configuration table stored in the local part of the client; the parameters of the client comprise an operating system type, an operating system version, an application program version and/or a device model of the client.
12. The method according to any one of claims 1 to 11, further comprising:
judging whether the application program crash is a main thread crash or a sub thread crash based on the monitored thread information of the application program crash;
if the application program crash is sub-thread crash, recording crash information of the sub-thread;
and if the application program is a main thread crash, performing the crash processing on the main thread crash.
13. A device (1) for running applications, characterized in that said device (1) comprises the following means:
an application crash monitoring module (11) configured to monitor occurrence of an application crash, and acquire crash information of the application;
an application crash protection management module (12) configured to enable and/or disable respective application crash handling functions and to enable and/or disable remote update functions of the configuration table based on crash information of the application and a configuration table of application crash handling policies;
a crash processing module (13) configured to process the application crash based on a crash processing policy corresponding to the acquired crash information of the application; and
a client local storage module (14) configured to locally store the configuration table, the configuration table including a mapping relationship between crash information (A) of an application and a crash handling policy.
14. Device (1) according to claim 13, characterized in that the crash handling module (13) is configured to perform the crash handling not based on input from a user, automatically based on a crash handling policy in the configuration table corresponding to crash information (B) of the application.
15. The device (1) according to claim 13 or 14, wherein a configuration table of the application crash handling policy is stored in the client local storage module (14) and the stored configuration table is updated remotely via a back-end server (15).
16. The device (1) of any of claims 13-15, wherein the application crash protection management module (12) is configured to query a backend server (15) for a configuration table of updated application crash handling policies after application startup and/or when no crash information (B) for the application exists in the configuration table of application crash handling policies stored in the client local storage module; if there is an update, downloading the updated configuration table from the back-end server (15) and updating the configuration table stored in the client local storage module (14).
17. Device (1) according to any of claims 13-16, wherein the crash information of the application comprises type information and/or identification information of an application crash, wherein the type information comprises a crash type and the identification information comprises a full class name, a method name and/or a file name, wherein the full class name comprises a class name and/or a package name.
18. The device (1) of any of claims 13-17, wherein the application crash protection management module (12) is configured to monitor whether a preset number of application crashes have occurred within a preset time period, and to stop performing the crash processing and report to a back-end server (15) when a preset number of application crashes have occurred within a preset time period.
19. The device (1) according to any of claims 13 to 18, wherein the application crash protection management module (12) is configured to perform the matching of the acquired crash information (B) of the application with the crash information (a) of the application in the configuration table by means of a fuzzy decision, wherein the decision on the basis of which the fuzzy decision can be dynamically adjusted in dependence on the acquired crash information (B) of the application and/or the crash information (a) of the application in the configuration table in dependence on a parameter.
20. Device (1) according to any one of claims 13 to 19, characterized in that said crash handling policy comprises one or more of the following policies:
no operation is performed;
displaying an error page and guiding a user to clear user data;
displaying an upgrade page and guiding a user to upgrade an application program;
displaying a page to show a recommended solution;
performing an automatic restart;
performing an automatic reboot and cleaning up local user data;
displaying a page to show an application crash report;
logging out and logging in the application program again;
reinitializing the software development kit without restarting the application;
a first demotion policy and a first promotion policy corresponding to the first demotion policy; and
a second destage policy and a second promotion policy corresponding to the second destage policy.
21. Device (1) according to any one of claims 13 to 20, characterized in that the crash handling module (13) is configured to determine a crashed sub-function of the application on the basis of the crash information (B) of the application and to shut down the crashed sub-function of the application on the basis of the first downgrading policy until, after restarting the application and/or stopping executing the first downgrading policy, restarting the shut-down sub-function on the basis of the first upgrading policy.
22. The device (1) according to any of claims 13 to 21, wherein the crash handling module (13) is configured to determine whether a number of times of crashes of the same type of application occurred within a preset time period exceeds a preset threshold; if the number of times of the same type of application program crash in a preset time period exceeds a preset threshold, judging whether the determined sub-function belongs to a preset sub-function or not based on the crash information (B) of the application program; and if the determined sub-function belongs to the preset sub-function, closing the sub-function of the application program, which is crashed, based on the second downgrading strategy until the application program finishes upgrading or the back-end service provided by a back-end server (15) finishes updating, and then re-opening the closed sub-function based on the second upgrading strategy.
23. The device (1) according to any of claims 13 to 22, wherein the crash processing module (13) is configured to obtain, from the backend server (15), a configuration table of an application crash processing policy adapted to the parameters based on the parameters of the client, and to perform a synchronous update of the configuration table stored locally at the client; the parameters of the client comprise an operating system type, an operating system version, an application program version and/or a device model of the client.
24. The device (1) according to any one of claims 13 to 23, wherein the application crash monitoring module (11) determines whether the application crash is a main thread crash or a sub thread crash based on the monitored thread information of the application crash; and if the application program is a main thread crash, performing crash processing on the main thread crash.
25. A system (10) for handling an application crash, the system (10) being configured to perform the method according to any one of claims 1 to 12, the system (100) comprising:
an application crash monitoring module (11) configured to monitor occurrence of an application crash, and acquire crash information (B) of the application;
an application crash protection management module (12) configured to enable and/or disable respective application crash processing functions and to enable and/or disable remote update functions of the configuration table based on the application crash information (B) and an application crash processing policy configuration table of the application;
a crash processing module (13) configured to process the application crash based on a crash processing policy corresponding to the acquired crash information (B) of the application;
a client local storage module (14) configured to store the configuration table locally at a client running the application, the configuration table comprising a mapping relationship between information (A) of a program crash and a downgrading policy; and
a back-end server (15) configured to enable remote updating of the configuration table in the client local storage module.
26. A computer program product, such as a computer-readable program carrier, containing computer program instructions which, when executed by a processor, at least assist in carrying out the steps of the method according to any one of claims 1 to 12.
CN202211409719.1A 2022-11-10 2022-11-10 Method and system for processing application program crash and device for running application program Pending CN115934390A (en)

Priority Applications (2)

Application Number Priority Date Filing Date Title
CN202211409719.1A CN115934390A (en) 2022-11-10 2022-11-10 Method and system for processing application program crash and device for running application program
PCT/EP2023/025441 WO2024099586A1 (en) 2022-11-10 2023-10-23 Method and system for handling application crash, and device for running application

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN202211409719.1A CN115934390A (en) 2022-11-10 2022-11-10 Method and system for processing application program crash and device for running application program

Publications (1)

Publication Number Publication Date
CN115934390A true CN115934390A (en) 2023-04-07

Family

ID=86653124

Family Applications (1)

Application Number Title Priority Date Filing Date
CN202211409719.1A Pending CN115934390A (en) 2022-11-10 2022-11-10 Method and system for processing application program crash and device for running application program

Country Status (2)

Country Link
CN (1) CN115934390A (en)
WO (1) WO2024099586A1 (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117555717A (en) * 2024-01-10 2024-02-13 深圳聚点互动科技有限公司 Application exception handling method, terminal and computer storage medium

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10263836B2 (en) * 2014-03-24 2019-04-16 Microsoft Technology Licensing, Llc Identifying troubleshooting options for resolving network failures
WO2019026171A1 (en) * 2017-08-01 2019-02-07 株式会社日立製作所 Storage system management system
US11102330B2 (en) * 2019-08-30 2021-08-24 Microstrategy Incorporated Providing updates for server environments

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN117555717A (en) * 2024-01-10 2024-02-13 深圳聚点互动科技有限公司 Application exception handling method, terminal and computer storage medium
CN117555717B (en) * 2024-01-10 2024-04-26 深圳聚点互动科技有限公司 Application exception handling method, terminal and computer storage medium

Also Published As

Publication number Publication date
WO2024099586A1 (en) 2024-05-16

Similar Documents

Publication Publication Date Title
CN112948157B (en) Server fault positioning method, device and system and computer readable storage medium
CN106959866B (en) Log collection client and upgrading method thereof
CN108363659B (en) Method and device for processing abnormity of electronic equipment
JP2010086181A (en) Virtual machine system, method for managing thereof, program, and recording medium
CN111324423B (en) Method and device for monitoring processes in container, storage medium and computer equipment
EP3148116A1 (en) Information system fault scenario information collection method and system
CN112099825B (en) Method, device, equipment and storage medium for upgrading component
US6205561B1 (en) Tracking and managing failure-susceptible operations in a computer system
CN109144534A (en) Service module dynamic updating method, device and electronic equipment
US20230281003A1 (en) Deployment of new versions of event consumers in an event-driven system
CN115934390A (en) Method and system for processing application program crash and device for running application program
CN107967192B (en) System crash processing method and device for intelligent terminal
CN116560791A (en) Processor affinity management method and device for process and electronic equipment
CN114741119A (en) System starting method and device, computer equipment and storage medium
CN114546717A (en) Method and device for starting android intelligent terminal, intelligent terminal and storage medium
KR20160059181A (en) Apparatus and method for controlling updating software of AVN system in vehicle
CN106354602A (en) Service monitoring method and equipment
EP2333668A1 (en) Information processor and hang-up cause investigation information acquiring method
CN107247642B (en) Method and device for determining executable mapping file during system startup
CN111400094A (en) Method, device, equipment and medium for restoring factory settings of server system
CN113094280B (en) Upgrade method, system, and readable storage medium
KR20120030573A (en) A method, apparatus and computer program for loading files during a boot-up process
CN111400076B (en) Downtime restoration method, device, equipment and storage medium
CN115291925A (en) BMC upgrading method, system, equipment and storage medium
CN117742756A (en) System upgrading method and device, storage medium and electronic equipment

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