CN111258802A - Method for capturing application program crash information and related equipment - Google Patents
Method for capturing application program crash information and related equipment Download PDFInfo
- Publication number
- CN111258802A CN111258802A CN202010083965.7A CN202010083965A CN111258802A CN 111258802 A CN111258802 A CN 111258802A CN 202010083965 A CN202010083965 A CN 202010083965A CN 111258802 A CN111258802 A CN 111258802A
- Authority
- CN
- China
- Prior art keywords
- file
- crash
- crash information
- folder
- information
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error 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/0766—Error or fault reporting or storing
- G06F11/0778—Dumping, i.e. gathering error/state information after a fault for later diagnosis
-
- G—PHYSICS
- G06—COMPUTING OR CALCULATING; COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/0703—Error 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/079—Root cause analysis, i.e. error or fault diagnosis
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Health & Medical Sciences (AREA)
- Biomedical Technology (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Debugging And Monitoring (AREA)
Abstract
The disclosure provides a method and a device for capturing application program crash information, a computer readable storage medium and an electronic device. The method comprises the following steps: when detecting that the application program has local crash, writing the crash information of the local crash into a dump file; intercepting crash information written into the dump file, and storing character strings of the crash information into a predefined global variable; generating a readable file of the crash information according to the character strings in the predefined global variables; and uploading the readable file of the crash information to a server so that the server can locate and analyze the local crash of the application program according to the readable file of the crash information. By the technical scheme provided by the embodiment of the disclosure, the efficiency of local crash positioning can be improved, and the consumption of computing resources of the server side is reduced.
Description
Technical Field
The present disclosure relates to the field of computer technologies, and in particular, to a method and an apparatus for capturing application crash information, a computer-readable storage medium, and an electronic device.
Background
With the development of computer applications, various computer application programs for users are coming out endlessly. However, in the running process of the application program, a program crash phenomenon sometimes occurs, and a great loss is caused to the system no matter the pointer is out of range or illegal operation is performed. However, during the testing of a large system, it seems inevitable that a program crash will occur in the early stages.
Therefore, a technical solution for recording the reason of product crash when the application program crashes is needed to facilitate the product developer to locate the error code of the program in time and improve the quality of the code and the stability of the product is needed.
It is to be noted that the information disclosed in the above background section is only for enhancement of understanding of the background of the present disclosure, and thus may include information that does not constitute prior art known to those of ordinary skill in the art.
Disclosure of Invention
An object of the embodiments of the present disclosure is to provide a method, an apparatus, a computer-readable storage medium, and an electronic device for capturing application crash information, so as to overcome at least a problem of low efficiency in locating application crashes in the related art to a certain extent.
Additional features and advantages of the disclosure will be set forth in the detailed description which follows, or in part will be obvious from the description, or may be learned by practice of the disclosure.
According to an aspect of the embodiments of the present disclosure, a method for capturing application crash information is provided, which includes: when detecting that the application program has local crash, writing the crash information of the local crash into a dump file; intercepting crash information written into the dump file, and storing character strings of the crash information into a predefined global variable; generating a readable file of the crash information according to the character strings in the predefined global variables; and uploading the readable file of the crash information to a server so that the server can locate and analyze the local crash of the application program according to the readable file of the crash information.
According to an aspect of the embodiments of the present disclosure, there is provided an apparatus for capturing application crash information, including: the crash information writing unit is used for writing the crash information which is locally crashed into a dump file when the application program is detected to be locally crashed; a crash information intercepting unit for intercepting crash information written in the dump file and storing a character string of the crash information into a predefined global variable; the readable file generating unit is used for generating a readable file of the crash information according to the character strings in the predefined global variables; and the readable file uploading unit is used for uploading the readable file of the crash information to a server so as to facilitate the server to locate and analyze the local crash of the application program according to the readable file of the crash information.
According to an aspect of the embodiments of the present disclosure, there is provided a computer-readable storage medium, on which a computer program is stored, which when executed by a processor, implements the method of capturing application crash information as described in the above embodiments.
According to an aspect of the embodiments of the present disclosure, there is provided an electronic device including: one or more processors; a storage device for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of capturing application crash information as described in the above embodiments.
In the technical solutions provided by some embodiments of the present disclosure, a manner capable of capturing a native (native) layer crash is provided, where a locally generated crash file (when it is detected that the application program has a local crash, crash information that the local crash occurs is written into the dump file) is intercepted, a local direct parsing is performed (the crash information to be written into the dump file is intercepted, a character string of the crash information is saved in a predefined global variable; a readable file of the crash information is generated according to the character string in the predefined global variable), a readable file of the crash information of the local crash is locally generated, the readable file includes readable and directly viewable character string information, so that the character string information uploaded to a server is directly viewable, and the server is prevented from executing a large number of executable files to parse the dump file (dump file), on one hand, the dump file is locally analyzed in one step, and the dump file does not need to be uploaded to a server; on the other hand, the consumption of a Central Processing Unit (CPU) and a memory space of the server can be reduced, which is beneficial for the server to quickly and timely locate and analyze the local collapse of the application program so as to improve the application program.
It is to be understood that both the foregoing general description and the following detailed description are exemplary and explanatory only and are not restrictive of the disclosure.
Drawings
The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and together with the description, serve to explain the principles of the disclosure. It is to be understood that the drawings in the following description are merely exemplary of the disclosure, and that other drawings may be derived from those drawings by one of ordinary skill in the art without the exercise of inventive faculty. In the drawings:
FIG. 1 illustrates a schematic diagram of an exemplary system architecture to which a method of capturing application crash information or an apparatus for capturing application crash information of embodiments of the present disclosure may be applied;
FIG. 2 illustrates a schematic structural diagram of a computer system suitable for use with the electronic device used to implement embodiments of the present disclosure;
FIG. 3 schematically illustrates a flow diagram of a method of capturing application crash information, in accordance with an embodiment of the present disclosure;
FIG. 4 schematically illustrates a diagram of a method of capturing application crash information, in accordance with an embodiment of the present disclosure;
FIG. 5 schematically illustrates a flow diagram of a method of capturing application crash information, in accordance with an embodiment of the present disclosure;
FIG. 6 schematically illustrates a flow diagram of a method of capturing application crash information, in accordance with an embodiment of the present disclosure;
FIG. 7 schematically illustrates a block diagram of an apparatus to capture application crash information according to one embodiment of the present disclosure.
Detailed Description
Example embodiments will now be described more fully with reference to the accompanying drawings. Example embodiments may, however, be embodied in many different forms and should not be construed as limited to the examples set forth herein; rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the concept of example embodiments to those skilled in the art.
Furthermore, the described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments. In the following description, numerous specific details are provided to give a thorough understanding of embodiments of the disclosure. One skilled in the relevant art will recognize, however, that the subject matter of the present disclosure can be practiced without one or more of the specific details, or with other methods, components, devices, steps, and so forth. In other instances, well-known methods, devices, implementations, or operations have not been shown or described in detail to avoid obscuring aspects of the disclosure.
The block diagrams shown in the figures are functional entities only and do not necessarily correspond to physically separate entities. I.e. these functional entities may be implemented in the form of software, or in one or more hardware modules or integrated circuits, or in different networks and/or processor means and/or microcontroller means.
The flow charts shown in the drawings are merely illustrative and do not necessarily include all of the contents and operations/steps, nor do they necessarily have to be performed in the order described. For example, some operations/steps may be decomposed, and some operations/steps may be combined or partially combined, so that the actual execution sequence may be changed according to the actual situation.
FIG. 1 illustrates a schematic diagram of an exemplary system architecture 100 to which the method of capturing application crash information or the apparatus for capturing application crash information of embodiments of the present disclosure may be applied.
As shown in fig. 1, the system architecture 100 may include one or more of terminal devices 101, 102, 103, a network 104, and a server 105. The network 104 serves as a medium for providing communication links between the terminal devices 101, 102, 103 and the server 105. Network 104 may include various connection types, such as wired, wireless communication links, or fiber optic cables, to name a few.
It should be understood that the number of terminal devices, networks, and servers in fig. 1 is merely illustrative. There may be any number of terminal devices, networks, and servers, as desired for implementation. For example, the server 105 may be a server cluster composed of a plurality of servers, a cloud server, or the like.
The user may use the terminal devices 101, 102, 103 to interact with the server 105 via the network 104 to receive or send messages or the like. The terminal devices 101, 102, 103 may be various electronic devices having a display screen, including but not limited to smart phones, tablet computers, portable computers, wearable smart devices, smart home devices, desktop computers, and the like.
When the terminal device 101 (which may also be the terminal device 102 or 103) detects that the application program installed thereon is locally crashed, writing crash information of the locally crashed application program into a dump file; intercepting crash information written into the dump file, and storing character strings of the crash information into a predefined global variable; generating a readable file of the crash information according to the character strings in the predefined global variables; the terminal device 101 may also upload the readable file of the crash information to the server 105, and the server 105 may locate and analyze the local crash of the application according to the readable file of the crash information. The server 105 may be a server that provides various services.
FIG. 2 illustrates a schematic structural diagram of a computer system suitable for use in implementing the electronic device of an embodiment of the present disclosure.
It should be noted that the computer system 200 of the electronic device shown in fig. 2 is only an example, and should not bring any limitation to the functions and the scope of the application of the embodiments of the present disclosure.
As shown in fig. 2, the computer system 200 includes a Central Processing Unit (CPU)201 that can perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)202 or a program loaded from a storage section 208 into a Random Access Memory (RAM) 203. In the RAM 203, various programs and data necessary for system operation are also stored. The CPU201, ROM202, and RAM 203 are connected to each other via a bus 204. An input/output (I/O) interface 205 is also connected to bus 204.
The following components are connected to the I/O interface 205: an input portion 206 including a keyboard, a mouse, and the like; an output section 207 including a display such as a Cathode Ray Tube (CRT), a Liquid Crystal Display (LCD), and the like, and a speaker; a storage section 208 including a hard disk and the like; and a communication section 209 including a network interface card such as a LAN card, a modem, or the like. The communication section 209 performs communication processing via a network such as the internet. A drive 210 is also connected to the I/O interface 205 as needed. A removable medium 211 such as a magnetic disk, an optical disk, a magneto-optical disk, a semiconductor memory, or the like is mounted on the drive 210 as necessary, so that a computer program read out therefrom is mounted into the storage section 208 as necessary.
In particular, the processes described below with reference to the flowcharts may be implemented as computer software programs, according to embodiments of the present disclosure. For example, embodiments of the present disclosure include a computer program product comprising a computer program embodied on a computer readable storage medium, the computer program containing program code for performing the method illustrated by the flow chart. In such an embodiment, the computer program may be downloaded and installed from a network through the communication section 209 and/or installed from the removable medium 211. The computer program executes various functions defined in the system of the present application when executed by a Central Processing Unit (CPU) 201.
It should be noted that the computer readable storage medium shown in the present disclosure 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 disclosure, 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 contrast, in the present disclosure, 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 storage 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 storage 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 disclosure. 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 units described in the embodiments of the present disclosure may be implemented by software, or may be implemented by hardware, and the described units may also be disposed in a processor. Wherein the names of the elements do not in some way constitute a limitation on the elements themselves.
As another aspect, the present application also provides a computer-readable storage medium, which may be included in the electronic device described in the above embodiments; or may exist separately without being assembled into the electronic device. The computer-readable storage medium carries one or more programs which, when executed by an electronic device, cause the electronic device to implement the method as described in the embodiments below. For example, the electronic device may implement the steps shown in fig. 3, 4 or 5.
Android is divided into 4 layers: java application program, Java framework, native framework (native layer), Java running environment and Linux kernel space. These layers are roughly so distinguished:
java applications are basically understood as individual APPs (applications), implemented in the Java language. The Java Framework layer is a Framework layer which is often called, and normal identification and action can be realized by writing Android codes, and the support of the Java Framework layer is required.
The native layer part commonly comprises some local services, some link libraries and the like. One feature of this layer is the implementation in C and C + +. For example, we need to execute a complex operation, if the complex operation is implemented by Java code, the efficiency is very low, and at this time, the complex operation can be implemented by C or C + + code and then communicate with the upper layer Java code (this part is called as JNI (Java Native Interface) mechanism in Android). This is because Java is an interpreted language meaning that it will be "translated" into binary form when executed, whereas C and C + + languages are compiled languages meaning that programs can only be compiled and run on a specific operating system, that is, one step into machine language, and therefore their software runs faster and can directly cooperate with computer memory, disk, CPU, or other devices. And if the device needs to operate, the device must interact with the hardware driver at the bottom layer and also passes through a Native layer.
As the name implies, the Linux Kernel space is the Kernel part.
When a program runs, some abnormal situations are difficult to avoid, and particularly when conditions do not allow to hang up a debugger, a method for quickly positioning errors is important.
Crash (crash) on Android can be divided into two categories:
1、Java Crash
the Java code causes jvm (Java Virtual Machine) to exit, pops up a "program crashed" dialog box, and the end user clicks closed and then the program exits. Logcat (which is a command line tool in Android and can be used to obtain log information of an application) outputs a Java call stack under the "Android runtime" tag.
2. Native Crash (local collapse)
In C and C + + programming practice, common C/C + + problems of memory access invalidation, invalid objects, stack overflow, null pointer invocation, etc. are commonly encountered, and these problems eventually result in: the system crashes, which is referred to as a local crash.
In the Android platform, the crash (collapse) problem of the Android JNI layer is a relatively headache problem in the development process. The problem of localization is a difficult matter compared to the Java layer, because the C/C + + caused crash does not output an Exception string like Java. Meanwhile, Native coast has the characteristics of incomplete context, fuzzy error information, difficulty in capturing and the like, and is more difficult to repair than Java coast.
In addition, after the Android Application is developed, crashes often occur, but the crashes occur at a mobile terminal of a user, such as a mobile phone, and the information needs to be collected to analyze a code segment of the Application that crashes to improve the Application, but the mobile phone crash information is usually output in a log cat, and the information systems do not provide a corresponding API (Application Programming Interface) to obtain the information, so that a method for collecting log information of the crashes is needed, and the information is uploaded to a server to facilitate analysis by a developer.
In the related art, at least the following technical problems exist: firstly, a client cannot analyze logs, but uploads a locally generated crash information file (such as a 16-system dump file) which cannot be directly checked to a server for analysis, so that the server needs to compile and then generate an executable file, then executes the executable file to analyze the crash information file once again to see abnormal plaintext information, and the server needs to run a process every time the server analyzes the crash information file, which greatly consumes the memory and CPU resources of the server, thereby causing low analysis and positioning efficiency of the server, failing to position a code position where a problem occurs, and failing to improve an application program in time; secondly, the method is realized by self-defining and intercepting the crash signals, and the compatibility is poor. If the program is abnormal, a Signal, namely a Linux Signal, is sent to the system, and the Linux Signal is intercepted to process abnormal information, although the information can also be collected, the application program stability is reduced due to the interception of the system Signal.
Based on the above problem, in an embodiment of the present disclosure, a method for capturing application crash information is provided to optimize the above problem. Specifically referring to fig. 3, the method for capturing application crash information is applicable to the electronic device described in the foregoing embodiment, and may include steps S310 to S340:
in step S310, when detecting that the application program has a local crash, writing crash information of the local crash into a dump file.
The application program in the embodiment of the disclosure uses C/C + + to develop partial modules of APP. When the application program generates a native case, the dmp file is used as a dump file, so that the crash information of the native case is written into the dump file, and the generally 16-system unreadable data in the dump file is stored.
In step S320, the crash information written in the dump file is intercepted, and the character string of the crash information is saved in a predefined global variable.
In the embodiment of the present disclosure, the character strings in the crash information may be saved in the predefined global variable by intercepting the crash information to be written in the dump file.
In step S330, a readable file of the crash information is generated according to the character string in the predefined global variable.
In the embodiment of the present disclosure, the readable file of the crash information may be generated according to the character string saved in the predefined global variable.
In step S340, the readable file of the crash information is uploaded to a server, so that the server locates and analyzes the local crash of the application program according to the readable file of the crash information.
During APP operation, a large amount of crash information is stored locally, but this information is often needed to analyze where the code is in error. In the embodiment of the disclosure, the readable file capable of collecting the crash information is uploaded to the server background for analysis.
According to the method for capturing the crash information of the application program provided by the embodiment of the disclosure, a manner capable of capturing a native (native) layer crash is provided, by intercepting a locally generated crash file (when the application program is detected to have a local crash, the crash information of the local crash is written into the crash file), locally and directly analyzing (intercepting the crash information to be written into the crash file, storing a character string of the crash information into a predefined global variable; generating a readable file of the crash information according to the character string in the predefined global variable), locally generating a readable file of the crash information of the local crash, wherein the readable file comprises readable and directly viewable character string information, so that the character string information is uploaded to a server, the server can directly view the character string information, and the server is prevented from executing a large number of executable files to analyze the crash file (dufile), on one hand, the dump file is locally analyzed in one step, and the dump file does not need to be uploaded to a server; on the other hand, the consumption of a Central Processing Unit (CPU) and a memory space of the server can be reduced, which is beneficial for the server to quickly and timely locate and analyze the local collapse of the application program so as to improve the application program.
FIG. 4 schematically shows a schematic diagram of a method of capturing application crash information according to an embodiment of the disclosure.
After an application is developed and built, various crashes often occur, and this information is important for analyzing the improved APP and needs to be captured. As shown in fig. 4, taking breakpa as an example to illustrate how to achieve the purpose of obtaining the native layer crash information, the method may include the following steps: firstly, integrating Breakpa source codes into an APP application program; secondly, transplanting a Breakpad parser into the android application program; thirdly, when the APP breaks down, the break file is locally analyzed on the client side by using Breakpa to generate a readable file of the break information; and fourthly, uploading the analyzed file content to a server.
The Breakpa is a cross-platform open source library, and can be used for collecting native coast logs. Breakpad is a complete set of tools, and provides corresponding tools from the capture of crash to the dump of crash.
When breaking pad is integrated, the related art is that a dump file of crash information is generated at a client and then uploaded to a server, and the crash information is analyzed at the server once again, so that the purpose of checking the crash information can be completed by 3 steps in total. By adopting the method provided by the embodiment of the disclosure, the local analysis can be directly realized, the process of analyzing the file once by the server after uploading the file to the server is omitted, and the server executes a large number of executable programs to analyze the file cannot be in place in one step, so that a large number of server resources are consumed.
This is illustrated below in connection with the embodiments of fig. 5 and 6.
FIG. 5 schematically shows a flow diagram of a method of capturing application crash information according to an embodiment of the disclosure.
As shown in fig. 5, compared with the above embodiment, the method provided by the embodiment of the present disclosure may further include the following steps.
In step S510, source code files of a crash capture tool (here, each exemplified by a break pad) are obtained, which include a Client (Client) folder, a Common (Common) folder, a parser (processor) folder, and a crash capture tool (google _ break) folder.
Breakpad is a set of cross-platform crash dump and analysis framework tools. The Client folder is a directory in the Breakpa source code and mainly used for receiving an exception signal and acquiring corrupted stack information. Common folder is also a directory in Breakpa, and is a tool for converting character strings and reading and writing memory. The processor may be used to generate a readable C/C + + Stack trace.
In step S520, the client folder, the generic folder, the parser folder, and the crash capture tool folder are copied to a JAVA Native Interface (JNI) directory of the application program, where the parser folder includes a migration file of a parser.
When the JNI needs to be used, a native project needs to be created. The creation mode has two modes: manually creating a directory call JNI in the project root directory, creating an android.mk in the directory, then creating c, cpp files, and configuring the c, cpp files into the android.mk; and (5) right-key engineering, and selecting Android Tools- > Add Native Support to automatically generate.
In step S530, a file in the JAVA local interface directory is added to a build configuration file (e.g., android.
In the development process, files to be compiled are configured in android. Mk is a makefile configuration file (build configuration file). The source files in a project are respectively placed in a plurality of directories according to types, functions and modules, makefile defines a series of rules to specify which files need to be compiled first, which files need to be compiled later and which files need to be recompiled, and even more complex functional operations are carried out, because makefile can execute the commands of an operating system just like a Shell script.
Downloading the Breakpad source code, copying 4 folders of client, common, processor and google _ Breakpad under the source code path, and adding the Breakpad source code file into the android. The embodiment of the present disclosure is different from the related art, and the related art only needs to add the collected abnormal information file in the android.
FIG. 6 schematically shows a flow diagram of a method of capturing application crash information, according to an embodiment of the disclosure.
As shown in fig. 6, compared with the above embodiment, the method provided by the embodiment of the present disclosure may further include the following steps.
In step S610, an initialization class (minimumpdescriptor, which is a C + + class used for initializing a running program) defined in the crash capture tool folder is called for initialization, and a callback function when the local crash occurs to the application program is written, so that when the local crash occurs to the application program is detected, the crash information of the local crash is written into a dump file.
When the APP is started, Breakpad is initialized, and after initialization configuration, crash information of a native layer can be captured.
First, according to the embodiment of fig. 5, the break source code is integrated into the android application program, and then initialized when the APP is initialized, a path for saving the dump file (a directory where the dump file is stored is predefined) is set, and a constructor of the google _ break: minimumpdescriptor can be called to set.
For example, initialization may be invoked where the APP initializes, using the following code:
google_breakpad::MinidumpDescriptor descriptor(path)；
static google_breakpad::ExceptionHandler eh(descriptor,NULL,DumpCallback,NULL,true,-1)；
so far, the integration Breakpad is completed.
And secondly, when the application program is crashed, a dump file is generated and written into the directory set in the first step, the file is a 16-system unreadable file and cannot be checked, and in the past, the file needs to be uploaded to a server, and the server executes an executable file to convert the file into a character string before checking. In the embodiment of the present disclosure, the generated dump file after the improvement is not uploaded to the server, and the next step is continuously executed.
In step S620, the resolver directory is copied to the JAVA local interface directory using the migration file of the resolver.
And then, transplanting the analyzed dump code to a JNI directory, wherein an executable file is generated after the module is compiled originally and needs to be run on a server. This part of the code exists in the breakpoint pad, which is actually a file in the processor directory
In step S630, a file in the directory of the parser is added to the build configuration file.
In step S640, the print function is found in the exception information storage processing file (stackwalk _ common.cc file) under the directory of the parser.
In step S650, the print function is modified to intercept the crash information written in the dump file, and save the character string of the crash information into a predefined global variable.
The specific operation is that the part of code for parsing the dump is added to android.mk for compiling, then when the dump generates file information, SetupOptions and printMinidumpLock of a parser are called to parse the dump file, so that the call stack information reporting errors can be generated and parsed at the client, and the name of a certain function can be specified, wherein the call stack information can be stored by using std:: vector < std:: string >, which is a predefined global variable.
In step S660, a splicing function is written to generate a readable file of the crash information according to the character string in the predefined global variable.
And (4) analyzing all the global variables in the steps into character strings in a traversal mode, and then transmitting the character strings to the server.
For example, a specific migration step may include, after integrating BreakPad in APP:
firstly, copying a processor to a source code directory, and then adding a source code file into android.
Then, 8 print functions of PrintProcessState, printprocessstatemachien readable, printmodulememachien readable, PrintModule, printstackmachien readable, PrintStackContents and PrintRegister are found in the stackwalk _ common.cc file under the processor directory, and are respectively modified, because the clearpad is taken from the printf output information when the dump file is converted, the character string formatting is saved in the predefined global variable when the printf function is called.
And then, adding a splicing function, splicing the predefined global variables to obtain the crashed abnormal information as a final output result. The modified printing function collects the plaintext character string of the crash information, and the readable file of the crash information is obtained by calling the written splicing function.
In an exemplary embodiment, the method may further include: the unit test files (googletest) in the parser framework are removed. Here, the google test code in the processor is removed, and about 10 files related to the google tset are obtained, and the file name is associated with unit test.
Finally, the obtained analyzed character strings are uploaded to a server, a whole dump file needs to be uploaded in the related technology, and only one character string needs to be uploaded, so that the data transmission quantity between the client and the server can be reduced, the uploading speed of the crash information can be increased, and the server can be favorably and quickly locate the position and the reason of the problem.
According to the method for capturing the crash information of the application program, provided by the embodiment of the disclosure, by modifying the source code of the breakpad and adding the function calling function, the crash information can be directly analyzed at the client, a module specially used for uploading the dump file is not required to be developed to upload the dump file to the server, the dump file is not required to be analyzed again at the server, the cause of the crash can be conveniently found, and the problem can be timely analyzed and early found.
Embodiments of the disclosed apparatus are described below, which may be used to perform the above-described method for capturing application crash information. For details not disclosed in the embodiments of the apparatus of the present disclosure, please refer to the embodiments of the method for capturing crash information of an application described above in the present disclosure.
FIG. 7 schematically illustrates a block diagram of an apparatus to capture application crash information according to one embodiment of the present disclosure.
Referring to fig. 7, an apparatus 700 for capturing application crash information according to an embodiment of the present disclosure may include: a crash information writing unit 710, a crash information intercepting unit 720, a readable file generating unit 730, and a readable file uploading unit 740.
Specifically, the crash information writing unit 710 may be configured to write the crash information of the local crash into the dump file when detecting that the local crash of the application program occurs.
The crash information intercepting unit 720 may be configured to intercept crash information written to the dump file, and save a string of the crash information to a predefined global variable.
The readable file generating unit 730 may be configured to generate a readable file of the crash information according to the character string in the predefined global variable.
The readable file uploading unit 740 can be configured to upload the readable file of the crash information to the server, so that the server can locate and analyze the local crash of the application according to the readable file of the crash information.
In an exemplary embodiment, the apparatus 700 for capturing application crash information may further include: the source code file acquisition unit can be used for acquiring a source code file of the crash capture tool, and the source code file acquisition unit comprises a client folder, a general folder, a parser folder and a crash capture tool folder; the file folder copying unit can be used for copying the client file folder, the general file folder, the resolver file folder and the crash capture tool file folder to a JAVA local interface directory of the application program, wherein the resolver file folder comprises a migration file of a resolver; and the file adding configuration unit can be used for adding the files in the JAVA local interface directory into the construction configuration file.
In an exemplary embodiment, the apparatus 700 for capturing application crash information may further include: and the initialization unit can be used for calling the initialization class defined in the crash capture tool folder for initialization, and writing a callback function when the local crash occurs to the application program, so that when the local crash occurs to the application program is detected, the crash information of the local crash is written into a dump file.
In an exemplary embodiment, the apparatus 700 for capturing application crash information may further include: the resolver directory copying unit can be used for copying the directory of the resolver to the JAVA local interface directory by using the migration file of the resolver; and the parser file adding configuration unit can be used for adding the file in the directory of the parser in the building configuration file.
In an exemplary embodiment, the apparatus 700 for capturing application crash information may further include: the printing function searching unit can be used for searching the printing function in the abnormal information storage processing file in the catalog of the resolver; the printing function modifying unit can be used for modifying the printing function so as to intercept the crash information written into the dump file and store the character string of the crash information into a predefined global variable; and the splicing function writing unit can be used for writing a splicing function so as to generate a readable file of the crash information according to the character strings in the predefined global variables.
In an exemplary embodiment, the apparatus 700 for capturing application crash information may further include: a test file removal unit operable to remove the unit test files in the parser framework.
It should be noted that although in the above detailed description several units of the device for action execution are mentioned, this division is not mandatory. Indeed, the features and functions of two or more units described above may be embodied in one unit, in accordance with embodiments of the present disclosure. Conversely, the features and functions of one unit described above may be further divided into embodiments by a plurality of units.
Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein may be implemented by software, or by software in combination with necessary hardware. Therefore, the technical solution according to the embodiments of the present disclosure may be embodied in the form of a software product, which may be stored in a non-volatile storage medium (which may be a CD-ROM, a usb disk, a removable hard disk, etc.) or on a network, and includes several instructions to enable a computing device (which may be a personal computer, a server, a touch terminal, or a network device, etc.) to execute the method according to the embodiments of the present disclosure.
Other embodiments of the disclosure will be apparent to those skilled in the art from consideration of the specification and practice of the disclosure disclosed herein. This application is intended to cover any variations, uses, or adaptations of the disclosure following, in general, the principles of the disclosure and including such departures from the present disclosure as come within known or customary practice within the art to which the disclosure pertains. It is intended that the specification and examples be considered as exemplary only, with a true scope and spirit of the disclosure being indicated by the following claims.
It will be understood that the present disclosure is not limited to the precise arrangements described above and shown in the drawings and that various modifications and changes may be made without departing from the scope thereof. The scope of the present disclosure is limited only by the appended claims.
Claims (10)
1. A method for capturing application crash information, comprising:
when detecting that the application program has local crash, writing the crash information of the local crash into a dump file;
intercepting crash information written into the dump file, and storing character strings of the crash information into a predefined global variable;
generating a readable file of the crash information according to the character strings in the predefined global variables;
and uploading the readable file of the crash information to a server so that the server can locate and analyze the local crash of the application program according to the readable file of the crash information.
2. The method of claim 1, further comprising:
acquiring a source code file of a crash capture tool, wherein the source code file comprises a client folder, a general folder, a parser folder and a crash capture tool folder;
copying the client folder, the general folder, the resolver folder and the crash capture tool folder to a JAVA local interface directory of the application program, wherein the resolver folder comprises a migration file of a resolver;
and adding the files in the JAVA local interface directory into the construction configuration file.
3. The method of claim 2, further comprising:
and calling an initialization class defined in the crash capture tool folder for initialization, and writing a callback function when the local crash occurs to the application program, so as to write the crash information of the local crash into a dump file when the local crash occurs to the application program is detected.
4. The method of claim 2, further comprising:
copying the directory of the resolver to the directory of the JAVA local interface by using the migration file of the resolver;
and adding files in the catalogue of the resolver into the construction configuration file.
5. The method of claim 4, further comprising:
searching a printing function in an abnormal information storage processing file in the catalog of the resolver;
modifying the printing function to intercept the crash information written in the dump file and storing the character string of the crash information into a predefined global variable;
and writing a splicing function for generating a readable file of the crash information according to the character strings in the predefined global variables.
6. The method of claim 4, further comprising:
and removing the unit test file in the resolver framework.
7. An apparatus for capturing application crash information, comprising:
the crash information writing unit is used for writing the crash information which is locally crashed into a dump file when the application program is detected to be locally crashed;
a crash information intercepting unit for intercepting crash information written in the dump file and storing a character string of the crash information into a predefined global variable;
the readable file generating unit is used for generating a readable file of the crash information according to the character strings in the predefined global variables;
and the readable file uploading unit is used for uploading the readable file of the crash information to a server so as to facilitate the server to locate and analyze the local crash of the application program according to the readable file of the crash information.
8. The apparatus of claim 7, further comprising:
the source code file acquisition unit is used for acquiring a source code file of the crash capture tool and comprises a client folder, a general folder, a parser folder and a crash capture tool folder;
the file folder copying unit is used for copying the client side file folder, the general file folder, the resolver file folder and the crash capture tool file folder to a JAVA local interface directory of the application program, wherein the resolver file folder comprises a migration file of a resolver;
and the file adding configuration unit is used for adding the files in the JAVA local interface directory into the construction configuration file.
9. A computer-readable storage medium, on which a computer program is stored, which, when being executed by a processor, carries out the method of capturing application crash information according to any one of claims 1 to 6.
10. An electronic device, comprising:
one or more processors;
storage means for storing one or more programs which, when executed by the one or more processors, cause the one or more processors to implement the method of capturing application crash information as claimed in any one of claims 1 to 6.
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010083965.7A CN111258802A (en) | 2020-02-10 | 2020-02-10 | Method for capturing application program crash information and related equipment |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| CN202010083965.7A CN111258802A (en) | 2020-02-10 | 2020-02-10 | Method for capturing application program crash information and related equipment |
Publications (1)
| Publication Number | Publication Date |
|---|---|
| CN111258802A true CN111258802A (en) | 2020-06-09 |
Family
ID=70948237
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| CN202010083965.7A Pending CN111258802A (en) | 2020-02-10 | 2020-02-10 | Method for capturing application program crash information and related equipment |
Country Status (1)
| Country | Link |
|---|---|
| CN (1) | CN111258802A (en) |
Cited By (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111813667A (en) * | 2020-06-30 | 2020-10-23 | 北京字节跳动网络技术有限公司 | Method, device, medium and equipment for collecting application running track |
| CN112199224A (en) * | 2020-09-29 | 2021-01-08 | 珠海豹好玩科技有限公司 | Analysis method and device of crash file, electronic equipment and storage medium |
| CN112463343A (en) * | 2020-12-16 | 2021-03-09 | 广州博冠信息科技有限公司 | Business process restarting method and device, storage medium and electronic equipment |
| CN113886142A (en) * | 2021-10-18 | 2022-01-04 | 北京达佳互联信息技术有限公司 | File generation control method, device, server and storage medium |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106649107A (en) * | 2016-12-09 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | Automated testing method and device for stability of Android system |
| CN106649089A (en) * | 2016-10-09 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | Application crash analysis method and system |
| CN106844136A (en) * | 2016-12-06 | 2017-06-13 | 北京智能管家科技有限公司 | The collection method and system of a kind of program crashing information |
| CN109408261A (en) * | 2018-09-26 | 2019-03-01 | 中国平安财产保险股份有限公司 | Application crash processing method, device, computer equipment and storage medium |
-
2020
- 2020-02-10 CN CN202010083965.7A patent/CN111258802A/en active Pending
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN106649089A (en) * | 2016-10-09 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | Application crash analysis method and system |
| CN106844136A (en) * | 2016-12-06 | 2017-06-13 | 北京智能管家科技有限公司 | The collection method and system of a kind of program crashing information |
| CN106649107A (en) * | 2016-12-09 | 2017-05-10 | 武汉斗鱼网络科技有限公司 | Automated testing method and device for stability of Android system |
| CN109408261A (en) * | 2018-09-26 | 2019-03-01 | 中国平安财产保险股份有限公司 | Application crash processing method, device, computer equipment and storage medium |
Cited By (7)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN111813667A (en) * | 2020-06-30 | 2020-10-23 | 北京字节跳动网络技术有限公司 | Method, device, medium and equipment for collecting application running track |
| CN111813667B (en) * | 2020-06-30 | 2024-03-26 | 北京字节跳动网络技术有限公司 | Method, device, medium and equipment for collecting application running track |
| CN112199224A (en) * | 2020-09-29 | 2021-01-08 | 珠海豹好玩科技有限公司 | Analysis method and device of crash file, electronic equipment and storage medium |
| CN112463343A (en) * | 2020-12-16 | 2021-03-09 | 广州博冠信息科技有限公司 | Business process restarting method and device, storage medium and electronic equipment |
| CN112463343B (en) * | 2020-12-16 | 2023-09-26 | 广州博冠信息科技有限公司 | Restarting method and device of business process, storage medium and electronic equipment |
| CN113886142A (en) * | 2021-10-18 | 2022-01-04 | 北京达佳互联信息技术有限公司 | File generation control method, device, server and storage medium |
| CN113886142B (en) * | 2021-10-18 | 2025-11-04 | 北京达佳互联信息技术有限公司 | File generation control method, device, server and storage medium |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US9703678B2 (en) | Debugging pipeline for debugging code | |
| JP5415557B2 (en) | User script code conversion for debugging | |
| CN111740948B (en) | Data packet issuing method, dynamic updating method, device, equipment and medium | |
| US8407667B2 (en) | Inferring missing type information for reflection | |
| US8156473B2 (en) | Model oriented debugging | |
| US8707263B2 (en) | Using a DSL for calling APIS to test software | |
| US9684786B2 (en) | Monitoring an application in a process virtual machine | |
| US8239823B2 (en) | Generating libraries for reflection without project compilation | |
| CN110531962B (en) | Development processing method and device for applet and computer readable storage medium | |
| CN111176629A (en) | Application development method and device | |
| CN111258802A (en) | Method for capturing application program crash information and related equipment | |
| CN111459499A (en) | Program compiling method and device, computer storage medium and electronic equipment | |
| CN115629971A (en) | Application development system and development method | |
| CN113778897A (en) | Automatic test method, device, equipment and storage medium of interface | |
| US7171650B2 (en) | System and method for integrating resources in a network | |
| US12373203B2 (en) | Development environment integrated with infrastructure cost estimation system | |
| CN111694729B (en) | Application testing method, device, electronic equipment and computer readable medium | |
| CN111352631A (en) | Interface compatibility detection method and device | |
| US10353700B1 (en) | Code base sharing between standalone and web-based versions of an application via an emulated network communication channel | |
| CN120653269A (en) | Method, apparatus, device and product for generating deployment information of plugins | |
| CN111367512B (en) | A method and device for creating Android library module dependencies in application development | |
| CN117931219A (en) | Front-end project implementation method and device, electronic equipment and storage medium | |
| US9720660B2 (en) | Binary interface instrumentation | |
| CN114064050B (en) | Data processing method, device, electronic device and storage medium | |
| Kwon et al. | Lightweight migration for web applications with framework separation |
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 | ||
| RJ01 | Rejection of invention patent application after publication | ||
| RJ01 | Rejection of invention patent application after publication |
Application publication date: 20200609 |