CN116795712A - Reverse debugging method, computing device and storage medium - Google Patents

Abstract

The invention discloses a reverse debugging method, a computing device and a storage medium, wherein the reverse debugging method comprises the following steps: responding to an event triggered in the running process of a debugged program, and generating a dump file corresponding to the event so as to record the running state of the debugged program at the time point triggered by the event; and playing back the running state of the debuggee program at the event-triggered time point according to the dump file so as to determine the fault of the debuggee program. According to the technical scheme of the invention, event-level reverse debugging is realized, the efficiency of fault diagnosis of the program is improved, and the program problem can be more accurately positioned.

Description

Reverse debugging method, computing device and storage medium

Technical Field

The present invention relates to the field of debugging technologies, and in particular, to a reverse debugging method, a computing device, and a storage medium.

Background

An integrated development environment (IDE, integrated Development Environment) is an application program for providing a program development environment, and generally includes tools such as a code editor, a compiler, a debugger, and a graphical user interface. The development software service sleeve integrates a code writing function, an analysis function, a compiling function, a debugging function and the like.

In the current technical background, the function of the IDE is more and more powerful, but the code debugging function as the core function of the IDE is not changed for a long time. Currently, the main debugging functions comprise starting, running, breakpoint hitting, single step execution and the like of a debugging program, and the functions are gradually solidified. And how to track the problems after the program crashes and how to lack corresponding support for code analysis after the program runs.

In the prior art, qtCreater and Visual Studio have reverse debugging capability and are realized based on the reverse debugging function provided by a debugger, and the principle is that partial codes are subjected to record operation states through GDB, and state data are recovered during reverse debugging, so that reverse sequence execution of a program is realized. The debugging mode is manual, a user is required to determine code fragments to be recorded, the code fragments to be debugged are recorded manually, automatic triggering recording cannot be achieved, and recovery cannot be conducted aiming at system call events, x11 events, D-Bus events and the like, so that an event-level reverse debugging function cannot be achieved. In addition, the GDB can only record the running state of the current program, and does not organize the time dimension for the records, so that the time dimension records are lacking, and in addition, the GDB can only record continuous code fragments, and can not discretely record at different positions of the program.

In view of this, a debugging method is needed to solve the problems in the above technical solutions.

Disclosure of Invention

Accordingly, the present invention provides a reverse debug method and debug method to solve or at least alleviate the above-mentioned problems.

According to one aspect of the present invention, there is provided a reverse debug method including: responding to an event triggered in the running process of a debugged program, and generating a dump file corresponding to the event so as to record the running state of the debugged program at the time point triggered by the event; and playing back the running state of the debuggee program at the event-triggered time point according to the dump file so as to determine the fault of the debuggee program.

Optionally, according to the reverse debugging method of the present invention, the event includes a system call event; responding to an event triggered in the running process of a debugged program, generating a dump file corresponding to the event so as to record the running state of the debugged program at the time point triggered by the event, and comprising the following steps: creating a sub-process through the reverse debugging process; starting a debuggee program in the subprocess so that the debuggee program covers the subprocess; monitoring the subprocesses to realize monitoring of the debugged program; and responding to a system call event triggered in the running process of the subprocess, and generating a dump file corresponding to the system call event so as to record the running state of the debugged program at the time point triggered by the system call event.

Optionally, according to the reverse debugging method of the present invention, after creating a sub-process by the reverse debugging process, the method further includes: acquiring the process number of the sub-process; monitoring the sub-process includes: and calling a ptrace function and transmitting the process number of the subprocess to monitor the subprocess.

Optionally, according to the reverse debugging method of the present invention, starting the debuggee program in the sub-process includes: in the sub-process, the debuggee is started using the execute function.

Optionally, according to the reverse debugging method of the present invention, generating the dump file corresponding to the event includes: generating dump files corresponding to a plurality of events according to the plurality of events triggered in the running process of the debugged program, wherein the dump files contain a plurality of event data; according to the dump file, playing back the running state of the debuggee program at the time point triggered by the event, including: reading event data in the dump file; and playing back the running state of the debugged program at the time point triggered by the event according to the event data.

Optionally, according to the reverse debugging method of the present invention, generating the dump file corresponding to the event includes: acquiring a time stamp of the event triggering time point; and generating a dump file corresponding to the event based on the timestamp.

Optionally, the reverse debugging method according to the present invention further includes: and storing the dump file based on the corresponding event type and the time stamp so as to select the dump file of the corresponding event according to the time information.

Optionally, according to the reverse debugging method of the present invention, the obtaining the timestamp of the event-triggered time point includes: and acquiring the time stamp of the time point triggered by the event by utilizing a virtual dynamic library.

Optionally, according to the reverse debugging method of the invention, the events comprise D-Bus events and window events; the method further comprises the steps of: and capturing a D-Bus event or a window event triggered in the running process of the debugged program through an LD_PRELOAD environment variable.

According to one aspect of the present invention, there is provided a debugging method, executed at a front end, the front end being communicatively connected to a back end, the back end being adapted to generate dump files corresponding to a plurality of events triggered during the running of a debugged program according to the reverse debugging method described above; the method comprises the following steps: reading a dump file, traversing each event data recorded in the dump file, wherein the event data comprises a time stamp of an event; drawing corresponding event identification lines at corresponding positions on a time axis according to the time stamp of each event to generate and display a time line; and responding to a playback request of the event triggered based on the event identification line, acquiring corresponding event data, and performing playback operation according to the event data to acquire debugging information of the debugged program.

Optionally, according to the debugging method of the present invention, the front end includes an integrated development application, and the integrated development application includes a debugging plug-in, and the debugging plug-in is adapted to communicate with a reverse debugging tool of the back end via a debugging adapter; performing playback operation according to the event data to obtain debugging information of the debugged program, including: sending a debugging request to a debugging adapter according to the event data through a debugging plug-in, so as to request the debugged program to be run to the reverse debugging tool through the debugging adapter, wherein the reverse debugging tool is suitable for sending a stop signal to the debugging adapter when the debugged program runs to a breakpoint; receiving a stop signal message generated by the debugging adapter according to the stop signal package, and hitting a breakpoint according to the stop signal message; a request to obtain debug information is sent to a debug adapter to obtain stack information and variable values for the debuggee from the reverse debug tool via the debug adapter.

Optionally, according to the debugging method of the present invention, the event data includes memory snapshot data; obtaining corresponding event data, and performing playback operation according to the event data to obtain debugging information of a debugged program, wherein the method comprises the following steps: acquiring corresponding memory snapshot data from the dump file according to the timestamp corresponding to the event identification line; decompressing the memory snapshot data to obtain a memory snapshot file; and performing playback operation according to the memory snapshot file to acquire debugging information of the debugged program.

