Program debugging device, program debugging method, and program development product

Abstract

The invention relates to the technical field of program debugging, and provides a program debugging device, a program debugging method and a program development product. The program debugging method comprises the following steps: in response to a first debugging operation for a target program, debugging the target program to pass through a first target code position of a first code file corresponding to the target program; at least a first timeline and a second timeline corresponding to the first target code location are displayed, the first timeline corresponding to a first thread running the target program, and the second timeline corresponding to a second thread running the target program. Under the condition that a program relates to multi-thread concurrent execution, a program debugging process is displayed by using thread branching display corresponding to a plurality of timelines such as at least a first timeline and a second timeline and combining breakpoints on the timelines and code line information of the breakpoints; the visualization effect of the debugging function of the integrated development environment is improved, and the efficiency that developers locate exceptions / problems existing in codes is improved.

Description

Technical Field

[0001] The embodiments of the present application relate to the technical field of program debugging, and in particular, to a program debugging device, a program debugging method, and a program development product. Background Art

[0002] In program development, after developers complete code writing, they will perform various debugging operations on the code to find the defects in the code through debugging. Among them, breakpoint debugging is a debugging technique that pauses the execution during the program debugging process and allows developers to gradually check the code corresponding to the program. Developers can set key points (i.e., breakpoints) in the code of the program through an Integrated Development Environment (IDE). When debugging or running the program through the code at the key points, the execution will pause. During the pause, developers can view the debugging information corresponding to the code (such as: the variable values of variables to be observed, stack information, etc.). The debugging information helps developers understand the defects in the code executed before the key points. However, if the code with key points set involves a scenario of multi-threaded concurrent execution, when debugging the program through the code at the key points, it is impossible to distinguish the specific thread corresponding to the variable to be observed, so it brings difficulties to the debugging of the program with key points set. Summary of the Invention

[0003] The present application provides a program debugging device, a program debugging method, and a program development product.

[0004] In a first aspect, the present application provides a program debugging method, which is applied to an integrated development environment. The method includes:

[0005] In response to a first debugging operation on a target program, debug the target program through a first target code position of a first code file corresponding to the target program; display at least a first timeline and a second timeline corresponding to the first target code position, where the first timeline corresponds to a first thread running the target program, and the second timeline corresponds to a second thread running the target program.

[0006] In this specification, the integrated development environment here can be a tool for developers or testers to develop or debug a target program. The target program here can be referred to as a program, a program to be debugged, or a program under debugging. The first debugging operation is a debugging operation performed on the target program after the developer uses the integrated development environment to open the code of the target program. The target program can correspond to at least a first code file. The first target code position here can be a code line in the first code file. For example, the first target code position can be a code line in the first code file where a second type of key point is set. During the debugging process of the multi-threaded concurrent execution of the target program, the integrated development environment can start at least a first thread and a second thread, a first timeline and a second timeline, and display the first timeline corresponding to the first thread and the second timeline corresponding to the second thread in the debugging area of the integrated development environment. At least one first breakpoint and the first code line information corresponding to the first breakpoint can be displayed on the first timeline, and at least one second breakpoint and the second code line information corresponding to the second breakpoint can be displayed on the second timeline. The first breakpoint and the second breakpoint correspond to code positions in the first code file that are before the first target code position. That is to say, the first breakpoint and the second breakpoint can be code lines in the first code file where a first type of key point is set, and the code lines corresponding to the first breakpoint and the second breakpoint are before the code line corresponding to the first target code position.

[0007] Through the above program debugging method, in the case where the program involves multi-threaded concurrent execution, two methods are used to display the process of program debugging, namely, the thread split display corresponding to multiple timelines such as at least a first timeline and a second timeline, and the combination of breakpoints on the timeline and the code line information of the breakpoints, which enhances the efficiency of using the integrated development environment for program debugging; at the same time, it improves the visualization effect of the debugging function of the integrated development environment in a multi-threaded scenario and improves the efficiency of developers in locating anomalies / problems in the code.

[0008] In a possible implementation of the first aspect above, the first timeline includes at least one first breakpoint and the first code line information corresponding to the first breakpoint, and the second timeline includes at least one second breakpoint and the second code line information corresponding to the second breakpoint, where the first breakpoint and the second breakpoint correspond to code positions in the first code file that are before the first target code position.

[0009] In this specification, at least one first breakpoint and the first code line information corresponding to the first breakpoint can be displayed on the first timeline, and at least one second breakpoint and the second code line information corresponding to the second breakpoint can be displayed on the second timeline. The first breakpoint and the second breakpoint correspond to code positions in the first code file that are before the first target code position.

[0010] It can be seen that when the first thread and the second thread run the target program through the first target code position, by simultaneously displaying the breakpoints before the first target code position and the code line information corresponding to the breakpoints on the time line, developers can observe the debugging information corresponding to different key points in the same thread through the code lines of the key points during the debugging process.

[0011] In a possible implementation of the above first aspect, the first breakpoint and the second breakpoint correspond to the same code line in the first code file, and the first code line information and the second code line information are the same.

[0012] In this specification, the code lines in the first code file corresponding to the first breakpoint and the second breakpoint may also be the same, and the first code line information and the second code line information displayed on the first time line and the second time line are also the same.

[0013] It can be seen that due to the different thread behaviors of the first thread and the second thread on different lines, the debugging information corresponding to the same code line for different threads is also different. When the first thread and the second thread run the target program through the first target code position, the first breakpoint and the second breakpoint can be respectively displayed on the first time line and the second time line for the same code line in the first code file, so that developers can observe the different debugging information corresponding to the same breakpoint in different threads through the code lines of the key points during the debugging process.

[0014] In a possible implementation of the above first aspect, the first breakpoint corresponds to the first hit time information, and the first hit time information represents the time when the first thread runs the target program through the first breakpoint; the second breakpoint corresponds to the second hit time information, and the second hit time information represents the time when the second thread runs the target program through the second breakpoint.

[0015] It can be seen that if the times when the first thread and the second thread run the target program through the first breakpoint and the second breakpoint are different, then the first hit time information corresponding to the first breakpoint is also different from the second hit time information corresponding to the second breakpoint.

[0016] In a possible implementation of the above first aspect, the first time line is parallel to the second time line; the straight line passing through the starting positions of the first time line and the second time line is perpendicular to the first time line and perpendicular to the second time line; in the case where the first hit time information is different from the second hit time information: the straight line passing through the first breakpoint and the second breakpoint is not parallel to the straight line passing through the starting positions of the first time line and the second time line.

[0017] It can be seen that the starting positions of the first timeline and the second timeline displayed in the debugging area of the integrated development environment can be the same. That is, the straight line passing through the starting positions of the first timeline and the second timeline is perpendicular to the first timeline and perpendicular to the second timeline. When the first hit time information is different from the second hit time information, the position of the first breakpoint on the first timeline is different from the position of the second breakpoint on the second timeline. The different positions of the first breakpoint and the second breakpoint on the first timeline and the second timeline can more intuitively present the time when the first thread and the second thread run the target program through the first breakpoint and the second breakpoint.

[0018] In a possible implementation of the above first aspect, the first timeline includes first thread identification information, and the first thread identification information corresponds to the first thread; the second timeline includes second thread identification information, and the second thread identification information corresponds to the second thread.

[0019] It can be seen that the first thread identification information here can be the timeline identification of the first timeline, and the second thread identification information can be the timeline identification of the second timeline. For example: the first timeline and the second timeline can be represented by timeline 1 and timeline 2 respectively, and the numbers 1 and 2 can represent the order of time when the first thread and the second thread corresponding to the first timeline and the second timeline start.

[0020] In a possible implementation of the above first aspect, when debugging the target program passes through the first target code position of the first code file corresponding to the target program, the code area of the integrated development environment switches to display the first code file.

[0021] It can be seen that when the integrated development environment debugs the target program through the first target code position of the first code file, the code area of the integrated development environment displays the first code file. The code area of the integrated development environment can more intuitively present the first code file being debugged currently.

[0022] In a possible implementation of the above first aspect, it further includes: debugging the target program to pass through the second target code position of the first code file corresponding to the target program; displaying a third breakpoint and the third code line information corresponding to the third breakpoint on the first timeline, where the third breakpoint corresponds to the second target code position.

