CN108694108B - iOS crash data classification and statistics method and device - Google Patents

iOS crash data classification and statistics method and device Download PDF

Info

Publication number
CN108694108B
CN108694108B CN201710232014.XA CN201710232014A CN108694108B CN 108694108 B CN108694108 B CN 108694108B CN 201710232014 A CN201710232014 A CN 201710232014A CN 108694108 B CN108694108 B CN 108694108B
Authority
CN
China
Prior art keywords
crash
classification
report
matching
proportion
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
Application number
CN201710232014.XA
Other languages
Chinese (zh)
Other versions
CN108694108A (en
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.)
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
Original Assignee
Beijing Jingdong Century Trading Co Ltd
Beijing Jingdong Shangke Information Technology Co Ltd
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 Beijing Jingdong Century Trading Co Ltd, Beijing Jingdong Shangke Information Technology Co Ltd filed Critical Beijing Jingdong Century Trading Co Ltd
Priority to CN201710232014.XA priority Critical patent/CN108694108B/en
Publication of CN108694108A publication Critical patent/CN108694108A/en
Application granted granted Critical
Publication of CN108694108B publication Critical patent/CN108694108B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/30Monitoring
    • G06F11/3065Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • 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/0766Error or fault reporting or storing
    • G06F11/0775Content or structure details of the error report, e.g. specific table structure, specific error fields

Abstract

The embodiment of the invention provides a method and a device for classifying and counting iOS crash data. The method comprises the following steps: automatically classifying the crash data, extracting calling sentences belonging to application programs in the whole call stack by adopting a call stack reverse searching mode, and outputting a preliminary classification report; through the written configuration file, continuously performing iterative classification on the unclassified crash data, and outputting a recursive classification report after each iteration; and integrating the preliminary classification report and the recursion classification report, and outputting a final report of the crash analysis in combination with a final report of the last crash analysis.

Description