Optionally, according to the debugging method of the present invention, playback operation is performed according to the memory snapshot file to obtain debugging information of the debugged program, including: and sending a request for acquiring debugging information to a debugging adapter according to the memory snapshot file through a debugging plug-in, so as to acquire the thread information, stack information and variable values of the debugged program from the reverse debugging tool through the debugging adapter.

Optionally, the debugging method according to the present invention further includes: in response to a scaling request for the timeline, a step value is determined from the scaling request and the timeline is scaled according to the step value.

Optionally, according to the debugging method of the present invention, after traversing each event data recorded in the dump file, the debugging method further includes: generating corresponding event items according to the detailed information of each event data; and generating an event list according to each event item and displaying the event list.

Optionally, the debugging method according to the present invention further includes: and responding to a playback request for the event triggered based on the event item, acquiring corresponding event data, and performing playback operation according to the event data to acquire debugging information of the debugged program.

Optionally, the debugging method according to the present invention further includes: and calling the reverse debugging tool at the back end to generate dump files corresponding to a plurality of events triggered in the running process of the debugged program.

Optionally, the debugging method according to the present invention, wherein the dump file is adapted to store event data based on a predetermined data structure; the predetermined data structure comprises: time stamp when event triggers, event type, number of threads when event triggers, memory snapshot data.

Optionally, the debugging method according to the present invention further includes: and generating a storage path of the dump file based on the name, the record times and the process number of the debugged program corresponding to the dump file, and storing the dump file based on the storage path.

According to one aspect of the invention, there is provided a computing device comprising: at least one processor; a memory storing program instructions, wherein the program instructions are configured to be adapted to be executed by the at least one processor, the program instructions comprising instructions for performing the reverse debug method as described above.

According to one aspect of the present invention, there is provided a readable storage medium storing program instructions that, when read and executed by a computing device, cause the computing device to perform the reverse debug method as described above.

According to the technical scheme of the invention, a reverse debugging method is provided, when an event is triggered in the running process of a debugged program, a dump file corresponding to the event is generated to record the running state of the debugged program at the event-triggered time point, so that the running state of the debugged program at the event-triggered time point can be replayed according to the dump file to determine the fault of the debugged program. Therefore, according to the debugging scheme of the invention, fault diagnosis of the debugged program can be realized, and the problem of the debugged program is located. The invention can automatically record the running state of the event trigger through the event trigger, realize the reverse debugging of the event level, improve the efficiency of fault diagnosis on the program and more accurately locate the program problem. Compared with the IDE in the prior art which can only record continuous code fragments at a certain position, the event-level reverse debugging scheme realized by the invention can carry out dump operation at any position operated by a debugged program.

Furthermore, according to the reverse debugging method, by stamping the dump files with the time stamps, the events corresponding to the dump files are arranged according to the time line operated by the debugged program, so that a user can select the corresponding events according to the time information, and the operation state of the debugged program at the time point triggered by the events can be played back according to the dump files corresponding to the events.

In addition, according to the reverse debugging method, the time stamp when the event is triggered is acquired by utilizing the vDSO virtual dynamic library, so that the efficiency of acquiring the time stamp can be improved, and the performance consumption of acquiring the time stamp is reduced.

According to the technical scheme of the invention, a debugging method is also provided, and the front end (IDE) can call a reverse debugging tool of the back end to generate dump files corresponding to a plurality of events triggered in the running process of the debugged program. By reading the dump file, traversing each event data recorded in the dump file, drawing a corresponding event identification line according to the corresponding position of the time stamp of each event on the time axis, and generating and displaying the time line. The user can trigger a playback request of the event based on the event identification line, and the front end responds to the playback request to acquire corresponding event data and perform playback operation so as to acquire debugging information of the debugged program. Therefore, the invention can integrate the reverse debugging function of the rear end into the front end (IDE), realize visual operation, promote usability, and view stack information and variable values of the debugged program based on the interface. In addition, the method and the device for displaying the event identification lines on the time axis based on the time line display the event identification lines on the time axis according to the time sequence triggered by the event by generating the time line, so that a user can conveniently select and position the corresponding event according to the time information, the efficiency of checking the event information is improved, and the interactivity is enhanced.

The foregoing description is only an overview of the present invention, and is intended to be implemented in accordance with the teachings of the present invention in order that the same may be more clearly understood and to make the same and other objects, features and advantages of the present invention more readily apparent.

Drawings

To the accomplishment of the foregoing and related ends, certain illustrative aspects are described herein in connection with the following description and the annexed drawings, which set forth the various ways in which the principles disclosed herein may be practiced, and all aspects and equivalents thereof are intended to fall within the scope of the claimed subject matter. The above, as well as additional objects, features, and advantages of the present disclosure will become more apparent from the following detailed description when read in conjunction with the accompanying drawings. Like reference numerals generally refer to like parts or elements throughout the present disclosure.

FIG. 1 shows a schematic diagram of a computing device 100 according to one embodiment of the invention;

FIG. 2 illustrates a flow diagram of a reverse debug method 200 in accordance with one embodiment of the present invention;

FIG. 3 illustrates a flow diagram of a debug method 300 in accordance with one embodiment of the present invention;

FIG. 4 shows a schematic diagram of a debug system 400 in accordance with one embodiment of the present invention;

FIG. 5 illustrates a schematic diagram of displaying a timeline and event list on an integrated development application interface in accordance with one embodiment of the invention.

Detailed Description

Exemplary embodiments of the present disclosure will be described in more detail below with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be embodied in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

FIG. 1 shows a schematic diagram of a computing device 100 according to one embodiment of the invention. As shown in FIG. 1, in a basic configuration, computing device 100 includes at least one processing unit 102 and a system memory 104. According to one aspect, the processing unit 102 may be implemented as a processor, depending on the configuration and type of computing device. The system memory 104 includes, but is not limited to, volatile storage (e.g., random access memory), non-volatile storage (e.g., read only memory), flash memory, or any combination of such memories. According to one aspect, an operating system 105 is included in system memory 104.

According to one aspect, operating system 105 is suitable, for example, for controlling the operation of computing device 100. Further, examples are practiced in connection with a graphics library, other operating systems, or any other application program and are not limited to any particular application or system. This basic configuration is illustrated in fig. 1 by those components within the dashed line. According to one aspect, computing device 100 has additional features or functionality. For example, according to one aspect, computing device 100 includes additional data storage devices (removable and/or non-removable) such as, for example, magnetic disks, optical disks, or tape. Such additional storage is illustrated in fig. 1 by removable storage device 109 and non-removable storage device 110.