[0023] It can be seen that when the first thread debugs the target program and passes through the second target code position of the first code file corresponding to the target program, at least one third breakpoint and the third code line information corresponding to the third breakpoint can continue to be displayed on the first timeline. The code line corresponding to the third breakpoint here is located before the code line corresponding to the second target code position. During the continuous debugging of the target program, the breakpoints corresponding to the second target code positions after the first target code position will also be successively displayed on the timeline, providing more detailed debugging information of the target program.

[0024] In a possible implementation of the above first aspect, the third breakpoint corresponds to third hit time information, and the third hit time information represents the time when the first thread runs the target program through the third breakpoint. When the first hit time information is different from the third hit time information, the position of the third breakpoint on the first timeline is different from the position of the first breakpoint on the first timeline.

[0025] It can be seen that the first thread runs the target program through the first breakpoint and the third breakpoint successively. Therefore, when the first hit time information is different from the third hit time information, the position of the third breakpoint on the first timeline is different from the position of the first breakpoint on the first timeline, and the position of the third breakpoint on the first timeline can be after the position of the first breakpoint on the first timeline.

[0026] In a possible implementation of the above first aspect, it further includes: in response to a second debugging operation on the target program, debugging the target program from the first code file to the second code file corresponding to the target program and passing through the third target code position of the second code file; displaying at least one fourth breakpoint and the fourth code line information corresponding to the fourth breakpoint on the first timeline, and displaying at least one fifth breakpoint and the fifth code line information corresponding to the fifth breakpoint on the second timeline, where the fourth breakpoint and the fifth breakpoint correspond to the code positions in the second code file before the third target code position.

[0027] It can be seen that the second debugging operation here is the next debugging operation performed by the developer on the target program using the integrated development environment. The target program can correspond to at least the first code file and the second code file. During the debugging process of the target program, the target program can successively pass through the codes of the first code file and the second code file. The third target code position here can be a code line in the second code file. The fourth breakpoint and the fifth breakpoint can correspond to the code lines set in the second code file, and the code lines corresponding to the fourth breakpoint and the fifth breakpoint are located before the code line corresponding to the third target code position.

[0028] In a possible implementation of the above first aspect, the first line of code information is hidden on the first timeline, and the second line of code information is hidden on the second timeline.

[0029] It can be seen that when the first thread and the second thread debug the target program passing through the third target code position of the second code file, the code area of the integrated development environment switches to display the second code file. The first line of code information is hidden on the first timeline, and the second line of code information is hidden on the second timeline. The first timeline and the second timeline can only display the code line information of the fourth breakpoint and the fifth short line set in the currently displayed second code file in the integrated development environment, without displaying the code line information of the first breakpoint and the second breakpoint set in the non-currently displayed first code file. It can more accurately display the code line information corresponding to the breakpoint related to the currently running target program passing through the second code file.

[0030] In a possible implementation of the above first aspect, when the target program being debugged passes through the third target code position of the second code file, the code area of the integrated development environment switches to display the second code file.

[0031] It can be seen that when the integrated development environment debugs the target program passing through the third target code position of the second code file, the code area of the integrated development environment displays the second code file. The code area of the integrated development environment can more intuitively present the currently debugged second code file.

[0032] In a possible implementation of the above first aspect, it further includes: in response to a backtracking operation for the first breakpoint, the code area of the integrated development environment switches to display the first code file and the code of the first line of code information is displayed in the first code file in a highlighted manner.

[0033] It can be seen that the backtracking operation here can be that the developer backtracks the debugging information of the thread behavior corresponding to the first timeline by clicking on the first breakpoint on the first timeline. The code area of the integrated development environment can switch to display the first code file and present code highlighting in the first code file according to the first line of code information of the first breakpoint.

[0034] In a possible implementation of the above first aspect, it further includes: in response to a backtracking operation for the first breakpoint, the debug area of the integrated development environment displays the first debug information corresponding to the first breakpoint, where the first debug information includes at least one of the variable value of the first variable to be observed, the first thread identification information, the first hit time information, and the first line of code information.

[0035] In a possible implementation of the above first aspect, the first line of code information is displayed on the first time line and the fourth line of code information is hidden, and the second line of code information is displayed on the second time line and the fifth line of code information is hidden.

[0036] It can be seen that the first time line and the second time line can display only the line information of the first breakpoint and the second short line set in the first code file currently displayed in the integrated development environment, and do not display the line information of the fourth breakpoint and the fifth breakpoint set in the second code file that is not currently displayed. It can more accurately display the line information corresponding to the breakpoint related to the first code file passed by the currently running target program.

[0037] In a second aspect, the present application provides a program debugging device, which is applied to an integrated development environment, and is characterized in that

[0038] The program debugging device responds to a first debugging operation on a target program, and debugs the first target code position of the target program passing through the first code file corresponding to the target program;

[0039] The program debugging device displays at least a first time line and a second time line corresponding to the first target code position in a debugging area of the integrated development environment, where the first time line corresponds to a first thread running the target program, and the second time line corresponds to a second thread running the target program.

[0040] In a third aspect, the present application provides a computer-readable storage medium, including instructions that cause an electronic device to execute the data processing method in the first aspect or any one of the implementation manners when executed on the electronic device.

[0041] The beneficial effects of the above aspects can be referred to each other. BRIEF DESCRIPTION OF THE DRAWINGS

[0042] Figures 1(a) to 1(c) Shows an application scenario of an application interface of an integrated development environment according to an embodiment of the present application;

[0043] Figure 2 Shows a schematic diagram of the effect of thread splitting display and displaying line information of key points on a time line involved in a program debugging method according to an embodiment of the present application;

[0044] FIG. 3(a) shows a schematic diagram of the effect of an integrated development environment according to an embodiment of the present application showing multiple time lines corresponding to multiple threads;

[0045] Figures 3(b) to 3(e) Shows a schematic flow chart of a program debugging method according to an embodiment of the present application;

[0046] Figure 4Shows the architecture diagram of a program development product for the applicable program debugging method of the embodiments of the present application;

[0047] Figure 5 Shows the architecture diagram of the debugging module of the integrated development environment of the embodiments of the present application;

[0048] Figure 6 Shows the process interaction diagram between each functional module in the debugging module of the embodiments of the present application and the debugger;

[0049] Figure 7 Shows the functional schematic diagram of the timeline interface module in the debugging module of the embodiments of the present application;

[0050] Figure 8 Shows the process interaction diagram for implementing backtracking debugging information between each functional module in the debugging module of the embodiments of the present application and the debugger;

[0051] Figures 9(a) to 9(i) Exemplarily shows the application scenario schematic diagram of the integrated development environment for the applicable program debugging method of the embodiments of the present application;

[0052] Figures 10(a) to 10(e) Exemplarily shows the application scenario schematic diagram of the integrated development environment for the applicable program debugging method of the embodiments of the present application;

[0053] Figure 11 Exemplarily shows the structural schematic diagram of the electronic device in the embodiments of the present application. Detailed implementation manners

[0054] The technical solutions in the embodiments of the present application will be clearly and elaborately described below with reference to the accompanying drawings. Each of the following embodiments may be referred to each other.

[0055] It can be understood that the technical solution of the present application is applicable to an electronic device capable of running an integrated development environment. The electronic device may specifically be a personal computer (PC), an ultra-mobile personal computer (UMPC), a hardware server (including: an entry-level server, a workgroup-level server, a department-level server, and an enterprise-level server), and a cloud server. The electronic device may further include: terminal devices such as a tablet computer, a laptop computer, a computer, and a netbook.

[0056] Some terms related to the embodiments of the present application will be explained below.

[0057] Forward debugging: Forward debugging is a breakpoint debugging method that gradually traces the debugging process of program code. During the forward debugging of a program, the program starts executing from the starting point, and the debugger pauses at the breakpoints set in the code, allowing developers to gradually debug the program code, view the variable values of variables to be observed, and so on. Forward debugging can be used to troubleshoot problems such as logical errors and variable value errors in the code.

[0058] Reverse debugging: Reverse debugging is an enhanced capability of breakpoint debugging that allows developers to perform debugging operations in the opposite direction to forward debugging during the debugging process (such as returning to the previous line or the previous breakpoint position passed in the forward debugging process), which can effectively improve the development experience of using debugging functions and the efficiency of problem location. Reverse debugging technology is currently used in some debugging command-line tools and integrated development environments and can be used together with forward debugging. According to the position of returning to the debugging process in reverse debugging, reverse debugging can be divided into reverse breakpoint debugging and reverse single-step debugging, etc. Through these operations, developers can view the debugging information (which can also be said to be historical information) of the program that has been debugged. Reverse debugging can be used to reproduce complex problems that occur in forward debugging, such as multi-threaded problems, etc.