iOS crash data classification and statistics method and device
Technical Field
The invention relates to the field of computers, in particular to a method and a device for classifying and counting iOS (iOS Operation System) crash data.
Background
Currently, apps running on the iOS system usually report stack information, device information, etc. when a crash occurs to a server after the crash occurs (commonly referred to as "application flash back"), some of the apps are completed by official crash collection of applets, and more apps are selected to collect data by using third-party crash collection analysts such as member union, Tencent Bugly, etc.
However, after receiving a large amount of crash data (assuming that a piece of crash data is placed in a text file separately), how to classify the crash files, how to effectively define which crash files belong to the same bug (hidden undetected defects or problems in a system or a program, which are causes of a crash), and how to perform statistical analysis on the crash files so as to better improve the stability of the app.
In the uploaded crash information, the contents of the third-party crash SDK, the crash collection SDK developed by the large company and the crash collection collected by the apple company are very different, but the third-party crash SDK, the crash collection SDK and the crash collection SDK have the following data: crash occurrence time, app version and build number, system version, device type, start time, error type, crash thread call stack information, etc. In the present invention, for the purpose of pursuing versatility, only the original data is limited to the above items.
Most of the prior arts only simply call statement matching at the top of the stack according to the crash thread or completely matching the crash stack as the basis of crash classification. There is no systematic complete solution to achieve accurate classification. Specifically, the method comprises the following steps:
first, a large number of crash logs are obtained, each crash log being a file.
Then, call stack symbolization is performed on all crash logs using symbolocatescah.
Next, a sort operation is performed on the crash files.
And finally, directly extracting the calling statements of the calling stack top for comparison, and if the calling statements of the stack top function are consistent, classifying the function as the same type of crash.
Since the stack top calling statement is the last executed place of the program and is also the statement of the crash, the crash is classified roughly and shallowly directly according to the stack top statement.
In the process of implementing the invention, the inventor finds that at least the following problems exist in the prior art:
since the prior art directly classifies crashes according to the stack top calling statement, the crash causes inaccurate positioning in some cases, because the crash is not necessarily caused by calling the stack top layer code, but is triggered by a middle certain statement call, and what we really need to position is the call that the crash is caused by the statement. For example, there is an abort () statement in the program, which indicates that the developer wants to actively throw an exception and terminate the application, and this statement is commonly used in the system library, and when a system function is called, if a call error or a parameter mismatch is found, the system may call this statement and terminate the application, and at this time, the call stack top statement is abort (). However, the cause of the crash is that the system function is called incorrectly, for example, parameters are wrong, environment configuration is wrong, and the cause of the crash should be located in the statement calling the system function, instead of the statement abort (), and the cause of the crash is that firstly, the system function is uncontrollable, and if an exception occurs, the crash can be repaired only by modifying its calling mode or replacing the calling statement; secondly, many system functions eventually call abort () to terminate applications, and the reason for triggering them is caused by calling mode errors/parameter configuration errors, and what should be found is the real reason for triggering abort, not the statement that triggers crash, abort ().
The classification of the existing scheme can cause that a plurality of real crash reasons are hidden under the same crash, and the classification is not thorough. As just noted, there are a number of reasons why an abort statement may result in the application last calling abort () for which the reason should be classified rather than against the statement.
Disclosure of Invention
Embodiments of the present invention provide a method, an apparatus, an electronic device, and a readable storage medium for iOS crash data classification and statistics. The method can more accurately locate the cause of the crash, and directly locate the essential cause of the crash caused by the program instead of triggering the statement of the crash. The breakdown classification can be completed as far as possible, the classification is clearer, and a plurality of breakdown reasons cannot be hidden under one type of breakdown classification; and moreover, a clean and readable report can be output, problems can be found conveniently, the same collapse change trend can be given by combining the report of the previous version, and the repair result can be verified.
To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided a method for iOS crash data classification and statistics, the method including: automatically classifying the crash data, extracting calling sentences belonging to application programs in the whole call stack by adopting a call stack reverse searching mode, and outputting a preliminary classification report; through the written configuration file, continuously performing iterative classification on the unclassified crash data, and outputting a recursive classification report after each iteration; and integrating the primary classification report and the recursion classification report, and combining the final report of the last crash analysis to output the final report of the crash analysis.
Preferably, the method further comprises: and extracting the class name, the function name and the file function of the calling statement as the description of the crash reason, making a mapping table of the crash reason and a storage folder, and putting the crash data of the same crash reason into the same folder.
Preferably, the method further comprises: and after the written configuration file is read in, converting the written configuration file into an object, converting each matching rule into a matching object, forming a matching object list, and managing the matching object list by a matching manager.
Preferably, the basic function of the matching object is to perform regular matching according to the specific field of the configuration and support multiple field "and" matching and multiple "or" matching.
Preferably, each item of content of the preliminary classification report includes: the classified crash reasons, the duty statistics, and the folder location where the crash type is stored.
Preferably, the final report content includes: the result overview comprises the total number and the proportion of the legal crashes, the number and the proportion of the crashes classified in the primary classification stage, the number and the proportion of the crashes classified in the recursive classification stage and the number and the proportion of the unclassified crashes, each item of content of the crash statistic list comprises the crash reasons, the number and the proportion of the crashes caused by the crash reasons and the positions of folders stored by the crash types, and the crash statistic categories are sorted from high to low according to the proportion.
To achieve the above object, according to an aspect of an embodiment of the present invention, there is provided an apparatus for iOS crash data classification and statistics, the apparatus including: the initial classification module is used for automatically classifying the crash data, extracting calling sentences belonging to the application program in the whole call stack by adopting a call stack reverse searching mode, and outputting an initial classification report; the recursive classification module continuously carries out iterative classification on the unclassified crash data through the written configuration file and outputs a recursive classification report after each iteration; and the report generation module integrates the preliminary classification report and the recursive classification report and outputs a final report of the crash analysis in combination with a final report of the last crash analysis.
Optionally, the preliminary classification module extracts the class name, the function name, and the file function of the calling statement as descriptions of the crash reasons, creates a mapping table between the crash reasons and the storage folder, and puts crash data of the same crash reason into the same folder.
Optionally, after the recursive classification module reads in the written configuration file, the written configuration file is converted into an object, each matching rule is converted into a matching object, and a matching object list is formed, and the matching object list is managed by a matching manager.
Optionally, the basic function of the matching object is to perform regular matching according to the specific field of the configuration, and support multiple fields "and" match and multiple "or" match.
Optionally, each item of content of the preliminary classification report includes: the classified crash reasons, the duty statistics, and the folder location where the crash type is stored.
Preferably, the final report content includes: the result overview comprises the total number and the proportion of the legal crashes, the number and the proportion of the crashes classified in the primary classification stage, the number and the proportion of the crashes classified in the recursive classification stage and the number and the proportion of the unclassified crashes, each item of content of the crash statistics list comprises the crash reasons, the number and the proportion of the crashes caused by the crash reasons and the positions of folders stored by the crash types, and the crash statistics list is sorted from high to low according to the proportion.
An electronic device of an embodiment of the present invention includes: one or more processors; the storage device is used for storing one or more programs, and when the one or more programs are executed by one or more processors, the one or more processors can execute the method for classifying and counting the iOS crash data.
To achieve the above object, according to another aspect of the embodiments of the present invention, there is provided an electronic device for iOS crash data classification and statistics, including: one or more processors; a storage device for storing one or more programs that, when executed by the one or more processors, cause the one or more processors to implement the method for iOS crash data classification and statistics of an embodiment of the present invention.
To achieve the above object, according to still another aspect of an embodiment of the present invention, there is provided a computer-readable storage medium.
A computer-readable storage medium of an embodiment of the present invention stores computer instructions for causing a computer to perform a method for iOS crash data classification and statistics of an embodiment of the present invention.
To achieve the above object, according to still another aspect of the embodiments of the present invention, there is provided a computer-readable medium on which a computer program is stored, the program, when executed by a processor, implementing the method for iOS crash data classification and statistics of the embodiments of the present invention.
One embodiment of the above invention has the following advantages or benefits: the classification of the crash is more accurate, and the crash which can be automatically classified can be classified into specific reasons. For the problem crash, a stage of manual participation is provided, and the crash is classified iteratively by writing a configuration table. In the multiple crash analysis, the trend change of the crash classification can be given, so that a reference basis is provided for task allocation and repair result verification.
Further effects of the above-mentioned non-conventional alternatives will be described below in connection with the embodiments.
Drawings
The drawings are included to provide a better understanding of the invention and are not to be construed as unduly limiting the invention. Wherein:
FIG. 1 is a block diagram of a system for implementing crash data classification and statistics, according to an embodiment of the invention.
FIG. 2 is a detailed flow diagram of the preliminary classification module according to an embodiment of the present invention.
FIG. 3 is a flow diagram of a recursive classification module according to an embodiment of the invention.
Fig. 4 is a schematic structural diagram of a computer system suitable for implementing the terminal device or the server according to the embodiment of the present application.
Detailed Description
Exemplary embodiments of the present invention are described below with reference to the accompanying drawings, in which various details of embodiments of the invention are included to assist understanding, and which are to be considered exemplary only. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the embodiments described herein can be made without departing from the scope and spirit of the invention. Also, descriptions of well-known functions and constructions are omitted in the following description for clarity and conciseness.
FIG. 1 is a block diagram of a system for implementing crash data classification and statistics, according to an embodiment of the invention.
Referring to FIG. 1, the system includes a preliminary classification module, a recursive classification module, and a report generation module. Each module will be described in detail below.
A preliminary classification module: and the system is responsible for carrying out classification statistics on the crashes which can be classified fully automatically at the place, mainly comprising the crashes (except for main statements) in which code calling statements definitely exist in a calling stack, classifying the crashes at the place and outputting a primary classification report.
A recursive classification module: and continuously iterating and classifying the unclassified crash data through the written configuration file, continuously reducing the unclassified crash proportion, and outputting a recursion classification report form after each iteration.
A report generation module: and integrating and outputting the primary classification report and the recursive classification report, and outputting a final report of the crash analysis in combination with a final report of the last crash analysis.
The pre-operation required for realizing the invention is as follows:
using crashsign translation tools such as ats, Symbolic technology, etc., requires first translating the binary address of the call stack into a visual call statement.
FIG. 2 is a detailed flow diagram of the preliminary classification module according to an embodiment of the present invention.
Referring to fig. 2, the detailed flow of the preliminary classification module is as follows.
First, data is entered, which is the original set of crash data files.
Secondly, invalid data is filtered: invalid crash data is filtered first, and by formatting each crash file into an object, which crash data is not in accordance with the analysis requirements can be effectively checked. For example, the file information is incomplete, the app version not targeted by this analysis crashes, and the like. In addition, other field-specific filter checks may also be performed herein. For example, if a user wishes to analyze only crashes for a particular iOS system version, the program may be expanded at this point, with unspecified versions of crashes being filtered out.
Thirdly, classifying App crash statements: in the step, a crash call stack is read at first, the call stack of the crash thread is traced back, the call stack is searched downwards from the topmost layer, whether a call statement belonging to the own app exists or not is checked, and a regular expression is used for checking whether the call statement conforms to the specification or not. If the statement exists, the statement is extracted to serve as a crash occurrence reason, the class name, the function name and the file function of the statement are extracted to serve as the description of the crash reason, a mapping table for the crash reason and a storage folder is made, and crash data of the same crash reason is placed under the same folder.
An example crash log call stack is given below.
The name of the crash call function (in Jsubpad) is represented in the call stack statement [ JDInviceInfoView controller fillVatInviceView: ]; indicating to which library the calling function belongs; (JDInvocicInfoViewController. m:2106) indicates to which file the calling function belongs. Therefore, it is known from the library name that it is the invocation statement belonging to the app itself, not the system library invocation.
"__exceptionPreprocess(in CoreFoundation_7.1.1)+132",
"objc_exception_throw(in libobjc.A.dylib_7.1.1)+60",
"-[__NSPlaceholderArray initWithObjects:count:](in CoreFoundation_7.1.1)+376",
"+[NSArray arrayWithObjects:count:](in CoreFoundation_7.1.1)+60",
"-[JDInvoiceInfoViewController fillVatInvoiceView:](in Jdipad_3.9.1_8088_AppStore)(JDInvoiceInfoViewController.m:2106)",
"-[JDInvoiceInfoViewController fillContentView](in Jdipad_3.9.1_8088_AppStore)(JDInvoiceInfoViewController.m:0)",
"__46-[JDInvoiceInfoViewController fetchRemoteData]_block_invoke(in Jdipad_3.9.1_8088_AppStore)(JDInvoiceInfoViewController.m:1417)",
"__86-[JDiPadNetworkingInterface
startNetworkingRequest:progress:success:failure:canceled:]_block_invoke_2(in Jdipad_3.9.1_8088_AppStore)(JDiPadNetworkingInterface.m:204)",
"_dispatch_call_block_and_release(in libdispatch.dylib_7.1.1)+24",
"_dispatch_client_callout(in libdispatch.dylib_7.1.1)+16",
"_dispatch_main_queue_callback_4CF(in libdispatch.dylib_7.1.1)+336",
"__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__(in CoreFoundation_7.1.1)+12",
"__CFRunLoopRun(in CoreFoundation_7.1.1)+1452",
"CFRunLoopRunSpecific(in CoreFoundation_7.1.1)+452",
"GSEventRunModal(in GraphicsServices_7.1.1)+168",
"UIApplicationMain(in UIKit_7.1.1)+1156",
"main(in Jdipad_3.9.1_8088_AppStore)(main.m:41)",
"start(in libdyld.dylib_7.1.1)+4"
Fourthly, outputting the result: after the previous steps are completed, outputting a preliminary classification report, wherein the report is a list, the content of each item comprises classified collapse reasons, proportion statistics and folder positions where collapse types are stored, and the classified collapse reasons, the proportion statistics and the folder positions are sorted and output according to the proportion.
After the above steps are completed, the data that has not been filtered or classified is placed in the unclassified folder and indicates the fraction of unclassified crashes, waiting for the recursive matching state to be entered.
FIG. 3 is a detailed flow diagram of the recursive classification module according to an embodiment of the invention.
The detailed flow of the recursive classification module is described below with reference to fig. 3.
The detailed flow of the recursive classification module is as follows:
1. inputting data: and after the preliminary classification is completed, the set of unclassified crash files.
2. Generating a matching rule object list: reading in a configuration file (written by json), converting the configuration file into an object, converting each matching rule into a matching object, forming a matching object list, and delivering the matching object list to a matching manager for management. The basic function of each matching object is to perform regular matching according to the specific field of the configuration, and further support multiple fields and matching and multiple or matching.
3. And circularly reading the crash data, continuously reading the crash data which is not processed, submitting the crash data to a matching manager for matching, and classifying the crash data into a crash folder mapped by a specific matching rule if the crash data can be matched with the specific matching rule. If none match, then put into the unclassified folder.
4. And outputting a result: and after all input data are processed, outputting a result report matched at this time, outputting a report classified by recursion, wherein the report is a list, the content of each item comprises the classified collapse reason, the proportion statistics and the position of a folder stored by the collapse type, and sequencing and outputting according to the proportion. While data that is not filtered or classified is placed in the unclassified folder and indicates the proportion of unclassified crashes.
The following detailed description is made with respect to the way in which the configuration file is written:
1. first, it needs to analyze the crash under the unclassified folder, and after reading a crash file, it will classify the cause of the crash and some identification fields in its crash report indicating its cause.
2. The configuration file itself is a text file in json format and the outermost layer is a list. Each item in the list includes a description of the cause of the crash, a field of crash cause matching rules (supporting regular matching, and supporting the same rule to take effect together to match, and any matching of multiple rules to match). The crash information summarized above is converted into a crash matching rule in the configuration file.
3. The matching rules will now be described in detail: each crash matching item of the json file is a dictionary, each dictionary has a keyword key value and a keyword list key value which respectively correspond to an array, each item in the array is a regular expression character string, all expressions in the keyword array must be satisfied, and at least one expression in the keyword list array must be satisfied. In the call stack of the crash log, each row of call statements is taken as a unit, the search is respectively carried out with the regular expression, and if any call statement in the call stack can search the content of the regular expression, the regular expression is satisfied. In addition, there are some common fields, such as iOSVersionMin and iOSVersionMax, used to indicate the range of system versions that need to be matched; such as exceptinontype, to indicate which type of Exception (a system-supplied value, such as NSGenericException, NSRangeException, NSInvalidArgumentException, …) is specific; for example, signalType, to indicate which type of signal is triggered (system supplied values, such as SEGV, SIGBUS, SIGABRT, …); for these common field matching items, it is only necessary to write "NULL" directly without participating in matching.
4. The reason why this matching table can help classify crashes will be described in detail. Because of the crash due to the same kind of reason, it must be embodied in the call stack. For example, a crash caused by a system cause, the system version of the crash is very concentrated, and then, although the whole call stack may be different, some call statements inside the call stack are overlapped, and these statements are the cause that we think of triggering the crash and are the common characteristics of the call statements. Therefore, after an experienced developer sees crash logs that cannot be automatically classified, some common characteristics can be extracted from the crash logs, and then the crash logs are sequentially configured according to the provided configuration items, so that further classification can be performed on unclassified crash logs.
As a crash reason generally corresponds to a plurality of crash files, the unclassified crash is continuously read, then the configuration file is updated, and then the recursive classification module is executed, so that the unclassified crash files can be reduced once and again. When the unclassified crash data proportion is considered to be in a reasonable position through iteration, the final report can be integrated and output.
The report generation module will be described in detail below:
1. and combining the previous preliminary classification report and the recursive classification report, and outputting a combined report. The report content is divided into two parts:
a) overview of the results: the method comprises the total number and the proportion of the legal breakdown, the classified number and the proportion of the breakdown in the primary classification stage, the classified number and the proportion of the breakdown in the recursive classification stage and the number and the proportion of the breakdown without classification.
b) Crash statistics list: each item of content includes a crash cause, a number of crashes caused by the crash cause, a duty cycle, and a folder location where the crash type is stored. And the entire list is sorted by duty from high to low.
2. Optionally, if the analysis report of the last crash can be read, the crash merged report of this time and the analysis report of the last crash are compared. And (3) performing trend description on the crash proportion of the same reason in the crash statistic lists of the two reports, and directly adding a field to the content item of the crash reason in the crash statistic list to indicate the trend: "new increase" represents that the cause of the crash is a classification newly generated after the crash analysis, "+ xx.xx%" indicates that the proportion of the crash is increased compared to the previous analysis, and further attention needs to be developed, and "— xx.xx%" indicates that the proportion of the crash is decreased compared to the previous analysis.
After the first two steps are completed, the output report is the final crash analysis report.
In the following, the complete classification flow will be described:
1. the crash files are all placed in a specific folder first, and then the preliminary classification script is executed. The crash file at this time must be a file that has undergone symbolization operations, and all call stacks thereof must be visualized code call statements, not binary addresses.
2. A primary classification stage: firstly, all crash logs are checked, and crash logs (format requirements and the like, and users can perform custom expansion) which do not meet requirements are directly deleted. Then, the call stack of each file is searched from the top of the stack to the bottom of the stack, and a first calling statement of the non-system library calling and non-main functions in the stack is found and used as a classification basis for the crash. The crashes that extract the same calling statement need to be classified into one category and stored in the same folder. Finally, the crash which cannot be classified in the above mode is placed in an unclassified folder, and the category of the classification and the proportion of each category are output (the unclassified category also counts as one category).
3. And checking the crash of the unclassified folder, and writing the configuration file according to the [ writing mode of the configuration file ].
4. And executing a recursive classification script, acquiring initial data from the unclassified folder after the last step of preliminary classification, sequentially matching each crash file with each matching table configuration through the written configuration file, classifying the crash log into a crash classification corresponding to the configuration item if the matching is successful, and moving the crash log into a specific classification folder from the unclassified folder (if the classification folder does not exist before, the crash log is newly built and moved into the specific classification folder). And finally, outputting the recursively classified categories and the proportion of each category (the unclassified category also serves as one category).
5. And (4) continuously executing (3) and (4), and integrating and outputting a final report when the crash data ratio under the unclassified folder is in a reasonable position through iteration.
6. And (4) putting the last analysis report result in the current folder, and executing the report generation script to obtain a final crash analysis report.
Referring now to FIG. 4, shown is a block diagram of a computer system 400 suitable for use in implementing a terminal device of an embodiment of the present application. The terminal device shown in fig. 4 is only an example, and should not bring any limitation to the functions and the scope of use of the embodiments of the present application.
As shown in fig. 4, the computer system 400 includes a Central Processing Unit (CPU)401 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)402 or a program loaded from a storage section 408 into a Random Access Memory (RAM) 403. In the RAM 403, various programs and data necessary for the operation of the system 400 are also stored. The CPU 401, ROM 402, and RAM 403 are connected to each other via a bus 404. An input/output (I/O) interface 405 is also connected to bus 404.
The following components are connected to the I/O interface 405: an input section 406 including a keyboard, a mouse, and the like; an output section 407 including a display device such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 408 including a hard disk and the like; and a communication section 409 including a network interface card such as a LAN card, a modem, or the like. The communication section 409 performs communication processing via a network such as the internet. A driver 410 is also connected to the I/O interface 405 as needed. A removable medium 411 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 410 as necessary, so that a computer program read out therefrom is mounted into the storage section 408 as necessary.
In particular, according to the embodiments of the present disclosure, the processes described above with reference to the flowcharts may be implemented as computer software programs. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable medium, the computer program comprising program code for performing the method illustrated in the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 409, and/or installed from the removable medium 411. The above-described functions defined in the system of the present application are executed when the computer program is executed by a Central Processing Unit (CPU) 401.
It should be noted that the computer readable medium shown in the present application may be a computer readable signal medium or a computer readable storage medium or any combination of the two. A computer readable storage medium may be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination of the foregoing. More specific examples of the computer readable storage medium may include, but are not limited to: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a Random Access Memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination of the foregoing. In the present application, a computer readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device. In this application, however, a computer readable signal medium may include a propagated data signal with computer readable program code embodied therein, for example, in baseband or as part of a carrier wave. Such a propagated data signal may take many forms, including, but not limited to, electro-magnetic, optical, or any suitable combination thereof. A computer readable signal medium may also be any computer readable medium that is not a computer readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device. Program code embodied on a computer readable medium may be transmitted using any appropriate medium, including but not limited to: wireless, wire, fiber optic cable, RF, etc., or any suitable combination of the foregoing.
The flowchart and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods and computer program products according to various embodiments of the present application. In this regard, each block in the flowchart or block diagrams may represent a module, segment, or portion of code, which comprises one or more executable instructions for implementing the specified logical function(s). It should also be noted that, in some alternative implementations, the functions noted in the block may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order, depending upon the functionality involved. It will also be noted that each block of the block diagrams or flowchart illustration, and combinations of blocks in the block diagrams or flowchart illustration, can be implemented by special purpose hardware-based systems which perform the specified functions or acts, or combinations of special purpose hardware and computer instructions.
The "module" referred to in the embodiments of the present application may be implemented by software or hardware. The described "module" may also be provided in the processor, and may be described as: a processor includes a preliminary classification module, a recursive classification module, and a report generation module. The names of these modules do not in some cases constitute a limitation on the module itself, for example, a recursive classification module may also be described as a module that iteratively classifies unclassified crash data through a written configuration file and outputs a recursive classification report after each iteration.
As another aspect, the present application also provides a computer-readable medium, which may be contained in the apparatus described in the above embodiments; or may be separate and not incorporated into the device. The computer readable medium bears one or more programs, when the one or more programs are executed by the equipment, the equipment automatically classifies crash data, extracts call statements belonging to the application program in the whole call stack by adopting a call stack reverse search mode, and outputs a primary classification report; through the written configuration file, continuously performing iterative classification on the unclassified crash data, and outputting a recursive classification report after each iteration; and integrating the preliminary classification report and the recursion classification report, and combining the final report of the last crash analysis to output the final report of the crash analysis.
According to the technical scheme of the embodiment of the invention, the breakdown is more accurately classified, and the breakdown capable of being automatically classified is ensured to be classified into specific reasons. For the problem crash, a stage of manual participation is provided, and the crash is classified iteratively by writing a configuration table. In the multiple crash analysis, the trend change of the crash classification can be given, so that a reference basis is provided for task allocation and repair result verification.
The above-described embodiments should not be construed as limiting the scope of the invention. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions can occur, depending on design requirements and other factors. Any modification, equivalent replacement, and improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims (12)