As set forth hereinabove, according to one aspect, the program module 103 is stored in the system memory 104. According to one aspect, program modules 103 may include one or more applications, the invention is not limited in the type of application, for example, the application may include: email and contacts applications, word processing applications, spreadsheet applications, database applications, slide show applications, drawing or computer-aided application, web browser applications, etc.

According to one aspect, program module 103 may include a plurality of program instructions adapted to perform inverse debugging method 200 and/or debugging method 300 of the present invention in order for computing device 100 to perform inverse debugging method 200 and/or debugging method 300 of the present invention.

According to one aspect, the examples may be practiced in a circuit comprising discrete electronic components, a packaged or integrated electronic chip containing logic gates, a circuit utilizing a microprocessor, or on a single chip containing electronic components or a microprocessor. For example, examples may be practiced via a system on a chip (SOC) in which each or many of the components shown in fig. 1 may be integrated on a single integrated circuit. According to one aspect, such SOC devices may include one or more processing units, graphics units, communication units, system virtualization units, and various application functions, all of which are integrated (or "burned") onto a chip substrate as a single integrated circuit. When operating via an SOC, the functionality described herein may be operated via dedicated logic integrated with other components of computing device 100 on a single integrated circuit (chip). Embodiments of the invention may also be practiced using other techniques capable of performing logical operations (e.g., AND, OR, AND NOT), including but NOT limited to mechanical, optical, fluidic, AND quantum techniques. In addition, embodiments of the invention may be practiced within a general purpose computer or in any other circuit or system.

According to one aspect, the computing device 100 may also have one or more input devices 112, such as a keyboard, mouse, pen, voice input device, touch input device, and the like. Output device(s) 114 such as a display, speakers, printer, etc. may also be included. The foregoing devices are examples and other devices may also be used. Computing device 100 may include one or more communication connections 116 that allow communication with other computing devices 118. Examples of suitable communication connections 116 include, but are not limited to: RF transmitter, receiver and/or transceiver circuitry; universal Serial Bus (USB), parallel and/or serial ports.