[0059] Timeline view: A timeline view is a view that shows the time attributes, time positions, and time sequences of something, and is usually used in software and hardware performance tuning tools, audio and video editing tools, etc.

[0060] The technical solution of the present application will be described below in combination with specific scenarios.

[0061] Figure 1(a) shows an application scenario of the application interface of an integrated development environment. As shown in Figure 1(a), the application interface 100 of the integrated development environment may include multiple functional areas, a toolbar area 101, a debugging area 102, a code area 103, an auxiliary display area 104, and a console area 105. Among them, the toolbar area 101 includes multiple controls for implementing the application functions of the integrated development environment, such as: query controls, debugging controls, etc. Among them, the query control is used to query information in the code. The debugging control is used to start the debugging of the program. The program here can also be called the target program.

[0062] The debugging area 102 is used to display the debugging information of the code corresponding to the program (variable values of variables to be observed, occupancy of system resources, thread information, stack information, etc.), and to provide timeline functions for various debugging of the code (such as: reverse debugging).

[0063] Developers / testers (hereinafter, developers will be taken as an example for illustration) can set key points (breakpoints) for the code in the code area 103. For example, key points can be set for a code line, which can also be referred to as a code location (e.g., 125). In some embodiments, the method of setting key points for the code may include: the developer performs a user operation on the code line 125 in the code displayed in the code area 103, such as double-clicking on the code line. In response to the user operation, an identifier 1031 of the key point is displayed at the position of code line 1:25 in the code area 103. During the process of the developer debugging the code, the key points can be displayed through the timeline function in the debugging area 102, that is, a label (Bookmark) is set for the above-mentioned key points (the key points corresponding to code line 125), and the labels are displayed on a single timeline in chronological order. If the developer sets multiple key points for the code, during the debugging process, the developer can see multiple labels on the timeline, and there is a timing relationship, that is, a sequential relationship, between the labels. The code area 103 can also display the code in the source code file currently displayed in the integrated development environment, as well as information such as the code line information (line number) corresponding to the code and code highlighting.

[0064] The auxiliary display area 104 can display the file name of the code in the code area 103 and the position of the currently displayed code snippet in the entire code.

[0065] The console area 105 is used to display the information generated after debugging the program, including: debugging result information, exception information, and so on.

[0066] In some embodiments, when the developer wants to trace back the debugging information corresponding to the key points in the debugging, the developer can directly select the corresponding label in the debugging area 102 for tracing back the debugging information. For example, click on the label on the timeline in the debugging area 102. At this time, the code area 103 will display the code of the key point corresponding to the label. For example, the code line where the key point corresponding to the label is located will be highlighted; at the same time, the debugging area 102 will also display the debugging information corresponding to the code, such as: the variable value of the variable to be observed corresponding to the code where the key point is set, stack information, code exception information, and so on.

[0067] However, during the process of program debugging by developers using the integrated development environment shown in FIG. 1(a), if the code involves multi-threaded concurrent execution, the timeline in the debugging area 102 in FIG. 1(a) cannot intuitively reflect the thread timing relationship. For example, FIG. 1(b) shows a schematic diagram of the debugging area 102 of the application interface of an integrated development environment displaying key points through the timeline function in a multi-threaded scenario. It can be seen that the debugging area 102 of the integrated development environment can display multiple key points through a single timeline. For example, it includes key points corresponding to thread 1 and key points corresponding to thread 2. That is, in a multi-threaded scenario, only the timing relationship between all key points can be reflected, but the relationship between threads and key points, as well as the timing relationship between key points corresponding to different threads, cannot be reflected. It is difficult to distinguish in the case of a large number of key points, and it is difficult to correspond the key points to specific code positions, and the visual positioning of multi-threaded problems cannot be effectively achieved.

[0068] To solve the above problems, an embodiment of the present application provides a program debugging method applied to an integrated development environment. In this method, during the process of debugging a program in the integrated development environment, thread information corresponding to key points set for the code of the program is obtained, and based on the thread information, a separate timeline is generated for each thread with corresponding key points. Among them, in a multi-threaded scenario, multiple timelines can be displayed, and the multiple timelines can be arranged in the chronological order of the start times of the corresponding threads. For example, the timeline corresponding to the thread that starts first is displayed on the left side of the timeline corresponding to the thread that starts later, and the multiple timelines can be arranged in parallel. Each timeline also includes a direction, and here the direction can be the chronological order of the time passed during the start of the debugging program, that is, the order of the time axis.

[0069] For example, FIG. 1(c) shows a schematic diagram of displaying key points through the timeline function in the debugging area 102 of the application interface of an integrated development environment in a multi-threaded scenario. It can be seen that the debugging area 102 of the integrated development environment displays the timelines corresponding to each thread (e.g., timeline 1 corresponding to thread 1, timeline 2 corresponding to thread 2), and key points corresponding to the thread of the corresponding timeline are displayed on each timeline. The position of the key point on the timeline can be the time point when the thread corresponding to the timeline debugs or runs the program through or passes the key point (which can also be called the hit time). The thread information and timing information corresponding to the key point are displayed simultaneously in two dimensions. During the debugging process, developers can directly judge the timing relationship between key points in the scenario of multi-threaded concurrent execution by observing the positions between key points on multiple timelines. At the same time, developers can also click on the key point of one of the timelines to trace the debugging information of the thread behavior corresponding to the timeline, realizing the visual debugging and positioning of the code under multi-threads. The timeline 1 and timeline 2 in FIG. 1(c) can be timeline identifiers for the timeline, and the numbers 1 and 2 can represent the chronological order of the start times of the threads corresponding to the timelines. For example, the thread 1 corresponding to timeline 1 starts earlier than the thread 2 corresponding to timeline 2. In some embodiments, the debugging area 102 can directly use the thread identifier or distinguish the timeline by combining the thread identifier with the timeline identifier. Here, the thread identifier can be the thread ID, the thread name defined by the developer, and so on.

[0070] In some embodiments, during the process of debugging a program in the integrated development environment, the stop code line information corresponding to the key points set for the program code can also be obtained. The stop code line information can be used for the integrated development environment to display the code lines of the code with key points set, that is, to identify the code lines corresponding to the key points in the source code file currently displayed by the integrated development environment. By combining the code lines corresponding to the key points and the timelines corresponding to the key points, that is, the code line information corresponding to the key points is also displayed on the timeline, enabling developers to observe the debugging information of the same or different thread behaviors corresponding to different key points in the same thread through the code lines of the key points during the debugging process.

[0071] It can be seen that through the above program debugging method, in the case where the program involves multi-threaded concurrent execution, two methods of thread split display (i.e., multiple timelines) and the code line information of key points are used to display the process of program debugging, enhancing the efficiency of using the integrated development environment for program debugging; at the same time, improving the visualization effect of the debugging function of the integrated development environment in a multi-threaded scenario and improving the efficiency of developers in locating exceptions / problems existing in the code.

[0072] In some possible implementation manners, the program debugging method according to the embodiments of the present application may involve two types of key points (breakpoints), such as: the first type of key points and the second type of key points. For the first type of key points, when the integrated development environment debugs the code passing through the first type of key points, the integrated development environment does not control the program to pause execution, but only caches the debugging information of the first type of key points; for the second type of key points, when the integrated development environment debugs the code passing through the second type of key points, the integrated development environment controls the program to pause execution. Therefore, a developer may choose to set the first type of key points for the code of a program involving multi-threaded concurrent execution, and set the second type of key points for the code subsequent to the first type of key points. For example: set the second type of key points for the subsequent code not involving multi-threaded concurrent execution. When the integrated development environment debugs the program passing through the first type of key points, that is, when passing through the code involving multi-threaded concurrent execution, it is possible to avoid pausing the program multiple times due to multi-threaded concurrent execution; when the integrated development environment debugs the program passing through the second type of key points, the integrated development environment controls the program to pause execution, and based on the time line corresponding to the first type of key points, displays the debugging information of the first type of key points in the program that has been debugged in a thread-splitting manner.