1. A method for iOS crash data classification and statistics, the method comprising:
automatically classifying the crash data, extracting calling sentences belonging to application programs in the whole call stack by adopting a call stack reverse searching mode, and outputting a preliminary classification report;
through the written configuration file, continuously performing iterative classification on the unclassified crash data, and outputting a recursive classification report after each iteration; the continuously iteratively classifying unclassified crash data through the written configuration file comprises the following steps: converting the written configuration file into an object, converting each matching rule into a matching object, forming a matching object list, and managing the matching object list by a matching manager; and
and integrating the preliminary classification report and the recursion classification report, and combining the final report of the last crash analysis to output the final report of the crash analysis.
2. The method of claim 1, further comprising: and extracting the class name, the function name and the file function of the calling statement as the description of the crash reason, making a mapping table of the crash reason and a storage folder, and putting the crash data of the same crash reason into the same folder.
3. The method of claim 1, wherein: the basic function of the matching object is to perform regular matching according to the configured specific field and support multiple fields and matching and multiple or matching.
4. The method of claim 1, wherein: each item of content of the preliminary classification report comprises: the classified crash reasons, the duty statistics, and the folder location where the crash type is stored.
5. The method of claim 1, wherein: the final report content includes: the result overview comprises the total number and the proportion of the legal crashes, the number and the proportion of the crashes classified in the primary classification stage, the number and the proportion of the crashes classified in the recursive classification stage and the number and the proportion of the unclassified crashes, each item of content of the crash statistics list comprises the crash reasons, the number and the proportion of the crashes caused by the crash reasons and the positions of folders stored by the crash types, and the crash statistics list is sorted from high to low according to the proportion.
6. An apparatus for iOS crash data classification and statistics, the apparatus comprising:
the initial classification module is used for automatically classifying the crash data, extracting calling sentences belonging to the application program in the whole call stack by adopting a call stack reverse searching mode, and outputting an initial classification report;
the recursive classification module continuously carries out iterative classification on the unclassified crash data through the written configuration file and outputs a recursive classification report after each iteration; the continuously iteratively classifying unclassified crash data through the written configuration file comprises the following steps: converting the written configuration file into an object, converting each matching rule into a matching object, forming a matching object list, and managing the matching object list by a matching manager; and
and the report generation module integrates the primary classification report and the recursive classification report and outputs a final report of the crash analysis in combination with a final report of the last crash analysis.
7. The apparatus of claim 6, wherein the preliminary classification module extracts the class name, function name, and file function of the calling statement as descriptions of crash reasons, creates a mapping table between the crash reasons and a storage folder, and places crash data of the same crash reason in the same folder.
8. The apparatus of claim 6, wherein: the basic function of the matching object is to perform regular matching according to the configured specific field and support multiple fields and matching and multiple or matching.
9. The apparatus of claim 6, wherein: each item of content of the preliminary classification report comprises: the classified crash reasons, the duty statistics, and the folder location where the crash type is stored.
10. The apparatus of claim 6, wherein: the final report content includes: the result overview comprises the total number and the proportion of the legal crashes, the number and the proportion of the crashes classified in the primary classification stage, the number and the proportion of the crashes classified in the recursive classification stage and the number and the proportion of the unclassified crashes, each item of content of the crash statistics list comprises the crash reasons, the number and the proportion of the crashes caused by the crash reasons and the positions of folders stored by the crash types, and the crash statistics list is sorted from high to low according to the proportion.
11. An electronic device for iOS crash data classification and statistics, comprising:
one or more processors;
a storage device for storing one or more programs,
when executed by the one or more processors, cause the one or more processors to implement the method of any one of claims 1-5.
12. A computer-readable medium, on which a computer program is stored, which, when being executed by a processor, carries out the method according to any one of claims 1-5.
CN201710232014.XA 2017-04-11 2017-04-11 iOS crash data classification and statistics method and device Active CN108694108B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201710232014.XA CN108694108B (en) 2017-04-11 2017-04-11 iOS crash data classification and statistics method and device

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201710232014.XA CN108694108B (en) 2017-04-11 2017-04-11 iOS crash data classification and statistics method and device