The term computer readable media as used herein includes computer storage media. Computer storage media may include volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information (e.g., computer readable instructions, data structures, or program modules 103). System memory 104, removable storage 109, and non-removable storage 110 are all examples of computer storage media (i.e., memory storage). Computer storage media may include Random Access Memory (RAM), read Only Memory (ROM), electrically erasable read only memory (EEPROM), flash memory or other memory technology, CD-ROM, digital Versatile Disks (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other article of manufacture that can be used to store information and that can be accessed by computer device 100. According to one aspect, any such computer storage media may be part of computing device 100. Computer storage media does not include a carrier wave or other propagated data signal.

According to one aspect, communication media is embodied by computer readable instructions, data structures, program modules 103, or other data in a modulated data signal (e.g., carrier wave or other transport mechanism) and includes any information delivery media. According to one aspect, the term "modulated data signal" describes a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio Frequency (RF), infrared, and other wireless media.

In an embodiment according to the invention, computing device 100 is configured to perform inverse debugging method 200 and/or debugging method 300 according to the invention. Computing device 100 includes one or more processors and one or more readable storage media storing program instructions that, when configured to be executed by the one or more processors, cause the computing device to perform reverse debug method 200 and/or debug method 300 in embodiments of the present invention. Wherein, the reverse debugging of the debuggee program can be realized by executing the reverse debugging method 200 of the present invention.

FIG. 2 illustrates a flow diagram of a reverse debug method 200 in accordance with one embodiment of the present invention. The method 200 is adapted to be performed at a back end 420 (which may be implemented as the aforementioned computing device 100). Back end 420 is deployed with a reverse debug tool 425. Reverse debug tool 425 may provide reverse debug functionality and may record the memory data of the debuggee.

According to one embodiment of the invention, an integrated development application (IDE) of the front end 410 may implement event-based debugging analysis of a program by invoking reverse debug functionality provided by reverse debug tool 425 of the back end 420.

It should be noted that, many events, such as a window drag event, a mouse click event, a keyboard input event, etc., are triggered during the running process of the program, and these events are often the causes of program crash and jamming. When program breakdown and stuck phenomenon occur, if the running state of the program in the process of searching the program problem and diagnosing the program fault can be saved when the trigger event occurs, the method is used for searching the program problem and diagnosing the program fault when the program breakdown occurs, and the efficiency of fault diagnosis on the program can be greatly improved theoretically, and the problem is more accurately positioned. Through investigation, currently mainstream IDE does not support this function.

According to one embodiment of the invention, the process of reverse debug tool 425 (which may be abbreviated as rDbg) may be referred to as a reverse debug process (rDbg process).

As shown in fig. 2, method 200 includes steps 210-220.

First, in step 210, when an event is triggered during the running of the debuggee, a dump file corresponding to the event is generated in response to the event triggered during the running of the debuggee, so as to record the running state of the debuggee at the time point triggered by the event (i.e., the running state when the event is triggered). Here, the event may be mapped to the dump file.

Thus, when an event is triggered in the running process of the debugged program, event-level recording of a key point (event-triggered time point) of the running state in the running process of the debugged program is realized through the dump file.

It should be noted that, in step 210 of the present invention, when an event is triggered, recording of the event triggered during the running process of the debuggee is implemented through the dump file, and specifically, the event data recorded in the dump file includes the running state information of the debuggee at the time point triggered by the event. And, the event and the dump file can be mapped so as to select the dump file corresponding to the event.

In step 220, by reading the dump file, the running state of the debuggee at the event-triggered point in time may be played back according to the dump file, so as to determine the failure of the debuggee.

Specifically, by parsing the dump file, event data in the dump file may be read, and according to the event data in the dump file (including running state information of the debuggee program at the event-triggered time point), the running state of the debuggee program at the corresponding event-triggered time point is played back, so as to determine a fault of the debuggee program. Thus, fault diagnosis of the debuggee program is realized to locate errors and problems of the debuggee program.

In one embodiment of the present invention, in order to improve the storage efficiency of event data, a plurality of event data involved in one recording operation may be stored in one dump file. That is, in step 210, dump files corresponding to the plurality of events may be generated according to the plurality of events triggered during the running process of the debuggee program. In this way, the dump file contains a plurality of event data corresponding to a plurality of events.

Here, a plurality of events may be mapped with the dump file.

It should be noted that, the present invention automatically generates the dump file to record the running state at the time of event triggering (i.e. snapshot is performed on the running state at the time of event triggering) in an event triggering manner, so that by storing and reading the dump file, a developer can be assisted to locate a program error to determine a fault of the program, and reverse debugging playback at the event level is realized.

According to one embodiment of the invention, the types of events include System call events (syscall events), D-Bus events, window events, signal events (Signal events). Here, the Window event is an X11 (X Window System 11, a bitmap display Window System, X represents the X protocol, 11 is the protocol version number. X protocol is mainly composed of X server and X client) event. Window events include, for example, window drag events and mouse shortcut operation events.

In one embodiment, the event triggered during the running of the debuggee may be a system call event. When the event is a system call event, in step 210, in response to an event triggered in the running process of the debugged program, a dump file corresponding to the event is generated to record the running state of the debugged program at the time point triggered by the event, which may specifically include the following steps.

First, one sub-process (sub-process of the reverse debug process) can be created by the reverse debug process (rDbg process) using fork. In this way, the reverse debug process may act as a parent process to the child process.

Subsequently, a debuggee is started in the sub-process, and after the debuggee is started, the debuggee (as a new program) may overlay the sub-process. Here, in the sub-process, the debuggee may be started using the execute function. It should be noted that, execution is used to start a new program (new stack and data segment) in the sub-process to overwrite the current process.

The reverse debug process (i.e. parent process) may then monitor the child process to enable monitoring of the debuggee. Here, the actual monitoring is of the debuggee, specifically, the system call event of the debuggee.

In one implementation, after creating a sub-process by the reverse debug process, the reverse debug process may obtain the process number (child) of the sub-process. In this way, the reverse debug process (parent process) may call the ptrace function (process trace) and pass in the process number of the child process to monitor the child process. Here, the ptrace function is used by the parent process to control the child process from which the relevant internal state and data may be obtained. The basic principle of the ptrace function is as follows: when the ptrace function is used for tracking, all signals (except SIGKILL) sent to the tracked child process are forwarded to the parent process, and the child process is blocked, and the state of the child process is marked as task_track by the system. Thus, after the parent process receives the signal, the stopped child process can be checked and modified, and then the child process can continue to run.

Finally, when a system call event is triggered in the running process of the subprocess (actually the debuggee), a dump file corresponding to the system call event is generated in response to the system call event triggered in the running process of the subprocess (actually the debuggee), so that the running state of the debuggee at the time point triggered by the system call event is recorded through the dump file.

Here, in one implementation, a traceProcess function may be invoked to save a current (when a system call event triggers) memory snapshot of a sub-process, and compress the memory snapshot, so that a dump file corresponding to the system call event may be generated and stored locally on the computing device.

In one embodiment, the time stamp of the event trigger point in time may be obtained first when the dump file corresponding to the event is generated. Then, a dump file corresponding to the event is generated based on the timestamp. Thus, the dump file may also record the timestamp of the event trigger.

In one implementation, a vDSO (virtual dynamic shared object) virtual dynamic library may be utilized to obtain a timestamp of the time point of the event trigger. It should be noted that, the vDSO virtual dynamic library is used to improve the running efficiency of the program and reduce frequent system calls. The vDSO virtual dynamic library may first map an area in the process' memory, dump the address mapping of the vDSO virtual dynamic library into a so file, where multiple system call functions may be recorded. In the reverse debugging process, because the event triggering is frequent, the time stamp (the time stamp of the time point of acquiring the event triggering) needs to be recorded for each event, and the efficiency of acquiring the time stamp can be improved through the vDSO virtual dynamic library, so that the performance consumption of acquiring the time stamp is reduced.

In one embodiment, in the method 200 of the present invention, for each dump file generated, the dump file may be stored based on the type and the timestamp of the corresponding event, so that not only can the event be classified and recorded, but also the user can conveniently select the dump file of the corresponding event according to the time information.

It should be noted that, according to the embodiment of the present invention, by stamping the dump file with a timestamp, it is realized that the dump file corresponding to each event is arranged according to the time line operated by the debugged program, so that the user searches and selects the corresponding event according to the time information, so that the running state of the debugged program at the event-triggered time point can be played back according to the dump file corresponding to the event.

In one real-time example, events triggered during the running of the debuggee may include D-Bus events, window events, signal events. D-Bus events, window events and signal events can be realized based on the pre-load technology, and the generation of the events is triggered according to the function call state by piling the called function library. It should be noted that the signal event corresponds to most of the errors in the program run time, including the most common segment errors. Therefore, by recording events triggered in the running process of the program by the dump file, playback debugging of the program faults which are difficult to debug can be realized, so that the faults can be rapidly positioned and solved.

For example, for D-Bus functions, x11 functions, piling can be performed by LD_PRELOAD technology, and during function call, memory state is dumped by calling dump_memory function of the procdial module. Here, the D-Bus function includes, for example: dbus_connection_send_with_reply (for queuing messages to be sent, as with dbus_connection_send (), but also returning a dbus_connection call for receiving replies to messages), dbus_connection_call_step_reply (for obtaining replies, returning NULL if no replies have been received), dbus_connection_pop_message (for returning the first received message from the incoming message queue, deleting it from the queue), dbus_connection_send (for adding messages to the outgoing message queue).

The x11 function includes, for example: xgetEventData (for retrieving and releasing additional event data through cookies), xnxtevent (for copying the first event in the event queue into the specified XEvent structure and then deleting it from the queue, xnxtevent () will flush the output buffer and block if the event queue is empty until an event is received), xcb _wait_for_event (for blocking until an event is queued in the X server and then dequeued from the queue).

It should be noted that, the proccdump module exports the memory information through the snapshot export and/or the process data under the proc/directory. For example, by obtaining a "/proc/$pid/mem" file (pid is the process number of the debuggee) and writing it to a dump file (dump file).

It should be noted that, the ld_reload environment variable is used for loading the dynamic library, and the loading sequence is as follows: LD_PRELOAD > LD_LIBRARY_PATH >/etc/LD so cache >/lib >/usr/lib. Code can be injected into a specific library by a pre load technique to achieve piling.

In one embodiment of the invention, capture of D-Bus events, window events, may be accomplished using LD_PRELOAD environment variables.

Specifically, in step 210, a D-Bus event or window event triggered during the running of the debuggee may be captured by the LD_PRELOAD environment variable. And then, responding to the D-Bus event or window event triggered in the running process of the debugged program, and generating a dump file corresponding to the D-Bus event or window event so as to record the running state of the debugged program at the time point triggered by the D-Bus event or window event.

According to the reverse debugging method 200 of the present invention, when an event is triggered during the running of a debuggee program, a dump file corresponding to the event is generated to record the running state of the debuggee program at the event-triggered time point, so that the running state of the debuggee program at the event-triggered time point can be played back according to the dump file, so as to determine the fault of the debuggee program. Therefore, according to the debugging scheme of the invention, fault diagnosis of the debugged program can be realized, and the problem of the debugged program is located. The invention can automatically record the running state of the event trigger through the event trigger, realize the reverse debugging of the event level, improve the efficiency of fault diagnosis on the program and more accurately locate the program problem. Compared with the IDE in the prior art which can only record continuous code fragments at a certain position, the event-level reverse debugging scheme realized by the invention can carry out dump operation at any position operated by a debugged program.

Further, according to the reverse debugging method 200 of the present invention, by stamping the dump files with a timestamp, it is achieved that the events corresponding to each dump file are arranged according to the time line operated by the debugged program, so that the user selects the corresponding event according to the time information, and thus the running state of the debugged program at the time point triggered by the event can be played back according to the dump file corresponding to the event.

In addition, according to the reverse debugging method 200 of the present invention, the timestamp when the event is triggered is obtained by using the vDSO virtual dynamic library, so that the efficiency of obtaining the timestamp can be improved, and the performance consumption of obtaining the timestamp can be reduced.

FIG. 3 illustrates a flow diagram of a debug method 300 in accordance with one embodiment of the present invention. The debugging method 300 is adapted to be executed at a front end 410 (which may be implemented as the aforementioned computing device 100), the front end 410 being communicatively coupled to a back end 420 for invoking the reverse debugging functionality provided by a reverse debugging tool 425 (rDbg) of the back end 420.

As previously described, back end 420 may execute reverse debug method 200 via reverse debug tool 425 to generate dump files corresponding to events (and in particular, may generate dump files corresponding to multiple events) according to reverse debug method 200.

FIG. 4 shows a schematic diagram of a debug system 400 in accordance with one embodiment of the present invention. As shown in fig. 4, debug system 400 includes front end 410, back end 420. Front end 410 may be communicatively coupled to back end 420 and may specifically communicate based on the DAP protocol. Wherein front end 410 is configured to perform the debugging method 300 of the present invention and back end 420 is configured to perform the inverse debugging method 200 of the present invention. Front end 410, back end 420 may each be implemented as computing device 100 shown in fig. 1 to cause computing device 100 to perform inverse debugging method 200 and/or debugging method 300 of the present invention.

In one embodiment, backend 420 includes a reverse debug tool 425, which reverse debug tool 425 may be configured to perform the reverse debug method 200 of the present invention.

In one embodiment, back end 420 further includes a debug adapter 421, and front end 410 may communicate with a reverse debug tool 425 of back end 420 via debug adapter 421 of back end 420 (adapting DAP protocol) to invoke reverse debug functionality provided by reverse debug tool 425.

In one embodiment of the invention, front end 410 may include an integrated development application (IDE) that may be configured to perform debug method 300 of the present invention. Also, front end 410 (integrated development application) may integrate reverse debug plugin 411, through which reverse debug plugin 411 may invoke reverse debug tool 425 of back end 420 (via debug adapter 421) to enable integration of reverse debug functionality into the IDE. Here, the generation and parsing logic of the interface and dump file of the parameter configuration, event display, etc. of the reverse debug may be written into the reverse debug plug-in 411.

In one embodiment of the invention, front end 410 (reverse debug plug-in 411) may call reverse debug tool 425 of back end 420 to perform step 210 described previously to initiate a reverse debug record function. When the reverse debug logging function is enabled, the debuggee may run until the debuggee is turned off. The inverse debug tool 425 of the backend 420, by executing the logic of step 210 described above, may run the debuggee program, and record all events (which may include multiple events) triggered by the debuggee program during the run (during the period from startup to shutdown) to generate dump files corresponding to the multiple events triggered by the debuggee program during run.

In one embodiment, the integrated development application of front end 410 may invoke the inverse debug tool 425 of back end 420 via the DAP protocol to simplify the interaction of front end 420 and back end 420.

In order to improve the storage efficiency of the event data, all the event data (a plurality of event data) involved in one recording operation may be stored in one dump file. That is, in step 210 of the method 200, dump files corresponding to a plurality of events may be generated according to a plurality of events triggered during the running process of the debuggee. In this way, the dump file contains a plurality of event data corresponding to a plurality of events. And, multiple events may be mapped to the dump file.

As shown in fig. 3, method 300 begins at step 310.

In step 310, the front end 410 may read the dump file through the inverse debug plug-in 411, traversing the event data(s) recorded in the dump file. Here, each event data may contain a time stamp of the corresponding event (i.e., a time stamp corresponding to a point of time when the event triggered).

In addition, the event data may record running state information of the debuggee program at the event-triggered time point.

In one embodiment, the reverse debug plugin 411 of the front end 410 may read the dump file by loading a library of functions (librdbg. So) and parse the dump file to obtain event data recorded in the dump file. Here, the inverse debug tool 425 of the back end 420 may be invoked to generate the library librdbg. So, so that the front end 410 may load the library, and load and parse the dump file based on the library librdbg. So to obtain event data recorded in the dump file.

Subsequently, in step 320, a respective event identification line is drawn at a corresponding position on the time axis according to the time stamp of each event to generate and display the time line. In particular, the timeline may be displayed on an interface of an integrated development application (IDE). In this way, a plurality of event identification lines can be presented on a time axis according to the time sequence triggered by the events based on the time line so as to be operated by a user, and the user is supported to position the events according to the event identification lines, so that interactivity is enhanced.

FIG. 5 illustrates a schematic diagram of displaying a timeline and event list on an integrated development application interface in accordance with one embodiment of the invention. As shown in fig. 5, the time line includes a time axis (horizontal line segment) and a plurality of event indication lines (vertical line segment), wherein the time line is a fixed interval incremental display, the starting point is a time (value of 0) when the program starts recording, and the step value may be 500ms.

As shown in fig. 5, a user may select an event at a corresponding time point based on a timeline displayed on the integrated development application interface, and request playback of the event by triggering an event identification line corresponding to the event. For example, in one embodiment, a user may trigger a playback request for an event by double clicking on an event identification line.

In step 330, the front end 410 may obtain event data corresponding to the event identification line in response to a playback request for an event triggered based on the event identification line (for example, by performing a double click operation on the event identification line), and perform a playback operation according to the event data to obtain debug information of the debugged program. Here, a fault of the debuggee program can be determined from the debug information, and a problem in the debuggee program is located.

In addition, in consideration of the fact that the event identification line is narrow in width, the event identification line is not easy to hit, and in one embodiment, the method can increase the redundancy width of the event identification line in the implementation process. For example, the event identification line has an abscissa of 100 and a redundancy width of 5, and a double click operation within the abscissa range 95-105 may trigger the event identification line.

In one embodiment of the invention, the user may also perform a zoom operation on the timeline on the integrated development application interface to zoom the timeline to a size that is appropriate for the user's operation (e.g., double-click operation event identification line).

Front end 410 (inverse debug plugin 411) may respond to a user's zoom request for the timeline, from which a step value may be determined, and from which the timeline is zoomed.

For example, in one implementation, as shown In FIG. 5, a toolbar (Tool) is included on the integrated development application interface, through which a user may trigger a Zoom request for a timeline by means of the Zoom In, zoom Out, and Zoom fit of the toolbar. Zoom achieves scaling of the time axis by changing the step value of the time axis.

In one embodiment, after traversing each event data recorded in the dump file, a corresponding event entry may also be generated according to detailed information of each event data, respectively. An event list may be generated and displayed based on each event entry. As shown in fig. 5, the event list including each event entry may be specifically displayed on the integrated development application interface. The event entry may contain, among other things, details of the event, such as the event type, the time stamp of the event, the call duration, etc.

In this embodiment, the user may also trigger a playback request for the corresponding event by double clicking on the event entry. The front end 410 (reverse debug plug-in 411) may acquire corresponding event data in response to a playback request for an event triggered by a user based on an event entry, and perform a playback operation according to the event data to acquire debug information of a debugged program.

In addition, as shown in FIG. 5, by filters in the toolbar, filtering can be done for event types (including D-Bus, signal, syscall, x events). By selecting a certain type of event, the user can display only the corresponding type of event in the event List (Even List). The < > in the toolbar is used to select the last or next event. The sort support orders by index, call duration. The edit box is written in the form of "[ sys sig x11] begin [, end ]", for example.

According to one embodiment of the invention, the event data may comprise memory snapshot data. Here, the memory snapshot data is coredump data subjected to compression processing.

In this embodiment, the step 330 of obtaining the event data corresponding to the event identification line, and performing playback operation according to the event data to obtain the debug information of the debugged program may specifically include the following steps.

First, the reverse debug plug-in 411 may determine a timestamp corresponding to the event identifier line triggered by the user, and obtain corresponding memory snapshot data from the dump file according to the timestamp corresponding to the event identifier line. Here, the timestamp corresponding to the event identification line may be input through an interface provided by the function library librdbg.so, so as to obtain the corresponding memory snapshot data from the dump file.

And then, obtaining the memory snapshot file by decompressing the memory snapshot data. Here, the decompressed position is, for example, tmp/rdbg.dump (i.e., the storage path of the memory snapshot file).

And finally, performing playback operation according to the memory snapshot file to acquire debugging information of the debugged program.

Debug plug-in 412 (debug) may also be included in an integrated development application (IDE) of front end 410, according to one embodiment of the present invention. The reverse debug plugin 411 may implement the debug function provided by the call debug plugin 412 by invoking the service interface provided in the debug plugin 412. Debug plug-in 412 of front end 410 may communicate with inverse debug tool 425 of back end 420 via debug adapter 421 of back end 420 (adapting DAP protocol).

In this embodiment, the reverse debug plugin 411 performs the playback operation according to the event data (e.g. the memory snapshot file) in step 330 by calling the service interface provided by the debug plugin 412 and entering the parameters of the full path of the debuggee, the reverse debug tool 425 parameters, the path of the core file (e.g. the memory snapshot file path is/tmp/rdbg. Dump), etc. to obtain the debug information of the debuggee.

In particular, inverse debug plugin 411 may invoke debug plugin 412 based on the service interface provided by debug plugin 412. Debug plug-in 412 may communicate with inverse debug tool 425 of back-end 420 via debug adapter 421 of back-end 420 (adapting DAP protocol).

When playback operation is performed according to the event data to acquire debug information of the debugged program, a debug flow of the adaptation ordinary program is as follows.

First, a provisioning request (including an initialization request, a set breakpoint request, a start request) may be sent to debug adapter 421 through debug plug-in 412 to be configured according to the provisioning request through debug adapter 421. In this way, the breakpoint can be set based on the provisioning request.

Next, debug plug-in 412 may send a debug request (configuration completion request) to debug adapter 421 in accordance with the event data to request to run the debuggee program from reverse debug tool 425 via debug adapter 421, reverse debug tool 425 halts debugging when the debuggee program runs to the breakpoint, and issues a stop signal to debug adapter 421.

Next, debug plug-in 412 may receive a stall signal message generated by debug adapter 421 from the stall signal package, and may hit a breakpoint from the stall signal message (obtain stall signal data). Here, the corresponding row may be located by the integrated development application, and the effect of the hit breakpoint may be displayed on the integrated development application interface.

Finally, debug plug-in 412 may send a request to debug adapter 421 to obtain debug information in order to obtain stack information and variable values for the debuggee from reverse debug tool 425 via debug adapter 421. Here, the debug information includes stack information and variable values.

It can be seen that the above steps can achieve obtaining debug information of a debuggee program. After the front end acquires the debugging information, the front end can display the debugging information on an integrated development application interface so that a user can check the debugging information and determine the fault of the debugged program according to the debugging information.

It should be noted that the debugging flow of coredump is different from the normal program. And when the event data contains memory snapshot data and playback operation is performed according to the decompressed memory snapshot file to acquire debugging information of the debugged program, the following debugging process can be executed.

First, the reverse debug plug-in 411 calls the debug plug-in 412, and only needs to send an initialization request and a start request to the debug adapter 421 through the debug plug-in 412. There is no need to send a debug request (configuration completion request).

Debug plugin 412 may then send a request to debug adapter 421 to obtain debug information from memory snapshot files to obtain thread information, stack information, and variable values for the debuggee program from reverse debug tool 425 via debug adapter 421, resulting in debug information containing thread information, stack information, and variable values.

After the front end acquires the debugging information, the front end can display the debugging information on an integrated development application interface so that a user can check the debugging information and determine the fault of the debugged program according to the debugging information.

In one embodiment, before executing the debug flow, it may first be determined whether the debug object (event data) is a memory snapshot file, and if so, the request for obtaining debug information is directly sent without sending a debug request (configuration completion request).

In one embodiment of the present invention, for each generated dump file (dump file), the storage path of the dump file may be generated based on the name of the debuggee program corresponding to the dump file, the number of times the debuggee program is recorded (i.e., the number of event triggers), and the process number of the debuggee program. The dump file may then be stored based on the deposit path. In other words, the storage path (parameter) of the dump file may include the name, the number of records, and the process number of the debuggee program corresponding to the dump file.

In one implementation, the deposit path of the dump file is, for example, ".local/share/rDbg/$debugeName- $number/dump $processID". Where debugename represents the name of the debuggee, number is used to identify how many times the debuggee was recorded (i.e., the number of times the debuggee was recorded), and processID represents the process number of the debuggee. Assuming that the debuggee program is named Demo, the process number is 1234, and the debuggee program is recorded for the first time, the corresponding dump file has a storage path of ". Local/share/rDbg/Demo-1/dump1234".

In addition, to facilitate finding the last recording when playback is performed based on the dump file, a link folder "last-track" may be created under the ". Local/share/rDbg/" directory, and the actual location may point to the folder of the last recording, for example, may point to the aforementioned Demo-1 folder. In performing a playback operation, the debuggee needs to be passed to the reverse debug tool 425 as a parameter, so that a full path of the debuggee needs to be recorded under the ". Local/share/rDbg/" directory, where the file name is, for example, debug- $processid, and the recorded full path is, for example: the/debugee/full-path.

In one embodiment of the invention, the dump file may store event data based on a predetermined data structure. The predetermined data structure may specifically include: the time stamp at the time of event triggering (i.e., the time stamp corresponding to the time point of event triggering), the event type, the number of threads (thread_num, the number of threads present in the process at the time of event triggering), the thread number at the time of event triggering (current_tid), and the memory snapshot data (i.e., the compressed coredump data, which can be dynamically decompressed and overlaid/tmp/rdbg.dump file before use). In this way, the data structure of the dump file is such that it starts with a timestamp and follows the event type, thread number and memory snapshot data at the time of event triggering after the timestamp.

It is noted that the memory snapshot data in the dump file is obtained by compressing the coredump file, so as to reduce the space occupation.

In one example, the timestamp format is, for example, YYYY: MM: dd HH: MM: ss: SSS.

In one embodiment, event types may include System call events (syscall events), D-Bus events, window events, signal events (Signal events). Here, the window event is an X11 (X Window System 11, a bitmap display window system, X represents the X protocol, 11 is the protocol version number. X protocol consists essentially of X server and X client) event. Window events include, for example, window drag events and mouse shortcut operation events. Wherein each event type may comprise a base type (large type) and a plurality of sub-divided event types may be superimposed on the base type, such that filtering of event types may be achieved by the base type and the sub-divided event types are used to achieve finer filtering of events.

According to the debugging method 300 of the present invention, the front-end (IDE) may call the back-end's reverse debugging tool to generate dump files corresponding to a plurality of events triggered during the running of the debuggee. By reading the dump file, traversing each event data recorded in the dump file, drawing a corresponding event identification line according to the corresponding position of the time stamp of each event on the time axis, and generating and displaying the time line. The user can trigger a playback request of the event based on the event identification line, and the front end responds to the playback request to acquire corresponding event data and perform playback operation so as to acquire debugging information of the debugged program. Therefore, the invention can integrate the reverse debugging function of the rear end into the front end (IDE), realize visual operation, promote usability, and view stack information and variable values of the debugged program based on the interface. In addition, the method and the device for displaying the event identification lines on the time axis based on the time line display the event identification lines on the time axis according to the time sequence triggered by the event by generating the time line, so that a user can conveniently select and position the corresponding event according to the time information, the efficiency of checking the event information is improved, and the interactivity is enhanced.

The various techniques described herein may be implemented in connection with hardware or software or, alternatively, with a combination of both. Thus, the methods and apparatus of the present invention, or certain aspects or portions of the methods and apparatus of the present invention, may take the form of program code (i.e., instructions) embodied in tangible media, such as removable hard drives, U-drives, floppy diskettes, CD-ROMs, or any other machine-readable storage medium, wherein, when the program is loaded into and executed by a machine, such as a computer, the machine becomes an apparatus for practicing the invention.

In the case of program code execution on programmable computers, the mobile terminal will generally include a processor, a storage medium readable by the processor (including volatile and non-volatile memory and/or storage elements), at least one input device, and at least one output device. Wherein the memory is configured to store program code; the processor is configured to perform the reverse debug method and/or debug method of the present invention in accordance with instructions in said program code stored in the memory.

By way of example, and not limitation, readable media comprise readable storage media and communication media. The readable storage medium stores information such as computer readable instructions, data structures, program modules, or other data. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism and includes any information delivery media. Combinations of any of the above are also included within the scope of readable media.

In the description provided herein, algorithms and displays are not inherently related to any particular computer, virtual system, or other apparatus. Various general-purpose systems may also be used with examples of the invention. The required structure for a construction of such a system is apparent from the description above. In addition, the present invention is not directed to any particular programming language. It will be appreciated that the teachings of the present invention described herein may be implemented in a variety of programming languages, and the above description of specific languages is provided for disclosure of enablement and best mode of the present invention.

In the description provided herein, numerous specific details are set forth. However, it is understood that embodiments of the invention may be practiced without these specific details. In some instances, well-known methods, structures and techniques have not been shown in detail in order not to obscure an understanding of this description.

Similarly, it should be appreciated that in the foregoing description of exemplary embodiments of the invention, various features of the invention are sometimes grouped together in a single embodiment, figure, or description thereof for the purpose of streamlining the disclosure and aiding in the understanding of one or more of the various inventive aspects. However, the disclosed method should not be construed as reflecting the intention that: i.e., the claimed invention requires more features than are expressly recited in each claim. Thus, the claims following the detailed description are hereby expressly incorporated into this detailed description, with each claim standing on its own as a separate embodiment of this invention.

Those skilled in the art will appreciate that the modules or units or components of the devices in the examples disclosed herein may be arranged in a device as described in this embodiment, or alternatively may be located in one or more devices different from the devices in this example. The modules in the foregoing examples may be combined into one module or may be further divided into a plurality of sub-modules.

Those skilled in the art will appreciate that the modules in the apparatus of the embodiments may be adaptively changed and disposed in one or more apparatuses different from the embodiments. The modules or units or components of the embodiments may be combined into one module or unit or component and, furthermore, they may be divided into a plurality of sub-modules or sub-units or sub-components. Any combination of all features disclosed in this specification (including any accompanying claims, abstract and drawings), and all of the processes or units of any method or apparatus so disclosed, may be used in combination, except insofar as at least some of such features and/or processes or units are mutually exclusive. Each feature disclosed in this specification (including any accompanying claims, abstract and drawings), may be replaced by alternative features serving the same, equivalent or similar purpose, unless expressly stated otherwise.

Furthermore, those skilled in the art will appreciate that while some embodiments described herein include some features but not others included in other embodiments, combinations of features of different embodiments are meant to be within the scope of the invention and form different embodiments.

Furthermore, some of the embodiments are described herein as methods or combinations of method elements that may be implemented by a processor of a computer system or by other means of performing the functions. Thus, a processor with the necessary instructions for implementing the described method or method element forms a means for implementing the method or method element. Furthermore, the elements of the apparatus embodiments described herein are examples of the following apparatus: the apparatus is for carrying out the functions performed by the elements for carrying out the objects of the invention.

As used herein, unless otherwise specified the use of the ordinal terms "first," "second," "third," etc., to describe a general object merely denote different instances of like objects, and are not intended to imply that the objects so described must have a given order, either temporally, spatially, in ranking, or in any other manner.

While the invention has been described with respect to a limited number of embodiments, those skilled in the art, having benefit of the above description, will appreciate that other embodiments are contemplated within the scope of the invention as described herein. Furthermore, it should be noted that the language used in the specification has been principally selected for readability and instructional purposes, and may not have been selected to delineate or circumscribe the inventive subject matter. Accordingly, many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the appended claims. The disclosure of the present invention is intended to be illustrative, but not limiting, of the scope of the invention, which is defined by the appended claims.

Claims (14)

1. A reverse debug method, comprising:

responding to an event triggered in the running process of a debugged program, and generating a dump file corresponding to the event so as to record the running state of the debugged program at the time point triggered by the event;

and playing back the running state of the debuggee program at the event-triggered time point according to the dump file so as to determine the fault of the debuggee program.

2. The method of claim 1, wherein the event comprises a system call event; responding to an event triggered in the running process of a debugged program, generating a dump file corresponding to the event so as to record the running state of the debugged program at the time point triggered by the event, and comprising the following steps:

creating a sub-process through the reverse debugging process;

starting a debuggee program in the subprocess so that the debuggee program covers the subprocess;

monitoring the subprocesses to realize monitoring of the debugged program;

and responding to a system call event triggered in the running process of the subprocess, and generating a dump file corresponding to the system call event so as to record the running state of the debugged program at the time point triggered by the system call event.

3. The method of claim 1 or 2, wherein generating the dump file corresponding to the event comprises:

generating dump files corresponding to a plurality of events according to the plurality of events triggered in the running process of the debugged program, wherein the dump files contain a plurality of event data;

according to the dump file, playing back the running state of the debuggee program at the time point triggered by the event, including:

Reading event data in the dump file;

and playing back the running state of the debugged program at the time point triggered by the event according to the event data.

4. The method of any of claims 1-3, wherein generating a dump file corresponding to the event comprises:

acquiring a time stamp of the event triggering time point;

and generating a dump file corresponding to the event based on the timestamp.

5. A debugging method performed at a front end, the front end being communicatively connected to a back end, the back end being adapted to generate dump files corresponding to a plurality of events triggered during the running of a debugged program according to the method of any one of claims 1-4; the method comprises the following steps:

reading a dump file, traversing each event data recorded in the dump file, wherein the event data comprises a time stamp of an event;

drawing corresponding event identification lines at corresponding positions on a time axis according to the time stamp of each event to generate and display a time line;

and responding to a playback request of the event triggered based on the event identification line, acquiring corresponding event data, and performing playback operation according to the event data to acquire debugging information of the debugged program.

6. The method of claim 5, wherein the front end comprises an integrated development application including a debug plug-in therein, the debug plug-in adapted to communicate with a reverse debug tool of the back end via a debug adapter; performing playback operation according to the event data to obtain debugging information of the debugged program, including:

sending a debugging request to a debugging adapter according to the event data through a debugging plug-in, so as to request the debugged program to be run to the reverse debugging tool through the debugging adapter, wherein the reverse debugging tool is suitable for sending a stop signal to the debugging adapter when the debugged program runs to a breakpoint;

receiving a stop signal message generated by the debugging adapter according to the stop signal package, and hitting a breakpoint according to the stop signal message;

a request to obtain debug information is sent to a debug adapter to obtain stack information and variable values for the debuggee from the reverse debug tool via the debug adapter.

7. The method of claim 5, wherein the event data comprises memory snapshot data;

obtaining corresponding event data, and performing playback operation according to the event data to obtain debugging information of a debugged program, wherein the method comprises the following steps:

Acquiring corresponding memory snapshot data from the dump file according to the timestamp corresponding to the event identification line;

decompressing the memory snapshot data to obtain a memory snapshot file;

and performing playback operation according to the memory snapshot file to acquire debugging information of the debugged program.

8. The method of claim 7, wherein performing playback operations according to the memory snapshot file to obtain debug information of the debuggee program comprises:

and sending a request for acquiring debugging information to a debugging adapter according to the memory snapshot file through a debugging plug-in, so as to acquire the thread information, stack information and variable values of the debugged program from the reverse debugging tool through the debugging adapter.

9. The method of any of claims 5-8, further comprising:

in response to a scaling request for the timeline, a step value is determined from the scaling request and the timeline is scaled according to the step value.

10. The method of any of claims 5-9, wherein after traversing each event data recorded in the dump file, further comprising:

generating corresponding event items according to the detailed information of each event data;

And generating an event list according to each event item and displaying the event list.

11. The method of claim 10, further comprising:

and responding to a playback request for the event triggered based on the event item, acquiring corresponding event data, and performing playback operation according to the event data to acquire debugging information of the debugged program.

12. The method of any of claims 5-11, further comprising:

and calling the reverse debugging tool at the back end to generate dump files corresponding to a plurality of events triggered in the running process of the debugged program.

13. A computing device, comprising:

at least one processor; and

a memory storing program instructions, wherein the program instructions are configured to be adapted to be executed by the at least one processor, the program instructions comprising instructions for performing the method of any of claims 1-12.

14. A readable storage medium storing program instructions which, when read and executed by a computing device, cause the computing device to perform the method of any of claims 1-12.