[0073] In some other implementation manners, only the first type of key points may be displayed on the time line in the program debugging method, avoiding too many key points being displayed on the time line during the debugging process due to setting a relatively large number of key points in the program code.

[0074] Figure 2 The figure shows a schematic diagram of the effect of thread-splitting display and the display of the code line information of key points on the time line involved in a program debugging method applicable to the embodiments of the present application. According to Figure 2 As shown in the content marked as ①, during the debugging process of multi-threaded concurrent execution, the integrated development environment may generate a separate time line for each thread (such as: thread 1 to thread 4) of the code of the program with key points set for debugging. For example: time line 1 to time line 4. It can be seen that time line 1 to time line 4 may be arranged in parallel based on the direction of the time axis. The starting positions of time line 1 to time line 4 may be the start time point of debugging the program in a multi-threaded concurrent execution manner, and the positions of the key points on each time line may be the time points when the thread corresponding to the time line debugs or runs the program through the key points. According to Figure 2 As shown in the content marked as ②, the integrated development environment may obtain the code lines of the key points in the code of multi-threaded concurrent execution, that is, the code line information corresponding to the key points in the source code file corresponding to the code (such as 123, 45). By fusing the content of ① and ②, according to Figure 2 As shown in the content marked as ③, the key points and the code line information of the key points are displayed on the time line corresponding to the thread. In Figure 2Among them, the key points shown on each timeline are the key points in the code corresponding to the programs that have been debugged by each thread. That is to say, the key points of the code that have not been debugged are not shown on the timeline. As the program debugging process progresses, the key points in the code will be shown on the timeline in sequence.

[0075] In some embodiments, during the program debugging process in the integrated development environment through multi-threaded concurrent execution, each thread may repeatedly debug all / part of the code with key points set. As shown in FIG. 3(a), during the program debugging process in the integrated development environment, multiple / multiple groups of key points with the same code line but different positions will be shown on the timelines of the started thread 39 and thread 40 respectively (for example, key points 31 and 35 are shown multiple times on timeline 39, and key point 48 is shown multiple times on timeline 40). That is to say, every time a thread debugs through the code with a key point, the integrated development environment will display the key point on the timeline corresponding to the thread. Different positions of the key points with the same code line on the same timeline indicate different time points when the thread runs the program through the key point. Each key point can also correspond to its own debugging information (that is, the variable value of the variable to be observed, code exception information, etc.). As can be seen from FIG. 3(a), the integrated development environment can more clearly represent the debugging information of the code that each thread has debugged through (or referred to as executed through) through the timeline. Here, the key points 31, 35, and 48 can be the first type of key points.

[0076] FIG. 3(b) shows a schematic flow diagram of the program debugging method according to an embodiment of the present application. The program debugging method can be applied to an integrated development environment. The program debugging method includes:

[0077] S301: The integrated development environment responds to a first debugging operation on a target program, and debugs the target program through a first target code position of a first code file corresponding to the target program.

[0078] Exemplarily, the target program here can be referred to as a program, a program to be debugged, or a program under debugging. The first debugging operation is a debugging operation performed on the target program by a developer after opening the code of the target program using the integrated development environment. The target program can correspond to at least a first code file and a second code file. For example: debugging the target program can successively pass through the code of the first code file and the code of the second code file. Here, the first target code position can be a code line in the first code file. For example: the first target code position can be the code line in the first code file where the second type of key point is set.

[0079] S302: The integrated development environment displays at least a first timeline and a second timeline corresponding to the first target code position. The first timeline corresponds to a first thread running the target program, and the second timeline corresponds to a second thread running the target program.

[0080] Exemplarily, during the debugging process of the multi-threaded concurrent execution of the target program, the integrated development environment may start at least a first thread and a second thread, and display a first timeline corresponding to the first thread and a second timeline corresponding to the second thread in the debugging area of the integrated development environment. At least one first breakpoint and the first line-of-code information corresponding to the first breakpoint may be displayed on the first timeline, and at least one second breakpoint and the second line-of-code information corresponding to the second breakpoint may be displayed on the second timeline. The first breakpoint and the second breakpoint correspond to code positions in the first code file that are before the first target code position. That is to say, the first breakpoint and the second breakpoint may be on the lines of code in the first code file where the first type of key points are set, and the lines of code corresponding to the first breakpoint and the second breakpoint are before the line of code corresponding to the first target code position.

[0081] In some implementation manners, the lines of code in the first code file corresponding to the first breakpoint and the second breakpoint may also be the same, and the first line-of-code information and the second line-of-code information displayed on the first timeline and the second timeline are also the same. The first breakpoint corresponds to first hit time information, and the first hit time information represents the time when the first thread runs the target program through the first breakpoint; the second breakpoint corresponds to second hit time information, and the second hit time information represents the time when the second thread runs the target program through the second breakpoint.

[0082] In some implementation manners, the starting positions of the first timeline and the second timeline displayed in the debugging area of the integrated development environment may be the same. That is, the straight line passing through the starting positions of the first timeline and the second timeline is perpendicular to the first timeline and perpendicular to the second timeline. In the case where the first hit time information is different from the second hit time information, the position of the first breakpoint on the first timeline is different from the position of the second breakpoint on the second timeline. That is, the straight line passing through the first breakpoint and the second breakpoint is not parallel to the straight line passing through the starting positions of the first timeline and the second timeline. The first thread identification information here may be the timeline identification of the first timeline, and the second thread identification information may be the timeline identification of the second timeline. For example: the first timeline and the second timeline may be represented by timeline 1 and timeline 2 respectively, and the numbers 1 and 2 may represent the order of the start time of the first thread and the second thread corresponding to the first timeline and the second timeline.

[0083] In some implementation manners, when debugging the target program through the first target code position of the first code file corresponding to the target program, the code area of the integrated development environment is switched to display the first code file. That is, the code area of the integrated development environment currently displays the first code file.

[0084] The program debugging method of the embodiment of the present application shown in FIG. 3(b) above may further include the process shown in FIG. 3(c), including:

[0085] S301a: The debugging target program passes through the second target code position of the first code file corresponding to the target program.

[0086] Exemplarily, the second target code position here may be a code line in the first code file. For example, the second target code position may be a code line in the first code file where a second type of key point is set.

[0087] S302a: Display a third breakpoint and third code line information corresponding to the third breakpoint on the first timeline, where the third breakpoint corresponds to the second target code position.

[0088] Exemplarily, when debugging the target program in the first thread and passing through the second target code position of the first code file corresponding to the target program, at least one third breakpoint and third code line information corresponding to the third breakpoint may continue to be displayed on the first timeline. The code line corresponding to the third breakpoint here is before the code line corresponding to the second target code position.

[0089] In some implementation manners, the third breakpoint corresponds to third hit time information, and the third hit time information represents the time when the first thread runs the target program through the third breakpoint. It can be seen that the first thread runs the target program through the first breakpoint and the third breakpoint successively. Therefore, when the first hit time information and the third hit time information are different, the position of the third breakpoint on the first timeline is different from the position of the first breakpoint on the first timeline, and the position of the third breakpoint on the first timeline may be after the position of the first breakpoint on the first timeline.

[0090] The program debugging method of the embodiment of the present application shown in FIG. 3(b) above may further include the process shown in FIG. 3(d), including:

[0091] S301b: In response to a second debugging operation on the target program, debug the target program from the first code file to the second code file corresponding to the target program and pass through the third target code position of the second code file.

[0092] Exemplarily, the second debugging operation here is the next debugging operation performed by the developer on the target program using an integrated development environment. The third target code position here may be a code line in the second code file. For example, the third target code position may be a code line in the second code file where a second type of key point is set.

[0093] S302b: Display at least one fourth breakpoint and the fourth line of code information corresponding to the fourth breakpoint on the first timeline, and display at least one fifth breakpoint and the fifth line of code information corresponding to the fifth breakpoint on the second timeline, where the fourth breakpoint and the fifth breakpoint correspond to code positions in the second code file that are before the third target code position.

[0094] Exemplarily, the fourth breakpoint and the fifth breakpoint can be the lines of code in the second code file where the first type of key points are set, and the lines of code corresponding to the fourth breakpoint and the fifth breakpoint are before the line of code corresponding to the third target code position.

[0095] In some implementation manners, when the debug target program passes through the third target code position of the second code file, the code area of the integrated development environment is switched to display the second code file. Hide the first line of code information on the first timeline and hide the second line of code information on the second timeline. The first timeline and the second timeline can only display the line of code information of the breakpoints set in the second code file currently displayed by the integrated development environment, and do not display the line of code information of the breakpoints set in the first code file that is not currently displayed.

