CN111125015A - Method, apparatus, terminal and medium for dump file classification - Google Patents

Method, apparatus, terminal and medium for dump file classification Download PDF

Info

Publication number
CN111125015A
CN111125015A CN201911326248.6A CN201911326248A CN111125015A CN 111125015 A CN111125015 A CN 111125015A CN 201911326248 A CN201911326248 A CN 201911326248A CN 111125015 A CN111125015 A CN 111125015A
Authority
CN
China
Prior art keywords
module
crash
software
unique
server side
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.)
Granted
Application number
CN201911326248.6A
Other languages
Chinese (zh)
Other versions
CN111125015B (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 Baidu Netcom Science and Technology Co Ltd
Original Assignee
Beijing Baidu Netcom Science and 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 Baidu Netcom Science and Technology Co Ltd filed Critical Beijing Baidu Netcom Science and Technology Co Ltd
Priority to CN201911326248.6A priority Critical patent/CN111125015B/en
Publication of CN111125015A publication Critical patent/CN111125015A/en
Application granted granted Critical
Publication of CN111125015B publication Critical patent/CN111125015B/en
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/14Details of searching files based on file metadata
    • G06F16/148File search processing
    • 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
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/13File access structures, e.g. distributed indices

Abstract

Embodiments of the present disclosure disclose methods, apparatuses, terminals, and media for dump file classification. One embodiment of the method comprises: in response to detecting the software crash, determining a first module belonging to the software in a call stack according to a pop sequence; generating a unique crash identifier based on the module name and the call address offset of the module; and sending the unique crash identifications and the dump files to the server side, so that the server side classifies the dump files based on the unique crash identifications. The unique crash identifier is generated through the module name and the call address offset, and the server can complete classification based on the unique crash identifier when receiving the dump file, so that a large amount of workload of manual analysis is saved, and the efficiency is improved. Moreover, the bug address when the software crashes can be accurately positioned when the software runs in different terminals or environments.

Description

Method, apparatus, terminal and medium for dump file classification
Technical Field
Embodiments of the present disclosure relate to the field of computer technologies, and in particular, to a method, an apparatus, a terminal, and a medium for dump file classification.
Background
When software crashes, in order to find the cause of the crash, a computer operating system (such as a Windows system) generates a dump (memory image of a process) file and sends the dump file to a server side, and developers analyze the dump file to realize collection and processing of the crash of the software product.
In the related art, after a large number of dump files are collected at a server side, the dump files need to be analyzed manually, and meanwhile, developers need to perform classification statistics on the reasons of software product breakdown. Manual analysis and statistics often have subjectivity of a large degree, so that analysis and statistics standards are not uniform, and in a scene of mass data, dump file information data often have multiple dimensions and large data volume, analysis and statistics often are inaccurate by manual work, coverage rate is not high enough, repeated work also easily causes errors, manual operation time is long, efficiency is low, and labor cost is very high.
Disclosure of Invention
Embodiments of the present disclosure propose methods and apparatuses for dump file classification.
In a first aspect, an embodiment of the present disclosure provides a method for dump file classification, where the method includes: in response to detecting the software crash, determining a first module belonging to the software in a call stack according to a pop sequence; generating a unique crash identifier based on the module name and the call address offset of the module; and sending the unique crash identifications and the dump files to the server side, so that the server side classifies the dump files based on the unique crash identifications.
In some embodiments, in response to detecting a software crash, determining that a first module in the call stack belongs to software in a pop order comprises: in response to detecting the software crash, obtaining a call stack; sequentially judging whether the module names in the call stack exist in a configuration file according to the pop sequence, wherein the configuration file stores all module names of the software; and responding to the existence, determining that the module corresponding to the module name is the first module belonging to the software, and finishing the judgment.
In some embodiments, the call address offset is determined by: acquiring a base address of a module; and determining the difference between the calling address of the module in the calling stack and the base address as the calling address offset of the module.
In some embodiments, the unique crash identification is determined by: connecting the module name and the call address offset in series to generate a character string; and determining the character string as a unique crash identifier so as to be conveniently sent to the server side.
In some embodiments, sending the unique crash identifier and the dump file to the server side, so that the server side classifies the dump file based on the unique crash identifier, includes: and sending the unique crash identifier and the dump file to the server side so that the server side takes the dump files with the same unique crash identifier as the same type.
In a second aspect, an embodiment of the present disclosure provides an apparatus for dump file classification, the apparatus including: the module determining unit is configured to determine a first module belonging to the software in the call stack according to the pull sequence in response to the detection of the software crash; a generation unit configured to generate a unique crash identifier based on a module name and a call address offset of the module; and the sending unit is configured to send the unique crash identifications and the dump files to the server side, so that the server side classifies the dump files based on the unique crash identifications.
In some embodiments, the module determining unit is further configured to perform the following operations: in response to detecting the software crash, obtaining a call stack; sequentially judging whether the module names in the call stack exist in a configuration file according to the pop sequence, wherein the configuration file stores all module names of the software; and responding to the existence, determining that the module corresponding to the module name is the first module belonging to the software, and finishing the judgment.
In some embodiments, the apparatus further comprises a calculation unit configured to determine the call address offset by: acquiring a base address of a module; and determining the difference between the calling address of the module in the calling stack and the base address as the calling address offset of the module.
In some embodiments, the generation unit is further configured to determine the unique crash identification by: connecting the module name and the call address offset in series to generate a character string; and determining the character string as a unique crash identifier so as to be conveniently sent to the server side.
In some embodiments, the sending unit sends the unique crash identifier and the dump file to the server side, so that the server side classifies the dump file based on the unique crash identifier, including:
and sending the unique crash identifier and the dump file to the server side so that the server side takes the dump files with the same unique crash identifier as the same type.
According to the method and the device for classifying the dump files, the unique crash identifications are generated through the module names and the call address offset, the server can complete classification based on the unique crash identifications when receiving the dump files, a large amount of workload of manual analysis is saved, and efficiency is improved. Moreover, the bug address when the software crashes can be accurately positioned when the software runs in different terminals or environments.
Drawings
Other features, objects and advantages of the disclosure will become more apparent upon reading of the following detailed description of non-limiting embodiments thereof, made with reference to the accompanying drawings in which:
FIG. 1 is an exemplary system architecture diagram in which some embodiments of the present disclosure may be applied;
FIG. 2 is a flow diagram of one embodiment of a method for dump file classification according to the present disclosure;
FIG. 3 is a schematic diagram of one application scenario of a method for dump file classification according to an embodiment of the present disclosure;
FIG. 4 is a flow diagram of yet another embodiment of a method for dump file classification according to the present disclosure;
FIG. 5 is a schematic block diagram of one embodiment of an apparatus for dump file classification according to the present disclosure;
FIG. 6 is a schematic structural diagram of an electronic device suitable for use in implementing embodiments of the present disclosure.
Detailed Description
The present disclosure is described in further detail below with reference to the accompanying drawings and examples. It is to be understood that the specific embodiments described herein are merely illustrative of the relevant invention and not restrictive of the invention. It should be noted that, for convenience of description, only the portions related to the related invention are shown in the drawings.
It should be noted that, in the present disclosure, the embodiments and features of the embodiments may be combined with each other without conflict. The present disclosure will be described in detail below with reference to the accompanying drawings in conjunction with embodiments.
FIG. 1 illustrates an exemplary system architecture 100 for a method or apparatus for dump file classification to which embodiments of the present disclosure may be applied.
As shown in fig. 1, the system architecture 100 may include 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.
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 apparatuses 101, 102, and 103 may be hardware or software. When the terminal devices 101, 102, 103 are hardware, they may be various electronic devices supporting data transmission, including but not limited to smart phones, tablet computers, e-book readers, laptop portable computers, desktop computers, and the like, on which operating systems (e.g., Windows systems) are installed, and may run various software applications.
The server 105 may be a server that provides various services, such as a background server that processes data uploaded by the terminal devices 101, 102, 103. The background server may classify the received dump files based on the unique crash identifier.
It should be noted that the method for classifying dump files provided by the embodiments of the present disclosure may be executed by the terminal devices 101, 102, and 103, and accordingly, the apparatus for classifying dump files may be disposed in the terminal devices 101, 102, and 103.
With continued reference to FIG. 2, a flow 200 of one embodiment of a method for dump file classification in accordance with the present disclosure is shown. The method for classifying the dump files comprises the following steps of:
step 201, in response to detecting the software crash, determining a first module in the call stack belonging to the software according to the pop sequence.
In this embodiment, an executing body (for example, the terminal shown in fig. 1) of the method for classifying dump files may communicate with the server end through a wired connection manner or a wireless connection manner, and it should be noted that the wireless connection manner may include, but is not limited to, a 3G/4G connection, a WiFi connection, a bluetooth connection, a WiMAX connection, a Zigbee connection, a uwb (ultra wideband) connection, and other wireless connection manners known now or developed in the future.
At present, many software products, such as software products of a Windows system, are expected to record an operating environment and a cause of a crash of a product when the product crashes, and to sort according to the number of crashes according to the cause of the crash, so that a product developer can locate bugs (bugs) of a program in time and preferentially locate bugs with a large number of crashes, so as to improve the quality of codes and the stability of the product, in order to improve public praise of users, pursue the stability of the product, and improve the quality of software.
Generally, when software running on a terminal crashes, running module information such as module names, module calling addresses and other information is stored in a calling stack, the modules are sequentially arranged from top to bottom according to a pop sequence, a first module belonging to the software is determined according to the pop sequence, a last module running before the software crashes is represented, and therefore a bug causing the software crash can be located more conveniently. As an example, the calling information of the module may be obtained through a Stack Trace (Stack Trace) technique in the related art, so as to determine the first module belonging to the software from the Stack.
Step 202, a unique crash identifier is generated based on the module name and the call address offset of the module.
Generally, if a bug exists somewhere on a module of software and the software crashes when running there, the crash will have the same characteristics, which is "same place on the same module". Because the calling addresses of the modules are different when the same software runs at different terminals or in different environments, the module with the bug cannot be accurately positioned only through the calling address of the module. However, the call address offset of the module is fixed and does not change depending on the operating terminal or environment of the software. Therefore, in this embodiment, the bug can be located more accurately by the unique crash id generated by the module name and the call address offset.
In this embodiment, based on the first module belonging to the software obtained in step 201, the execution principal (e.g., the terminal shown in fig. 1) may directly obtain the name of the module and the calling address of the module from the call stack, further determine the calling address offset of the module, and then generate a unique crash identifier based on the module name and the calling address offset.
In some optional implementations of this embodiment, the call address offset may be determined as follows:
first, the base address of the module is obtained. The following describes a method for acquiring a base address in conjunction with a specific application scenario, for example, a module name may be introduced through a getmodulemondle function of a winods API, where example codes are as follows:
hand HANDLE is the base address of the module, GetModuleHandle (L "kernel32. dll").
As another example, the base address of the module may be obtained by using the VirtualQueryEx function of the Windows API, with example code as follows:
MEMORY_BASIC_INFORMATION mbi;
::VirtualQueryEx(::GetCurrentProcess(),(LPCVOID)&GetCurrentProcess,&mbi,sizeof(mbi));
allocationbase is the base address of the module.
Then, the difference between the calling address and the base address is used as the calling address offset of the module. As an example, the calling address of the module is "0133018C", the retrieved base address is "0122017B", and the calling address offset is "00110011".
Then, a unique crash identifier is generated based on the module name and the call address offset, for example, the module name and the call address offset may be combined and then encoded through a Hash operation, so as to generate the encoded unique crash identifier.
In some alternative implementations of this embodiment, the unique crash identification may be further generated as follows. Connecting the module name and the calling address in series to generate a character string; and determining the character string as a unique crash identifier so as to be conveniently sent to the server side. As an example, the name of the module is "X software module 1. dll", the call address offset is "00110011", the generated unique crash identifier is "X software module 1.dll 00110011", the data type is a character string, data operation can be reduced to the maximum extent, and the data operation is also convenient for an operator to read.
And step 203, sending the unique crash identifier and the dump file to the server side.
In this embodiment, the execution subject (e.g., the terminal shown in fig. 1) sends the unique crash identifier and the dump file to the server (e.g., the server shown in fig. 1), so that the server classifies the dump file based on the unique crash identifier, for example, unique crash identifiers with the same module name and a similar calling address offset may be classified into one class. The server end can complete classification based on the unique crash identifier when receiving the dump file, so that a large amount of workload of manual analysis is saved, and the efficiency is improved.
In some optional implementations of this embodiment, the server side may treat dump files with the same unique crash identifier as the same class. Therefore, the dump files can be classified according to the accurate addresses of the bugs in the breakdown process, the workload of analyzing a large number of dump files by follow-up manual work is saved, and the efficiency and the accuracy are improved.
With continued reference to fig. 3, fig. 3 is a schematic diagram of an application scenario of the method for dump file classification according to the present embodiment. In the application scenario of fig. 3, a user 301 runs software on a terminal 302 (e.g., a computer), and when a software crash is detected, the terminal 302 determines a first module in a call stack that belongs to the software, generates a unique crash identifier based on a module name and a call address offset of the module, and sends the unique crash identifier and a corresponding dump file to a server 303. The server side 303 classifies the dump files based on the unique crash identifications.
According to the method for classifying the dump files in the embodiment, the unique crash identifier is generated through the module name and the call address offset, the server can complete classification based on the unique crash identifier when receiving the dump files, a large amount of workload of manual analysis is saved, and efficiency is improved. In addition, the bug address when the software crashes can be accurately positioned when the software runs in different terminals or environments.
With further reference to FIG. 4, a flow 400 of yet another embodiment of a method for dump file classification is shown. The process 400 of the method for dump file classification includes the following steps:
in response to detecting a software crash, a call stack is obtained, step 401.
And step 402, sequentially judging whether the module names exist in the configuration file according to the pop sequence.
All module names of the software are stored in the configuration file, and an operator can update the module names in the configuration file according to actual conditions. Since the module information stored in the call stack includes not only the module of the crash software but also the modules of other software or systems, in order to avoid mistaking the modules of other software or systems as the module of the crash software, in this embodiment, it is possible to verify whether the module belongs to the crash software through step 402, and false alarm can be prevented.
And step 403, in response to the existence, determining that the module corresponding to the module name is the first module belonging to the software. If the module name exists in the configuration file, the module corresponding to the module name belongs to the software. Based on "sequentially verifying the module names according to the pop sequence" in step 402, the last module running when the software crashes, that is, "the first module belonging to the software" in this embodiment, may be determined, and at this time, the determination may be ended.
Step 404, generate a unique crash identification based on the module name and the call address offset of the module. This step is similar to the step 202, and will not be described herein.
Step 405, sending the unique crash identifier and the dump file to the server side. So that the server end classifies the dump files based on the unique crash id, which is similar to the step 203 described above and will not be described herein again.
As can be seen from fig. 4, compared with the corresponding embodiment of fig. 2, the flow 400 of the method for classifying dump files in this embodiment represents a step of verifying whether a module belongs to crash software. Therefore, the scheme described in the embodiment can avoid mistakenly considering the wrong module as the module of the crash software, and ensure the accuracy of the unique crash identifier, thereby improving the accuracy of the classification and subsequent analysis of the dump files.
With further reference to fig. 5, as an implementation of the methods shown in the above figures, the present disclosure provides an embodiment of an apparatus for dump file classification, which corresponds to the embodiment of the method shown in fig. 2, and which may be applied in various electronic devices.
As shown in fig. 5, the apparatus 500 for dump file classification of the present embodiment includes: a module determination unit 501, a generation unit 502, and a transmission unit 503. The module determining unit 501 is configured to determine, in response to detecting a software crash, a first module in the call stack belonging to the software according to the pop sequence; a generating unit 502 configured to generate a unique crash identifier based on a module name and a call address offset of the module; a sending unit 503 configured to send the unique crash identifier and the dump file to the server side, so that the server side classifies the dump file based on the unique crash identifier.
In the present embodiment, the module determination unit 501 is further configured to perform the following operations: in response to detecting the software crash, obtaining a call stack; sequentially judging whether the module names in the call stack exist in a configuration file according to the pop sequence, wherein the configuration file stores all module names of the software; and responding to the existence, determining that the module corresponding to the module name is the first module belonging to the software, and finishing the judgment.
In this embodiment, the apparatus further comprises a calculation unit configured to determine the call address offset by: acquiring a base address of a module; and determining the difference between the calling address of the module in the calling stack and the base address as the calling address offset of the module.
In this embodiment, the generation unit 502 is further configured to determine the unique crash identity by: connecting the module name and the call address offset in series to generate a character string; and determining the character string as a unique crash identifier so as to be conveniently sent to the server side.
In this embodiment, the sending unit 503 sends the unique crash identifier and the dump file to the server side, so that the server side classifies the dump file based on the unique crash identifier, including: and sending the unique crash identifier and the dump file to the server side so that the server side takes the dump files with the same unique crash identifier as the same type.
Referring now to fig. 6, shown is a schematic diagram of an electronic device (e.g., terminal device in fig. 1) 600 suitable for use in implementing embodiments of the present disclosure. The terminal device in the embodiments of the present disclosure may include, but is not limited to, a mobile terminal such as a mobile phone, a notebook computer, a PDA (personal digital assistant), a PAD (tablet computer), a vehicle-mounted terminal (e.g., a vehicle-mounted navigation terminal), and the like, and a stationary terminal such as a desktop computer and the like. The terminal device shown in fig. 6 is only an example, and should not bring any limitation to the functions and the use range of the embodiments of the present disclosure.
As shown in fig. 6, electronic device 600 may include a processing means (e.g., central processing unit, graphics processor, etc.) 601 that may perform various appropriate actions and processes in accordance with a program stored in a Read Only Memory (ROM)602 or a program loaded from a storage means 608 into a Random Access Memory (RAM) 603. In the RAM 603, various programs and data necessary for the operation of the electronic apparatus 600 are also stored. The processing device 601, the ROM 602, and the RAM 603 are connected to each other via a bus 604. An input/output (I/O) interface 605 is also connected to bus 604.
Generally, the following devices may be connected to the I/O interface 605: input devices 606 including, for example, a touch screen, touch pad, keyboard, mouse, camera, microphone, accelerometer, gyroscope, etc.; output devices 607 including, for example, a Liquid Crystal Display (LCD), a speaker, a vibrator, and the like; storage 608 including, for example, tape, hard disk, etc.; and a communication device 609. The communication means 609 may allow the electronic device 600 to communicate with other devices wirelessly or by wire to exchange data. While fig. 6 illustrates an electronic device 600 having various means, it is to be understood that not all illustrated means are required to be implemented or provided. More or fewer devices may alternatively be implemented or provided. Each block shown in fig. 6 may represent one device or may represent multiple devices as desired.
In particular, according to an embodiment 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 via the communication means 609, or may be installed from the storage means 608, or may be installed from the ROM 602. The computer program, when executed by the processing device 601, performs the above-described functions defined in the methods of embodiments of the present disclosure. It should be noted that the computer readable medium described in the embodiments of 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 embodiments of the 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 embodiments of the present disclosure, however, a computer readable signal medium may comprise 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: electrical wires, optical cables, RF (radio frequency), etc., or any suitable combination of the foregoing.
The computer readable medium may be embodied in the terminal; or may exist separately without being assembled into the electronic device. The computer readable medium carries one or more programs which, when executed by the electronic device, cause the electronic device to: in response to detecting the software crash, determining a first module belonging to the software in a call stack according to a pop sequence; generating a unique crash identifier based on the module name and the call address offset of the module; and sending the unique crash identifications and the dump files to the server side, so that the server side classifies the dump files based on the unique crash identifications.
Computer program code for carrying out operations for embodiments of the present disclosure may be written in any combination of one or more programming languages, including an object oriented programming language such as Java, Smalltalk, C + +, and conventional procedural programming languages, such as the "C" programming language or similar programming languages. The program code may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the case of a remote computer, the remote computer may be connected to the user's computer through any type of network, including a Local Area Network (LAN) or a Wide Area Network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet service provider).
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 and/or flowchart illustration, and combinations of blocks in the block diagrams and/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 hardware. The described units may also be provided in a processor, and may be described as: a processor includes a module confirmation unit, a calculation unit, and a transmission unit. Where the names of these elements do not in some cases constitute a limitation on the elements themselves, for example, a module validation element may also be described as "determining the first element in the call stack that belongs to a module of software in the order of pop-up in response to detecting a software crash.
The foregoing description is only exemplary of the preferred embodiments of the disclosure and is illustrative of the principles of the technology employed. It will be appreciated by those skilled in the art that the scope of the invention in the embodiments of the present disclosure is not limited to the specific combination of the above-mentioned features, but also encompasses other embodiments in which any combination of the above-mentioned features or their equivalents is made without departing from the inventive concept as defined above. For example, the above features and (but not limited to) technical features with similar functions disclosed in the embodiments of the present disclosure are mutually replaced to form the technical solution.

Claims (12)

1. A method for dump file classification, comprising:
in response to detecting the software crash, determining a first module in a call stack belonging to the software according to a pop sequence;
generating a unique crash identifier based on the module name and the call address offset of the module;
and sending the unique crash identifier and the dump file to a server side, so that the server side classifies the dump file based on the unique crash identifier.
2. The method of claim 1, in response to detecting a software crash, determining that a first module in a call stack belongs to the software in a pop order, comprising:
in response to detecting the software crash, obtaining a call stack;
sequentially judging whether the module names in the call stack exist in a configuration file according to the pop sequence, wherein all module names of the software are stored in the configuration file;
and responding to the existence, determining that the module corresponding to the module name is the first module belonging to the software, and finishing the judgment.
3. The method of claim 1, wherein the call address offset is determined by:
acquiring a base address of the module;
and determining the difference between the calling address of the module in the calling stack and the base address as the calling address offset of the module.
4. The method of claim 1, wherein the unique crash identification is determined by:
connecting the module name and the call address offset in series to generate a character string;
and determining the character string as the unique collapse identifier so as to be sent to a server side conveniently.
5. The method of claim 1, wherein sending the unique crash identifier and the dump file to a server side, so that the server side classifies the dump file based on the unique crash identifier comprises:
and sending the unique crash identifier and the dump file to a server side so that the server side takes the dump files with the same unique crash identifier as the same class.
6. An apparatus for dump file classification, comprising:
the module determining unit is configured to determine a first module in a call stack belonging to the software according to the pull sequence in response to the detection of the software crash;
a generation unit configured to generate a unique crash identifier based on a module name and a call address offset of the module;
and the sending unit is configured to send the unique crash identifications and the dump files to the server side, so that the server side classifies the dump files based on the unique crash identifications.
7. The apparatus of claim 6, wherein the module determination unit is further configured to:
in response to detecting the software crash, obtaining a call stack;
sequentially judging whether the module names in the call stack exist in a configuration file according to the pop sequence, wherein all module names of the software are stored in the configuration file;
and responding to the existence, determining that the module corresponding to the module name is the first module belonging to the software, and finishing the judgment.
8. The apparatus of claim 6, further comprising a calculation unit configured to determine the call address offset by:
acquiring a base address of the module;
and determining the difference between the calling address of the module in the calling stack and the base address as the calling address offset of the module.
9. The apparatus of claim 6, wherein the generation unit is further configured to determine the unique crash identification by:
connecting the module name and the call address offset in series to generate a character string;
and determining the character string as the unique collapse identifier so as to be sent to a server side conveniently.
10. The apparatus of claim 6, wherein the sending unit sends the unique crash identifier and the dump file to a server side, so that the server side classifies the dump file based on the unique crash identifier, including:
and sending the unique crash identifier and the dump file to a server side so that the server side takes the dump files with the same unique crash identifier as the same class.
11. A terminal, comprising:
one or more processors;
a storage device having one or more programs stored thereon,
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, wherein the program, when executed by a processor, implements the method of any one of claims 1-5.
CN201911326248.6A 2019-12-20 2019-12-20 Method, apparatus, terminal and medium for dump file classification Active CN111125015B (en)

Priority Applications (1)

Application Number Priority Date Filing Date Title
CN201911326248.6A CN111125015B (en) 2019-12-20 2019-12-20 Method, apparatus, terminal and medium for dump file classification

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
CN201911326248.6A CN111125015B (en) 2019-12-20 2019-12-20 Method, apparatus, terminal and medium for dump file classification

Publications (2)

Publication Number Publication Date
CN111125015A true CN111125015A (en) 2020-05-08
CN111125015B CN111125015B (en) 2023-04-14

Family

ID=70500714

Family Applications (1)

Application Number Title Priority Date Filing Date
CN201911326248.6A Active CN111125015B (en) 2019-12-20 2019-12-20 Method, apparatus, terminal and medium for dump file classification

Country Status (1)

Country Link
CN (1) CN111125015B (en)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113867847A (en) * 2021-11-30 2021-12-31 统信软件技术有限公司 Abnormal plug-in processing method and device and computing equipment

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120110383A1 (en) * 2010-10-29 2012-05-03 HT mMobile Inc. Method and apparatus for off-line analyzing crashed programs
US20120166893A1 (en) * 2010-12-27 2012-06-28 International Business Machines Corporation Recording and Preventing Crash in an Appliance
CN104536874A (en) * 2014-12-26 2015-04-22 北京像素软件科技股份有限公司 Client collapse locating method and device
CN106354646A (en) * 2016-08-30 2017-01-25 竞技世界(北京)网络技术有限公司 Method for analyzing dump files
CN106484608A (en) * 2015-09-01 2017-03-08 青岛海信电器股份有限公司 A kind of kernel fault localization method, device and computer
CN106708704A (en) * 2016-12-23 2017-05-24 北京奇虎科技有限公司 Method and device for classifying crash logs

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20120110383A1 (en) * 2010-10-29 2012-05-03 HT mMobile Inc. Method and apparatus for off-line analyzing crashed programs
US20120166893A1 (en) * 2010-12-27 2012-06-28 International Business Machines Corporation Recording and Preventing Crash in an Appliance
CN104536874A (en) * 2014-12-26 2015-04-22 北京像素软件科技股份有限公司 Client collapse locating method and device
CN106484608A (en) * 2015-09-01 2017-03-08 青岛海信电器股份有限公司 A kind of kernel fault localization method, device and computer
CN106354646A (en) * 2016-08-30 2017-01-25 竞技世界(北京)网络技术有限公司 Method for analyzing dump files
CN106708704A (en) * 2016-12-23 2017-05-24 北京奇虎科技有限公司 Method and device for classifying crash logs

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
博客: "调试技巧之调用堆栈" *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN113867847A (en) * 2021-11-30 2021-12-31 统信软件技术有限公司 Abnormal plug-in processing method and device and computing equipment

Also Published As

Publication number Publication date
CN111125015B (en) 2023-04-14

Similar Documents

Publication Publication Date Title
KR102379313B1 (en) Electronic device for displaying application andoperating method thereof
CN109873735B (en) Performance test method and device for H5 page and computer equipment
CN111897740A (en) User interface testing method and device, electronic equipment and computer readable medium
CN110908922A (en) Application program testing method and device
CN111506900A (en) Vulnerability detection method and device, electronic equipment and computer storage medium
CN111459822B (en) Method, device, equipment and readable medium for extracting system component data
CN111125015B (en) Method, apparatus, terminal and medium for dump file classification
CN112596738B (en) Method and device for determining front-end page to be tested, storage medium and electronic equipment
CN109144864B (en) Method and device for testing window
CN109408387B (en) Page testing method and device
CN116662193A (en) Page testing method and device
CN111324470A (en) Method and device for generating information
CN111506904A (en) Method and device for online vulnerability repair
CN112379967B (en) Simulator detection method, device, equipment and medium
CN114025014B (en) Asset detection method and device, electronic equipment and storage medium
US20190147860A1 (en) Method and apparatus for identifying information
CN110084298B (en) Method and device for detecting image similarity
CN111309323B (en) Parameter initialization method and device and electronic equipment
CN110334763B (en) Model data file generation method, model data file generation device, model data file identification device, model data file generation apparatus, model data file identification apparatus, and model data file identification medium
CN114168183A (en) Front-end resource information processing method, device, equipment and storage medium
CN113849416A (en) Test method, test device, storage medium and electronic equipment
CN113626301A (en) Method and device for generating test script
CN111694875B (en) Method and device for outputting information
CN111797009A (en) Method and device for detecting code compatibility and electronic equipment
CN113704079A (en) Interface testing method and device based on Protobuf

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