Publications (2)

Publication Number Publication Date
CN108694108A CN108694108A (en) 2018-10-23
CN108694108B true CN108694108B (en) 2021-09-07

Family

ID=63843486

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201710232014.XA Active CN108694108B (en) 2017-04-11 2017-04-11 iOS crash data classification and statistics method and device

Country Status (1)

Country Link
CN (1) CN108694108B (en)

Families Citing this family (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN109815152A (en) * 2019-01-31 2019-05-28 科大讯飞股份有限公司 Program crashing type prediction method and system
CN110489345B (en) * 2019-08-08 2023-08-25 北京字节跳动网络技术有限公司 Crash aggregation method, device, medium and equipment
CN110647472A (en) * 2019-09-27 2020-01-03 北京博睿宏远数据科技股份有限公司 Breakdown information statistical method and device, computer equipment and storage medium
CN110865898B (en) * 2019-10-12 2023-09-05 北京字节跳动网络技术有限公司 Method, device, medium and equipment for converging crash call stack
CN111782504B (en) * 2020-05-20 2023-12-01 车智互联(北京)科技有限公司 Application program abnormality diagnosis method, mobile terminal and readable storage medium

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8479051B2 (en) * 2009-01-23 2013-07-02 Microsoft Corporation System and method for customized error reporting
US8694831B2 (en) * 2009-05-29 2014-04-08 Red Hat, Inc. Automatic bug reporting tool
CN101944059A (en) * 2010-08-20 2011-01-12 北京神州泰岳软件股份有限公司 Automatic analysis method and device of crash information of computer software
CN103034575B (en) * 2012-11-29 2015-08-19 北京奇虎科技有限公司 Collapse analytical approach and device
CN105630682A (en) * 2015-12-28 2016-06-01 珠海金山网络游戏科技有限公司 System and method for automatically collecting and analyzing collapse of mobile terminal

Also Published As

Publication number Publication date
CN108694108A (en) 2018-10-23

Similar Documents

Publication Publication Date Title
CN108694108B (en) iOS crash data classification and statistics method and device
US8887135B2 (en) Generating test cases for functional testing of a software application
AU2009238294B2 (en) Data transformation based on a technical design document
US9122540B2 (en) Transformation of computer programs and eliminating errors
US20150324246A1 (en) Correlation of source code with system dump information
US20240078168A1 (en) Test Case Generation Method and Apparatus and Device
CN108536745B (en) Shell-based data table extraction method, terminal, equipment and storage medium
CN115061721A (en) Report generation method and device, computer equipment and storage medium
CN114328276B (en) Test case generation method and device, and test case display method and device
CN109872230B (en) Test method and device of financial data analysis system, medium and electronic equipment
US20210012219A1 (en) Dynamic generation of rule and logic statements
CN111736865B (en) Database upgrading method and system
CN111488314A (en) Simulation log analysis method based on Python
CN110688096A (en) Method, device, medium and electronic equipment for constructing application program containing plug-in
US20160132809A1 (en) Identifying and amalgamating conditional actions in business processes
CN111831536A (en) Automatic testing method and device
EP3889770A1 (en) Mini program material processing method and apparatus, electronic device, and medium
US20160292067A1 (en) System and method for keyword based testing of custom components
CN111858366A (en) Test case generation method, device, equipment and storage medium
CN116775488A (en) Abnormal data determination method, device, equipment, medium and product
CN110716866A (en) Code quality scanning method and device, computer equipment and storage medium
CN113138974B (en) Method and device for detecting database compliance
CN111221698A (en) Task data acquisition method and device
CN113672512A (en) Code inspection rule generating method, code inspection method, device and medium
US9275358B1 (en) System, method, and computer program for automatically creating and submitting defect information associated with defects identified during a software development lifecycle to a defect tracking system

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