[0096] The program debugging method of the embodiment of the present application shown in FIG. 3(b) above can further include the process shown in FIG. 3(e), including:

[0097] S301c: In response to a backtracking operation for the first breakpoint, the code area of the integrated development environment is switched to display the first code file and display the code of the first line of code information in the first code file in a highlighted manner.

[0098] Exemplarily, the backtracking operation here can be that the developer backtracks the debugging information of the thread behavior corresponding to the first timeline by clicking on the first breakpoint on the first timeline. The code area of the integrated development environment can be switched to display the first code file and present code highlighting in the first code file according to the first line of code information of the first breakpoint.

[0099] S302c: In response to a backtracking operation for the first breakpoint, the debug area of the integrated development environment displays the first debugging information corresponding to the first breakpoint, where the first debugging information includes at least one of the variable value of the first variable to be observed, the first thread identification information, the first hit time information, and the first line of code information.

[0100] Exemplarily, in addition to displaying the first debugging information of the first breakpoint in the debug area of the integrated development environment, it can also display the first line of code information on the first timeline and hide the fourth line of code information, and display the second line of code information on the second timeline and hide the fifth line of code information.

[0101] After introducing the program debugging method provided by this application and the effects brought by the program debugging method, the following will introduce Figure 4 the architecture diagram of a program development product applicable to the program debugging method of the embodiments of this application.

[0102] As Figure 4 shown, the program development product includes an integrated development environment 400 and a debugger 500. Among them, the integrated development environment 400 includes a debugging module 401. Among them, the debugging module 401 has the debugging ability for the program (including: forward debugging or reverse debugging, etc.), and the debugging module 401 can interact with the debugger 500. In the embodiments of this application, the debugger 500 here can be used to debug the program line by line according to the execution order corresponding to the written program. The debugger 500 can correspond one by one to the programming language corresponding to the written program. That is, the debugger 500 can be a debugging function module provided by the running environment of the programming language. In some embodiments, when a developer starts debugging the program by opening the code of the program through the integrated development environment, the debugger 500 can receive a debugging instruction from the debugging module 401 and debug the program based on the received debugging instruction. After the developer uses the integrated development environment 400 to start program debugging, the debugging module 401 can send a debugging instruction to the debugger 500, obtain and save the debugging information returned by the debugger 500. The debugging module 401 can also display the debugging information in the visual interface of the integrated development environment, and in the debugging process of multi-threaded concurrent execution, display the debugging information of the program in a way that combines the code line information of the key points in the program through thread splitting. That is, provide the visual debugging ability under multi-threads. The debugger 500 here is used to debug the program, that is, execute the code corresponding to the program in a debugging manner, and monitor / track the debugging information corresponding to the program during the debugging process (such as: changes in variables in the storage area, changes in the stack, etc.).

[0103] The following will further introduce Figure 5 the debugging module 401 of the integrated development environment 400 shown in Figure 4 , which can also be called a program debugging device, as Figure 5 shown, the debugging module 401 can include: a debugging server 4011, a debugging plug-in end 4012, and a timeline interface module 4013.

[0104] Among them, the debugging server 4011 can interact with the debugger 500. After the developer starts program debugging using the integrated development environment 400, the debugging server 4011 can send debugging instructions to the debugger 500, and the debugger 500 debugs the program according to the debugging instructions. The debugging server 4011 can obtain and save the debugging information returned by the debugger 500. Here, the debugging information can include all the debugging information generated during the process of the debugger 500 debugging the program, including: the number of lines of code that have been debugged, the exception information generated, etc. (which can also be called the debugging information required for forward debugging); and the debugging information, hit time, thread information, and paused code line information of all key points set in the code. Among them, the debugging information of the key points can include: the variable values of the variables to be observed when the program runs through the key points, the occupancy of system resources, etc. The debugging server 4011 can store all the debugging information of the key points, thread information, and paused code line information in an orderly manner according to the hit time, that is, store the corresponding relationship between the debugging information of the key points and the hit time, thread information, and paused code line information. The corresponding relationship can also be called the basic debugging information of the key points. The debugging server 4011 can also return the debugging information required for normal debugging of the saved program and the basic debugging information of all key points to the debugging plugin side 4012.

[0105] The debugging plugin side 4012 is used to display the debugging information required for forward debugging in some functional areas on the application interface of the integrated development environment 400. For example, it displays exception information, etc. in the console area 105. The debugging plugin side 4012 is also used to send the received basic debugging information of all key points to the timeline interface module 4013.

[0106] The timeline interface module 4013 can be used to control / manage the debugging area 102 on the application interface of the integrated development environment 400. For example: the timeline interface module 4013 can complete the rendering of the timeline based on the basic debugging information of all key points, that is, complete the rendering effect corresponding to the basic debugging information. For example: according to the corresponding relationship between the debugging information of the key points and the thread information, render the thread branch display effect, that is, render the timeline and the key points on the timeline; according to the corresponding relationship between the debugging information of the key points and the hit time, render the position of the key points on the timeline (basic timing); according to the corresponding relationship between the debugging information of the key points and the paused code line information, render the display effect of the code line information corresponding to the key points on the timeline.

[0107] In some embodiments, the timeline interface module 4013 may be a debugging function sub-module managed by the debugging plug-in end 4012. The debugging plug-in end 4012 may also include any other number of debugging function sub-modules. The debugging plug-in end 4012 included in the debugging module 401 is optional. That is to say, the debugging server end 4011 may directly manage any other number of debugging function sub-modules including the timeline interface module 4013. The debugging module 401 may be configured as a separate function module in the integrated development environment 400.

[0108] Figure 6 shows Figure 5 a process interaction diagram between each function module in the described debugging module 401 and the debugger 500. The process interaction diagram may include the following steps.

[0109] S601: In response to a debugging instruction sent by the debugging server end 4011, the debugger 500 debugs the program under debugging 600.

[0110] Exemplarily, the program under debugging 600 here may also be referred to as the target program or the program to be debugged. The debugging instruction here may be a debugging instruction generated by a debugging operation performed by a developer on the program under debugging 600 after opening the code of the program using the integrated development environment.

[0111] S602: When the debugger 500 hits a critical position while debugging the program under debugging 600, the debugger 500 returns debugging information to the debugging server end 4011.

[0112] Exemplarily, the debugging information here may include the debugging information corresponding to the program under debugging 600 generated when the debugger 500 hits a critical position while debugging the program under debugging 600, that is, when the debugger 500 debugs or runs the program under debugging 600 through the code line where the key point is located, including: generated exception information, etc. (which may also be referred to as the debugging information required for forward debugging); and the debugging information of all key points set in the code, the hit time, thread information, and the stopped code line information.

[0113] S603: The debugging server end 4011 automatically saves the debugging information of the key points and stores all the debugging information of the key points in an orderly manner according to the hit time.

[0114] Exemplarily, the debugging server end 4011 may store the correspondence between the debugging information of the key points and the hit time information (that is, the time when the program under debugging 600 passes through the key point), thread information, and stopped code line information. The correspondence may also be referred to as the basic debugging information of the key points.

[0115] S604: The debugging server 4011 returns the debugging information required for forward debugging and the basic debugging information of all key points to the debugging plug-in side 4012.

[0116] Exemplarily, the debugging plug-in side 4012 here is used to display the debugging information required for forward debugging in some function areas on the application interface of the integrated development environment, such as: displaying exception information, etc.

[0117] S605: The debugging plug-in side 4012 sends the basic debugging information of all key points received to the timeline interface module 4013.

[0118] Exemplarily, the debugging plug-in side 4012 here can also send the basic debugging information of all key points received to the timeline interface module 4013. Through the timeline interface module 4013, the basic debugging information of all key points is specially displayed in the function area on the application interface of the integrated development environment.

[0119] S606: The timeline interface module 4013 completes the rendering work.

[0120] Exemplarily, as Figure 7 shown, the timeline interface module 4013 here can render the thread split display effect according to the correspondence between the basic debugging information of the key points and the thread information, that is, render the timeline and the key points on the timeline; render the position of the key points (basic timing) on the timeline according to the correspondence between the debugging information of the key points and the hit time information; render the display effect of the code line information corresponding to the key points (which can also be called the current line number display) on the timeline according to the correspondence between the debugging information of the key points and the staying code line information.

[0121] It can be seen that after applying Figure 5 the respective functional modules of the debugging module 401 shown in the integrated development environment 400 in FIG. 1, without changing the functions included in the original respective function areas of the integrated development environment 400, more clear program debugging information can also be displayed in one or more of the function areas, such as: during the debugging process of multi-threaded concurrent execution, the thread split display effect can be displayed in the debugging area 102 on the application interface of the integrated development environment 400, enabling developers to more quickly locate the exceptions / problems existing in the program.

[0122] In some embodiments, the above Figure 5In addition to representing the debugging information corresponding to the same / different key points in the code of the programs being debugged by multiple threads through the thread timeline display effect during the debugging process of the multi-threaded concurrent execution, the debugging module 401 of the described integrated development environment 400 also supports developers to trace back the debugging information of the thread behavior corresponding to that timeline by clicking on the key point of one of the timelines, that is, the traceback operation. The following is through Figure 8 Describes the process interaction diagram for implementing traceback debugging information between each functional module in the debugging module 401 and the debugger 500. The process interaction diagram may include the following steps.

[0123] S801: In response to the developer clicking on any key point in the timeline interface module 4013, the timeline interface module 4013 notifies the debugging plugin side 4012 to obtain the debugging information corresponding to the key point.

[0124] Exemplarily, the key point here can be any key point on the timeline displayed by the timeline interface module 4013 in the debugging area 102 of the integrated development environment as shown in FIG. 1. The notification sent by the timeline interface module 4013 to the debugging plugin side 4012 can be regarded as a notification instruction sent by the timeline interface module 4013. The notification can carry the basic debugging information of the key point, including the hit time of the key point, thread information, stopped code line information, etc.

[0125] S802: After receiving the notification, the debugging plugin side 4012 requests the debugging information corresponding to the key point from the debugging server side 4011.

[0126] Exemplarily, the debugging plugin side 4012 forwards the notification to the debugging server side 4011.

[0127] S803: The debugging server side 4011 obtains the debugging information corresponding to the key point and returns it to the debugging plugin side 4012.

[0128] Exemplarily, the debugging server side 4011 can, according to the saved debugging information, search for the debugging information of the key point based on the basic debugging information of the key point carried by the notification and return it to the debugging plugin side 4012.

[0129] S804: The debugging plugin side 4012 refreshes the functional area of the integrated development environment according to the returned debugging information of the key point.

[0130] Exemplarily, the functional area here can also be referred to as the debugging page of the integrated development environment. For example, the debugging area 102 and the code area 103 of the integrated development environment shown in FIG. 1. Among them, the debugging area 102 can include a thread window, a stack window, and a variable window, which are respectively used to display variable values of variables to be observed, occupancy of system resources, thread information, stack information, and so on. The code area 103 can present code highlighting (highlighted source code lines) according to the line information of the code where the debugging information of the key points stays. It enables developers to trace back the debugging information of specific key points on the timeline.

[0131] It can be seen that through Figure 6 and Figure 8 each functional module corresponding to the debugging module 401 of the integrated development environment 400 described above, it can support the visual display of thread information and current line number information of key points based on the timeline and support backtracking. Especially in a multi-threaded scenario, the thread information of key points can be displayed, which can be used to judge the timing relationship of thread behaviors, thereby improving the efficiency of locating multi-threaded problems; at the same time, the current line number information of key points is also displayed, which can be used to judge which one of multiple key points is the key point that needs to view debugging information, and directly backtrack by clicking on the key point.

[0132] After introducing the process interaction of the program debugging method implemented by the integrated development environment of the embodiments of the present application through the above Figure 6 and Figure 8 below, the application scenarios of the application interface of the integrated development environment (that is, the program development product) applicable to the program debugging method are introduced.

[0133] As shown in FIG. 9(a), the application interface 100 of the integrated development environment may include multiple functional areas such as a toolbar area 101, a debugging area 102, a code area 103, an auxiliary display area 104, and a console area 105. Among them, developers can set key points for the code corresponding to the source code file (such as hashtable.c in the figure) displayed in the code area 103. As shown in FIG. 9(a), developers can set key points for code lines 127, 130, and 133 of the code. Among them, the key points set at code lines 127 and 130 can be the first type of key points, and the key point set at code line 133 can be the second type of key points. After the developer starts debugging the program through the debugging control ① in the toolbar area 101, as shown in FIG. 9(b), during the debugging process of multi-threaded concurrent execution, the first thread debugs or runs the program and pauses execution after passing through code lines 127 and 130 (which can also be called key point 127 and key point 130) to code line 133 (key point 133). The debugging area 102 can display the timeline 1 corresponding to the first thread. Among them, the key points corresponding to code lines 127, 130, and 133 at different positions and the code line information corresponding to the key points will be respectively displayed on the timeline 1. For example, the code line information is displayed at the position of the key point on the timeline 1 or on one side of the key point. Different positions of the key points indicate different time points when the first thread debugs the program through the key points. It can be seen that the key point corresponding to code line 133 can be located at a later position on the timeline 1. In some embodiments, the timeline 1 may also only display the key points corresponding to code lines 127 and 130, that is, the first type of key points. The debugging area 102 can display the debugging information (such as: the variable value 110 of the variable to be observed xxxxx, etc.) when the first thread debugs the program through code line 133. If the first thread repeatedly debugs the code of code lines 127 and 130, multiple groups of key points corresponding to code lines 127 and 130 and the code line information will be respectively displayed on the timeline 1. Different positions of the multiple groups of key points indicate different time points when the first thread debugs the program through each key point. As shown in FIG. 9(c), when the first thread debugs the code of code lines 127 and 130 twice, two groups (the first group and the second group) of key points corresponding to code lines 127 and 130 will be successively displayed on the timeline 1.

[0134] Continuing to refer to FIG. 9(c), if a developer clicks on the label of the key point 130 in the latter group (the second group) on the timeline 1 to trace back the debugging information of the key point 130 corresponding to the thread behavior of the timeline 1, as shown in FIG. 9(d), the debugging information displayed in the debugging area 102 will also change (e.g., the variable value 111 of the variable to be observed xxxxx). If the developer clicks on the label of the key point 130 in the former group (the first group) on the timeline 1 to trace back the debugging information of the key point 130 corresponding to the thread behavior of the timeline 1, as shown in FIG. 9(e), the debugging information displayed in the debugging area 102 will also change (e.g., the variable value 222 of the variable to be observed xxxxx).

[0135] It can be seen that after the code passing through the key points is debugged by the first thread, key points will be displayed on the timeline 1. Different positions of the key points with the same code line on the same timeline 1 indicate different time points when the first thread debugging program passes through the key points. The developer can click on the label of the key point on the timeline 1 to trace back the debugging information of this key point, realizing the visual debugging and positioning of the code.

[0136] In some embodiments, during the debugging process of multi-threaded concurrent execution, the debugging area 102 can also simultaneously display the timeline 1 corresponding to the first thread and the timeline 2 corresponding to the second thread. The first thread and the second thread debug or run the program through the code lines 127 and 130. As shown in FIG. 9(f), key points corresponding to the code lines 127 and 130 at different positions and code line information can be respectively displayed on the timeline 1 and the timeline 2 (in the case where the code lines 127 and 130 in the program are repeatedly debugged by the first thread and the second thread, multiple groups of key points corresponding to the code lines 127 and 130 can also be displayed on the timeline 1 and the timeline 2). Among them, compared with the timeline 1, the positions of the key points corresponding to the code lines 127 and 130 on the timeline 2 can be different from the positions of the key points corresponding to the code lines 127 and 130 on the timeline 1, indicating different time points when the first thread and the second thread debugging programs pass through the code lines 127 and 130. At the same time, since the first thread and the second thread are different threads, therefore, the debugging information (e.g., the variable value 441 of the variable to be observed xxxxx) of the key point corresponding to the code line 130 on the timeline 2 displayed in the debugging area 102 can also be different from the debugging information of the key point corresponding to the code line 130 on the timeline 1 shown in FIG. 9(c). At this time, if the developer clicks on the label of the key point 130 on the timeline 1 to trace back the debugging information of the key point 130 corresponding to the thread behavior of the timeline 1, as shown in FIG. 9(g), the debugging information displayed in the debugging area 102 will also change (e.g., the variable value 222 of the variable to be observed xxxxx).

[0137] In some embodiments, if there are more than two threads (e.g., the first thread to the fourth thread) debugging the program, such asFigures 9(h) to 9(i) As shown, the debugging area 102 can display a scroll control 1021, and developers can control the scroll control 1021 to switch between the timelines corresponding to multiple threads. For example, scroll to display Timeline 1 to Timeline 4.

[0138] It can be seen that in the application scenario of the integrated development environment for the applicable program debugging method described above, the target program or the program to be debugged corresponds to only one source code file. In some other implementation manners, if the target program or the program to be debugged involves multiple source code files and the target program involves multi-threaded concurrent execution, the timeline corresponding to each thread presented by the integrated development environment can only display the line information of the key points set in the source code file currently displayed by the integrated development environment. For the source code files that have been opened but not displayed, the line information of the key points set in the source code files is not displayed. For the unopened source code files, the key points set in the source code files are not displayed, nor is the line information displayed. Figures 9(a) to 9(h) As shown in FIG. 10(a), the application interface 100 of the integrated development environment can include multiple functional areas such as a toolbar area 101, a debugging area 102, a code area 103, an auxiliary display area 104, and a console area 105. The developer has opened two source code files corresponding to the program in the code area 103 (the first source code file is hashtable.c as shown in the figure and the second source code file is xxxxfile.c). Among them, the execution order of the first source code file can be earlier than that of the second source code file, and during the process of debugging the program, the first source code file can call the second source code file, and the first source code file is the currently displayed source code file. The developer can set key points for the code lines 127 and 130 of the first source code file. As shown in FIG. 10(b), the developer can also switch to the second source code file in the code area 103 and set key points for the code lines 128 and 131 of the second source code file.

[0139]

[0140] ​After the developer starts debugging the program through the debugging control ① in the toolbar area 101, as shown in Figure 10(c), during the debugging process of multi-threaded concurrent execution, the integrated development environment can start the first thread and the second thread. The first thread and the second thread respectively debug the code lines 127 and 130 of the first source file passed by the program. The code area 103 displays the code of the first source file, and the debugging area 102 can display the timeline 1 and timeline 2 corresponding to the first thread and the second thread. Among them, the timeline 1 and timeline 2 will display the key points and code line information corresponding to the code lines 127 and 130 in the first source file. As shown in Figure 10(d), the first thread and the second thread debug the code lines 128 and 131 of the second source file passed by the program. The code area 103 displays the code of the second source file, and the timeline 1 and timeline 2 will newly display the key points and code line information corresponding to the code lines 128 and 131 in the second source file. At this time, in some implementation manners, the timeline 1 and timeline 2 will no longer display the code line information of the key points corresponding to the code lines 127 and 130 in the first source file.

[0141] As shown in Figure 10(e), when the developer switches from the second source file to the first source file in the code area 103, for example: the developer clicks on the file name (hashtable.c) of the first source file displayed in the code area 103, the timeline 1 and timeline 2 will redisplay the code line information of the key points corresponding to the code lines 127 and 130 in the first source file. At this time, the timeline 1 and timeline 2 can no longer display the code line information of the key points corresponding to the code lines 128 and 131 in the second source file. In some possible implementation manners, if the developer clicks on the key point on the timeline 1 in the debugging area 102 (such as: a key point belonging to the second source code, without displaying the line number), continuing to refer to Figure 10(d) shown, the code area 103 of the integrated development environment will switch to the code of the second source file. At the same time, the timeline 1 and timeline 2 will redisplay the code lines of the key points corresponding to the code lines 128 and 131 in the second source file and will not display the code line information of the key points corresponding to the code lines 127 and 130 in the first source file.

[0142] It can be seen that in the above Figures 10(a) to 10(e) application scenario of the integrated development environment applicable to the program debugging method, when the target program or the program to be debugged involves multiple source files and the target program involves multi-threaded concurrent execution, the timeline corresponding to each thread can only display the code line information of the key points set in the source file currently displayed by the integrated development environment, rather than the code line information of the key points set in the source file that is not currently displayed, enabling the developer to more quickly locate the anomalies / problems existing in the code during the debugging process.

[0143] The method of the embodiment of the present application is elaborated in detail above. To facilitate better implementation of the above solution of the embodiment of the present application, correspondingly, relevant devices for cooperating with the implementation of the above solution are also provided below.

[0144] Figure 11 It is a schematic structural diagram of an electronic device 1100 that runs an integrated development environment provided by the present application. As Figure 11 shown, the electronic device 1100 includes: a processor 1110, a communication interface 1120, and a memory 1130. Among them, the processor 1110, the communication interface 1120, and the memory 1130 can be interconnected through an internal bus 1140, or can also achieve communication through other means such as wireless transmission. In the embodiment of the present application, taking the connection through the bus 1140 as an example, the bus 1140 can be a Peripheral Component Interconnect Express (PCIe) bus, or an Extended Industry Standard Architecture (EISA) bus, a Unified Bus (Ubus or UB), a Compute Express Link (CXL), a Cache Coherent Interconnect for Accelerators (CCIX), etc. The bus 1040 can be divided into an address bus, a data bus, a control bus, etc. In addition to the data bus, the bus 1140 can also include a power bus, a control bus, a status signal bus, etc. However, for the sake of clear illustration, all kinds of buses are labeled as the bus 1140 in the figure.

[0145] The processor 1110 may be composed of at least one general-purpose processor, such as a central processing unit (CPU), or a combination of a CPU and a hardware chip. The above-mentioned hardware chip may be an application specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The above-mentioned PLD may be a complex programmable logic device (CPLD), a field-programmable gate array (FPGA), a generic array logic (GAL), or any combination thereof. The processor 1010 executes various types of digital storage instructions, such as digital storage instructions in software or firmware programs stored in the memory 1130, which enables the electronic device 1100 to provide various services.

[0146] The memory 1030 is used to store program codes and is controlled by the processor 1110 to execute the processing steps of the occlusion recognition method in the above embodiments. The program codes may include one or more software modules, and these one or more software modules may be Figure 8 the software modules provided in the embodiments, such as an acquisition unit, a generation unit, and a determination unit: the acquisition unit is used to acquire the power of multiple APs, the signal strength between the terminal and multiple APs, and the signal strength between multiple AP pairs; the generation unit is used to generate a path loss value pair between the terminal and an AP pair and the path loss value of the AP pair according to the power of the multiple APs acquired, the signal strength between the terminal and multiple APs, and the signal strength between multiple AP pairs; the determination unit is used to compare the first path loss value and the second path loss value between the first AP and the second AP to determine whether there is an occluder between the first AP and the second AP. Wherein, the first path loss value is the magnitude of the signal loss measured between the first AP and the second AP, and the second path loss value is the path loss value inferred from the path loss value pair of each AP pair in the multiple AP pairs and the terminal.

[0147] The memory 1130 may include volatile memory, such as random access memory (RAM); the memory 1030 may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, hard disk drive (HDD), or solid-state drive (SSD); the memory 1130 may further include a combination of the above types. The memory 1130 may store program code that specifically executes Figure 5 the steps S510 - S530 and their optional steps in the embodiments, which will not be elaborated here.

[0148] The communication interface 1120 may be an internal interface (such as a high-speed serial computer expansion bus), a wired interface (such as an Ethernet interface), or a wireless interface (such as a cellular network interface or a wireless local area network interface) for communicating with other devices or modules.

[0149] It should be noted that Figure 11 this is merely a possible implementation manner of the embodiments of the present application. In practical applications, the electronic device 1100 may further include more or fewer components, which are not limited here.

[0150] It should be understood that this embodiment may be implemented by a general physical server, for example, an ARM server or an X86 server, or may also be implemented by a virtual machine based on a general physical server combined with NFV technology. A virtual machine refers to a complete computer system with complete hardware system functions simulated by software and running in a completely isolated environment. The present application does not make specific limitations.

[0151] Figure 11 The illustrated electronic device 1100 may also be a computer cluster composed of at least one server, which is not specifically limited in the present application.

[0152] The embodiments of the present application further provide a computer-readable storage medium. Instructions are stored in the computer-readable storage medium, and when they run on a processor, Figure 5 the shown method flow is realized.

[0153] It can be understood that the structure illustrated in the embodiments of the present application does not constitute a specific limitation on the electronic device. In the embodiments of the present application, an electronic device (such as a mobile phone, a car computer, etc.) may include more or fewer components than shown, or combine certain components, or split certain components, or have different component arrangements. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0154] In the embodiments of the present application, it can be implemented in whole or in part by software, hardware, firmware, or any combination thereof. When implemented using software, it can be implemented in whole or in part in the form of a computer program product. The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, the processes or functions according to the embodiments of the present application are generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable devices. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions can be transmitted from one website, computer, server, or data center to another website, computer, server, or data center by wire (such as coaxial cable, optical fiber, digital subscriber line) or wirelessly (such as infrared, wireless, microwave, etc.). The computer-readable storage medium can be any available medium that can be accessed by a computer or a data storage device such as a server or a data center that includes one or more integrated available media. The available medium can be a magnetic medium (such as a floppy disk, hard disk, magnetic tape), an optical medium (such as a DVD), or a semiconductor medium (such as a solid-state drive), etc.

[0155] Those of ordinary skill in the art can understand that to implement all or part of the processes in the embodiments of the present application, the processes can be completed by instructing relevant hardware with a computer program. The program can be stored in a computer-readable storage medium. When the program is executed, it can include the processes in the embodiments of the present application. The aforementioned storage medium includes various media that can store program codes, such as read-only memory (ROM), random access memory (RAM), magnetic disks, or optical discs.

[0156] It should be understood that although terms such as "first" and "second" may be used herein to describe various features, these features should not be limited by these terms. These terms are only used for distinction and should not be construed as indicating or implying relative importance. For example, without departing from the scope of the embodiments of the present application, the first feature can be referred to as the second feature, and similarly, the second feature can be referred to as the first feature.

[0157] In addition, various operations will be described as a number of separate operations in a manner that is most conducive to understanding the embodiments of the present application; however, the described order should not be construed as implying that these operations must be dependent on the described order, and many of these operations can be implemented in parallel, concurrently, or simultaneously. In addition, the order of the operations can also be rearranged. When the described operations are completed, the process can be terminated, but there can also be additional operations not included in the drawings. The process can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0158] Unless the context otherwise requires, the terms "comprise", "have", and "include" are synonyms. The phrase "A / B" means "A or B". The phrase "A and / or B" means "(A), (B), or (A and B)".

[0159] As used herein, the term "module" can refer to, as part of it, or include: a memory (shared, dedicated, or group) for running one or more software or firmware programs, an application-specific integrated circuit (ASIC), an electronic circuit, and / or a processor (shared, dedicated, or group), combinational logic circuits, and / or other suitable components that provide the function.

[0160] In the drawings, some structural or method features may be shown in a specific arrangement and / or order. However, it should be understood that such a specific arrangement and / or order is not necessary. Instead, in the embodiments of the present application, these features can be described in a manner and / or order different from that shown in the illustrative drawings. Additionally, the structural or method features included in a specific drawing do not mean that all such features need to be included. In the embodiments of the present application, these features can be not included, or these features can be combined with other features.

[0161] The above has described in detail the embodiments of the present application in conjunction with the drawings, but the use of the technical solutions of the present application is not limited to various applications mentioned in the embodiments of the present application. Various structures and variations can be easily implemented with reference to the technical solutions of the present application to achieve various beneficial effects mentioned herein. Within the scope of knowledge possessed by those of ordinary skill in the art, various changes made without departing from the gist of the present application shall fall within the scope covered by the patent of the present application.

Claims

1. A program debugging method, applied to an integrated development environment, characterized in that The method includes: In response to a first debugging operation on a target program, debugging a first target code position of the target program passing through a first code file corresponding to the target program; Displaying at least a first timeline and a second timeline corresponding to the first target code position, where the first timeline corresponds to a first thread running the target program, and the second timeline corresponds to a second thread running the target program.

2. The method according to claim 1, characterized in that The first timeline includes at least one first breakpoint and first code line information corresponding to the first breakpoint, and the second timeline includes at least one second breakpoint and second code line information corresponding to the second breakpoint, where the first breakpoint and the second breakpoint correspond to code positions in the first code file that are before the first target code position.

3. The method according to claim 2, characterized in that, The first breakpoint and the second breakpoint correspond to the same code line in the first code file, and the first code line information and the second code line information are the same.

4. The method according to claim 3, characterized in that: The first breakpoint corresponds to first hit time information, and the first hit time information represents the time when the first thread runs the target program through the first breakpoint; The second breakpoint corresponds to second hit time information, and the second hit time information represents the time when the second thread runs the target program through the second breakpoint.

5. The method according to claim 4, wherein The first timeline is parallel to the second timeline; A straight line passing through the starting position of the first timeline and the starting position of the second timeline is perpendicular to the first timeline and perpendicular to the second timeline; In the case where the first hit time information is different from the second hit time information: a straight line passing through the first breakpoint and the second breakpoint is not parallel to a straight line passing through the starting position of the first timeline and the starting position of the second timeline.

6. The method according to any one of claims 1-5, characterized in that: The first timeline includes first thread identification information, and the first thread identification information corresponds to the first thread; The second timeline includes second thread identification information, and the second thread identification information corresponds to the second thread.

7. The method according to any one of claims 1 to 6, characterized in that, When debugging the target program through a first target code position of a first code file corresponding to the target program, the code area of the integrated development environment is switched to display the first code file.

8. The method according to any one of claims 1-6, characterized in that, Further includes: Debugging a second target code position of the target program passing through a first code file corresponding to the target program; Displaying a third breakpoint and third code line information corresponding to the third breakpoint on the first timeline, where the third breakpoint corresponds to the second target code position.

9. The method according to claim 8, wherein The third breakpoint corresponds to third hit time information, and the third hit time information represents the time when the first thread runs the target program through the third breakpoint. In the case where the first hit time information is different from the third hit time information, the position of the third breakpoint on the first timeline is different from the position of the first breakpoint on the first timeline.

10. The method according to any one of claims 1-9, characterized in that, Further includes: In response to a second debugging operation for the target program, debug the target program from the first code file to a second code file corresponding to the target program and through a third target code position of the second code file; Display at least one fourth breakpoint and fourth code line information corresponding to the fourth breakpoint on the first timeline, and display at least one fifth breakpoint and fifth code line information corresponding to the fifth breakpoint on the second timeline, where the fourth breakpoint and the fifth breakpoint correspond to code positions in the second code file that are before the third target code position.

11. The method according to claim 10, wherein Hide the first code line information on the first timeline and hide the second code line information on the second timeline.

12. The method according to claim 10 or 11, characterized in that, When debugging the target program through the third target code position of the second code file, the code area of the integrated development environment is switched to display the second code file.

13. The method according to any one of claims 10 - 12, characterized in that, Further includes: In response to a backtracking operation for the first breakpoint, the code area of the integrated development environment is switched to display the first code file and the code that displays the first code line information in the first code file in a highlighted manner.

14. The method according to any one of claims 10 - 12, characterized in that, Further includes: In response to a backtracking operation for the first breakpoint, the debugging area of the integrated development environment displays first debugging information corresponding to the first breakpoint, where the first debugging information includes at least one of the variable value of a first variable to be observed, the first thread identification information, the first hit time information, and the first code line information.

15. The method according to claim 11, wherein Display the first code line information on the first timeline and hide the fourth code line information, and display the second code line information on the second timeline and hide the fifth code line information.

16. A program debugging device, applied to an integrated development environment, characterized in that: The program debugging device, in response to a first debugging operation for a target program, debugs the target program through a first target code position of a first code file corresponding to the target program; The program debugging device displays at least a first timeline and a second timeline corresponding to the first target code position in a debugging area of the integrated development environment, where the first timeline corresponds to a first thread running the target program, and the second timeline corresponds to a second thread running the target program.

17. A program development product, characterized in that, Includes a debugger and an integrated development environment, The debugger, in response to a first debugging operation for a target program, debugs the target program through a first target code position of a first code file corresponding to the target program; The debugging area of the integrated development environment displays at least a first timeline and a second timeline corresponding to the first target code position, where the first timeline corresponds to a first thread running the target program, and the second timeline corresponds to a second thread running the target program.

18. An electronic device, characterized in that, Includes: A memory for storing programs; A processor for executing the programs stored in the memory; When the programs stored in the memory are executed, the processor is used to implement the method described in any one of claims 1-15.

Images