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

Abstract

The present application 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: 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; and displaying at least a first timeline and a second timeline which correspond to the first target code position, 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. When a program involves multithreaded concurrent execution, a program debugging process is displayed in two ways, i.e., using threads corresponding to multiple timelines, i.e., at least the first timeline and the second timeline, and incorporating breakpoints on the timelines and code line information of the breakpoints, thereby improving the visualization effect of the debugging function of an integrated development environment, and the efficiency of locating an abnormality / problem in a code by a developer.

Description

Program debugging device, program debugging method and program development product

[0001] This application claims priority to the Chinese patent application filed with the China Patent Office on December 29, 2023, with application number 202311869885.4 and application name “Program debugging device, program debugging method and program development product”, the entire contents of which are incorporated by reference into this application. Technical Field

[0002] The embodiments of the present application relate to the field of program debugging technology, and specifically to a program debugging device, a program debugging method, and a program development product. Background Art

[0003] In program development, after completing code writing, developers will perform various debugging on the code, and through debugging, they can find the defects of the code. Among them, breakpoint debugging is a debugging technology that suspends execution during the program debugging process and allows developers to step through the code corresponding to the program. Developers can set key points (i.e., breakpoints) in the program code through the Integrated Development Environment (IDE). When debugging or running the program through the code at the key point, the execution will be suspended. During the suspension, the developer can view the debugging information corresponding to the code (such as the variable value of the variable to be observed, stack information, etc.). The debugging information helps the developer understand the defects of the code executed before the key point. However, if the code with the key point set involves a scenario where multiple threads are executed concurrently, when debugging the code through the key point, it is not possible to distinguish the specific thread corresponding to the variable to be observed, therefore, it brings difficulties to the debugging of the program with the key point set.

[0004] Summary of the Invention

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

[0006] In a first aspect, the present application provides a program debugging method, applied to an integrated development environment, comprising:

[0007] In response to a first debugging operation for a target program, the target program is debugged through a first target code location 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.

[0008] In this specification, an integrated development environment (IDE) may be a tool used by developers or testers to develop or debug a target program. The target program may be referred to as a program, a program to be debugged, or a debugged program. A first debugging operation is a debugging operation performed on the target program after the developer uses the IDE to open the target program's code. The target program may correspond to at least a first code file. The first target code location may be a line of code in the first code file, for example, the first target code location may be a line of code in the first code file where a second-class key point is set. During the debugging process of multi-threaded concurrent execution of the target program, the IDE may launch 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 IDE. The first timeline may display at least one first breakpoint and first code line information corresponding to the first breakpoint, and the second timeline may display at least one second breakpoint and second code line information corresponding to the second breakpoint. The first breakpoint and the second breakpoint correspond to code locations in the first code file that precede the first target code location. That is, the first breakpoint and the second breakpoint can be set in the code line with the first type of key point in the first code file, and the code lines corresponding to the first breakpoint and the second breakpoint are located before the code line corresponding to the first target code position.

[0009] Through the above-mentioned program debugging method, when the program involves multi-threaded concurrent execution, the program debugging process is displayed in two ways: using at least the first timeline and the second timeline, which correspond to multiple timelines, and combining the breakpoints on the timeline and the code line information of the breakpoints, thereby enhancing the efficiency of program debugging using an integrated development environment; at the same time, the visualization effect of the debugging function of the integrated development environment in a multi-threaded scenario is improved, and the efficiency of developers in locating anomalies / problems in the code is improved.

[0010] In a possible implementation of the first aspect above, 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, wherein the first breakpoint and the second breakpoint correspond to code positions in the first code file that are located before the first target code position.

[0011] In this specification, at least one first breakpoint and first code line information corresponding to the first breakpoint can be displayed on the first timeline, and at least one second breakpoint and 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.

[0012] It can be seen that when the first thread and the second thread run the target program and pass 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 timeline, the developer 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.

[0013] In a possible implementation of the 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.

[0014] 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 timeline and the second timeline are also the same.

[0015] As can be seen, due to the different thread behaviors of the first and second threads, the debugging information corresponding to the same code line in different threads is also different. When the first and second threads run the target program and pass through the first target code location, the first breakpoint and the second breakpoint can be displayed on the first timeline and the second timeline respectively for the same code line in the first code file, allowing developers to observe different debugging information corresponding to the same breakpoint in different threads at key code lines during the debugging process.

[0016] In a possible implementation of the first aspect above, the first breakpoint corresponds to the first hit time information, and the first hit time information indicates 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 indicates the time when the second thread runs the target program through the second breakpoint.

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

[0018] In a possible implementation of the first aspect above, 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 the second timeline; when 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 position of the first timeline and the starting position of the second timeline.

[0019] It can be seen that the starting position of the first timeline displayed in the debugging area of ​​the integrated development environment can be the same as the starting position of the second timeline, that is, the 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, 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.

[0020] In a possible implementation of the first aspect, the first timeline includes first thread identification information corresponding to the first thread; the second timeline includes second thread identification information corresponding to the second thread.

[0021] 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 time sequence in which the first thread and the second thread corresponding to the first timeline and the second timeline are started.

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

[0023] It can be seen that when the integrated development environment debugs the target program passing 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 currently being debugged.

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

[0025] As can be seen, when the first thread debugging the target program passes through the second target code location in 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, where the code line corresponding to the third breakpoint is located before the code line corresponding to the second target code location. As the target program is continuously debugged, the breakpoints corresponding to the second target code location located after the first target code location will also be displayed on the timeline, providing more detailed debugging information for the target program.

[0026] In a possible implementation of the first aspect above, the third breakpoint corresponds to third hit time information, and the third hit time information indicates the time when the first thread runs the target program through the third breakpoint. 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 relative to the position of the first breakpoint on the first timeline.

[0027] 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.

[0028] In a possible implementation of the first aspect above, the method 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 a third target code position in the second code file; displaying at least one fourth breakpoint and fourth code line information corresponding to the fourth breakpoint on the first timeline, and displaying at least one fifth breakpoint and fifth code line information corresponding to the fifth breakpoint on the second timeline, wherein the fourth breakpoint and the fifth breakpoint correspond to code positions in the second code file that are before the third target code position.

[0029] As can be seen, the second debugging operation here is the next debugging operation performed by the developer using the integrated development environment on the target program. The target program can correspond to at least a first code file and a second code file. During the debugging process of the target program, the debugging of the target program can successively pass through the code of the first code file and the code of the second code file. The third target code location here can be a code line in the second code file. The fourth breakpoint and the fifth breakpoint can correspond to 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 location.

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

[0031] 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 code line information is hidden on the first timeline, and the second code line 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 second code file currently displayed by the integrated development environment, and do not display the code line information of the first breakpoint and the second breakpoint set in the first code file not currently displayed. It can more accurately display the code line information corresponding to the breakpoints related to the second code file passed by the currently running target program.

[0032] In a possible implementation of the first aspect, when the debugging target program 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.

[0033] It can be seen that when the integrated development environment debugs the target program passing 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.

[0034] In a possible implementation of the first aspect, the method further includes: in response to a backtrace operation on the first breakpoint, the code area of ​​the integrated development environment switches to displaying the first code file and highlighting the first code line information in the first code file.

[0035] As can be seen, the backtracking operation here can be a developer clicking a first breakpoint on a first timeline to backtrack the debugging information of the thread behavior corresponding to the first timeline. The code area of ​​the integrated development environment can be switched to display the first code file and highlight the code in the first code file based on the first code line information of the first breakpoint.

[0036] In a possible implementation of the first aspect above, the present invention further includes: in response to a backtrace operation for the first breakpoint, the debugging area of ​​the integrated development environment displays first debugging information corresponding to the first breakpoint, wherein the first debugging information includes at least one of a variable value of a first variable to be observed, first thread identification information, first hit time information, and first code line information.

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

[0038] As can be seen, the first and second timelines can only display the code line information for the first breakpoint and the second breakpoint set in the first code file currently displayed by the integrated development environment, while not displaying the code line information for the fourth and fifth breakpoints set in the second code file not currently displayed. This can more accurately display the code line information corresponding to the breakpoints related to the first code file currently running the target program.

[0039] 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:

[0040] The program debugging apparatus, in response to a first debugging operation on a target program, debugs the target program through a first target code position of a first code file corresponding to the target program;

[0041] The program debugging device displays at least a first timeline and a second timeline corresponding to the first target code position in the debugging area of ​​the integrated development environment, wherein 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.

[0042] In a third aspect, the present application provides a computer-readable storage medium comprising instructions, which, when executed on an electronic device, causes the electronic device to execute the data processing method according to the first aspect or any one of the implementation modes.

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

[0044] FIG1(a) to FIG1(c) illustrate an application scenario of an application interface of an integrated development environment according to an embodiment of the present application;

[0045] FIG2 is a schematic diagram showing the effects of displaying thread lines and displaying code line information of key points on a timeline in a program debugging method according to an embodiment of the present application;

[0046] FIG3( a ) shows a schematic diagram showing the effect of an integrated development environment displaying multiple timelines corresponding to multiple threads according to an embodiment of the present application;

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

[0048] FIG4 shows an architecture diagram of a program development product applicable to a program debugging method according to an embodiment of the present application;

[0049] FIG5 shows an architecture diagram of a debugging module of an integrated development environment according to an embodiment of the present application;

[0050] FIG6 shows a flow diagram of interaction between various functional modules in the debugging module and the debugger in an embodiment of the present application;

[0051] FIG7 shows a functional schematic diagram of a timeline interface module in a debugging module according to an embodiment of the present application;

[0052] FIG8 shows a flow diagram of the interaction between each functional module in the debugging module and the debugger to implement backtrace debugging information according to an embodiment of the present application;

[0053] 9( a ) to 9 ( i ) are schematic diagrams illustrating application scenarios of an integrated development environment applicable to a program debugging method according to an embodiment of the present application;

[0054] 10( a ) to 10 ( e ) are schematic diagrams illustrating application scenarios of an integrated development environment applicable to a program debugging method according to an embodiment of the present application;

[0055] FIG11 exemplarily shows a schematic structural diagram of an electronic device in an embodiment of the present application. DETAILED DESCRIPTION

[0056] The following will clearly and fully describe the technical solutions in the embodiments of the present application in conjunction with the accompanying drawings. The following embodiments can be referenced to each other.

[0057] It is understood that the technical approach of this application is applicable to electronic devices capable of running an integrated development environment, which may specifically include personal computers (PCs), ultra-mobile personal computers (UMPCs), hardware servers (including entry-level servers, workgroup-level servers, department-level servers, and enterprise-level servers), and cloud servers. Electronic devices may also include terminal devices such as tablet computers, laptops, computers, and netbooks.

[0058] The following is an explanation of some terms involved in the embodiments of the present application.

[0059] Forward debugging: Forward debugging is a breakpoint debugging method that tracks the debugging process of program code step by step. During forward debugging, the program starts from the starting point, and the debugger pauses execution at the breakpoints set in the code, allowing the developer to step through the program code and view the values ​​of variables to be observed. Forward debugging can be used to troubleshoot problems such as logic errors and incorrect variable values ​​in the code.

[0060] Reverse debugging: Reverse debugging is an enhanced capability of breakpoint debugging, which allows developers to perform debugging operations in the opposite direction of forward debugging during the debugging process (such as returning to the previous line in the forward debugging process or the last breakpoint position passed), which can effectively improve the developer's debugging experience and problem location efficiency. 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 the debugging process returned in reverse debugging, reverse debugging can be divided into reverse breakpoint debugging and reverse single-step debugging. Through these operations, developers can view the debugging information (also known as historical information) of the debugged program. Reverse debugging can be used to reproduce complex problems that occur in forward debugging, such as multi-threading problems, etc.

[0061] Timeline view: A timeline view displays the time attributes, time position, and time sequence of an object. It is commonly used in software and hardware performance tuning tools, audio and video editing tools, and other tools.

[0062] The technical solution of this application is explained below with reference to specific scenarios.

[0063] Figure 1(a) illustrates an application scenario for an integrated development environment (IDE) application interface. As shown in Figure 1(a), the IDE application interface 100 may include multiple functional areas: a toolbar area 101, a debug area 102, a code area 103, an auxiliary display area 104, and a console area 105. Toolbar area 101 includes multiple controls for implementing IDE application functions, such as query controls and debug controls. The query control is used to query information within the code. The debug control is used to initiate debugging of a program. The program in this context may also be referred to as a target program.

[0064] The debugging area 102 is used to display debugging information of the code corresponding to the program (variable values ​​of variables to be observed, system resource usage, thread information, stack information, etc.), and provide a timeline function for various debugging of the code (such as reverse debugging).

[0065] Developers / testers (hereinafter using developers as an example) can set key points (breakpoints) in the code area 103. For example, they can set a key point for a code line, also known as a code location (e.g., 125). In some embodiments, the method for setting a key point in the code may include: the developer performing a user operation on code line 125 in the code displayed in the code area 103, such as double-clicking the code line. In response to the user operation, a key point identifier 1031 is displayed at code line 125 in the code area 103. During the debugging process, the developer can display the key points in the debugging area 102 using the timeline function. That is, a label (Bookmark) is set for the key point (the key point corresponding to code line 125) and the label is displayed in chronological order on a single timeline. If the developer sets multiple key points in the code, the developer can see multiple labels on the timeline during debugging, and the labels have a temporal relationship, that is, a sequential relationship. The code area 103 can also display the code in the source code file currently displayed by the integrated development environment, as well as the corresponding code line information (line number), code highlighting, and other information.

[0066] 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 segment in the entire code.

[0067] The console area 105 is used to display information generated after debugging the program, including debugging result information, exception information, etc.

[0068] In some embodiments, when the developer wants to backtrace the debugging information corresponding to the key point in debugging, he can directly select the corresponding label in the debugging area 102 to backtrace the debugging information, such as: click the label on the timeline in the debugging area 102, then 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 of the key point, stack information, code exception information, etc.

[0069] However, when developers use the integrated development environment shown in Figure 1(a) to debug a program, if the code involves concurrent execution of multiple threads, the timeline of the debugging area 102 in Figure 1(a) cannot intuitively reflect the thread timing relationship. For example, Figure 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 timeline, for example, including key points corresponding to thread 1 and key points corresponding to thread 2. In other words, in a multi-threaded scenario, it can only reflect the timing relationship between all key points, but cannot reflect the relationship between threads and key points, or the timing relationship between key points corresponding to different threads. When there are many key points, it is difficult to distinguish them, and it is difficult to match key points with specific code locations, and it is impossible to effectively achieve visual positioning of multi-threaded problems.

[0070] In order 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, in the process of debugging a program in an integrated development environment, thread information corresponding to key points set for the program code is obtained, and based on the thread information, a separate timeline is generated for each thread with a corresponding key point, wherein, in a multi-threaded scenario, multiple timelines can be displayed, and the multiple timelines can be arranged in the order of the time when the corresponding threads are started, such as: the timeline corresponding to the thread started first is displayed on the left side of the timeline corresponding to the thread started later, and multiple timelines can be arranged in parallel. Each timeline also includes a direction, and the direction here can be the time sequence of starting the debugging program, that is, the order of the time axis.

[0071] For example, Figure 1(c) shows a schematic diagram of the debug area 102 in the application interface of an integrated development environment in a multi-threaded scenario, using the timeline function to display key points. It can be seen that the debug area 102 of the integrated development environment displays the timeline corresponding to each thread (e.g., timeline 1 corresponding to thread 1, timeline 2 corresponding to thread 2), and each timeline displays the key points of the thread corresponding to the timeline. The position of the key point on the timeline can be the time point (also known as the hit time) when the thread corresponding to the timeline is debugged or the program is running or passes through the key point. The thread information and timing information corresponding to the key point are displayed simultaneously in two dimensions. During the debugging process, developers can directly determine 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 a key point on a timeline to trace the debugging information of the thread behavior corresponding to the timeline, realizing visual debugging and positioning of code under multi-threading. Timeline 1 and timeline 2 in FIG1(c) may be timeline identifiers for the timelines. The numbers 1 and 2 may represent the order in which the threads corresponding to the timelines are started, e.g., thread 1 corresponding to timeline 1 is started earlier than thread 2 corresponding to timeline 2. In some embodiments, the debugging area 102 may distinguish timelines directly using thread identifiers or by combining thread identifiers with timeline identifiers. The thread identifiers here may be thread IDs, developer-defined thread names, and so on.

[0072] In some embodiments, during the debugging process of a program in an integrated development environment, information about the code lines corresponding to key points set in the program code can also be obtained. This information can be used by the integrated development environment to display the code lines for the code where the key points are 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 with the timelines corresponding to the key points, that is, by also displaying the code line information corresponding to the key points on the timeline, developers can observe debugging information for 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.

[0073] It can be seen that through the above program debugging method, when the program involves multi-threaded concurrent execution, the program debugging process is displayed in two ways: thread line display (i.e., multiple timelines) combined with code line information of key points, thereby enhancing the efficiency of program debugging using an integrated development environment; at the same time, the visualization effect of the debugging function of the integrated development environment in a multi-threaded scenario is improved, and the efficiency of developers in locating anomalies / problems in the code is improved.

[0074] In some possible implementations, the program debugging method of the embodiment of the present application can involve two types of key points (breakpoints), such as: first-class key points and second-class key points. For the first-class key points, when the integrated development environment debugger passes through the code of the first-class key points, the integrated development environment will not control the program to suspend execution, but only cache the debugging information of the first-class key points; for the second-class key points, when the integrated development environment debugger passes through the code of the second-class key points, the integrated development environment will control the program to suspend execution. Therefore, developers can choose to set the first-class key points for the code of the program involving multi-threaded concurrent execution, and set the second-class key points for the code subsequent to the first-class key points, for example: set the second-class key points for the code that does not involve multi-threaded concurrent execution in the subsequent process. When the integrated development environment debugger passes through the first-class key points, that is, when passing through the code involving multi-threaded concurrent execution, it can avoid pausing the program multiple times due to multi-threaded concurrent execution; when the integrated development environment debugger passes through the second-class key points, the integrated development environment controls the program to suspend execution, and based on the timeline corresponding to the first-class key points, the debugging information of the first-class key points in the program that has been debugged is displayed by thread splitting.

[0075] In other implementations, only the first type of key points may be displayed on the timeline in the program debugging method, thereby avoiding setting too many key points in the program code, which would result in too many key points being displayed on the timeline during the debugging process.

[0076] FIG2 shows a schematic diagram of the effect of displaying the thread line and displaying the code line information of the key points on the timeline involved in the program debugging method applicable to an embodiment of the present application. According to the content marked as ① in FIG2, in the debugging process of multi-threaded concurrent execution, the integrated development environment can generate a separate timeline for each thread (such as thread 1 to thread 4) of the program code with a key point for debugging, such as timeline 1 to timeline 4. It can be seen that timelines 1 to timeline 4 can be arranged in parallel based on the direction of the time axis, and the starting position of timelines 1 to timeline 4 can be the starting time point of debugging the program by multi-threaded concurrent execution, and the position of the key point in each timeline can be the time point when the thread corresponding to the timeline is debugged or the running program passes the key point. According to the content marked as ② in FIG2, the integrated development environment can obtain the code line of the key point in the code of the multi-threaded concurrent execution, that is, the code line information corresponding to the key point in the source code file corresponding to the code (for example, 123, 45). By fusing the contents of ① and ②, according to the content marked as ③ in FIG2, the key point and the code line information of the key point are displayed on the timeline corresponding to the thread. In Figure 2, the key points displayed on each timeline are the key points in the code corresponding to the debugged program in each thread. In other words, the key points in the undebugged code are not displayed on the timeline. As the program debugging process progresses, the key points in the code will be displayed on the timeline one by one.

[0077] In some embodiments, during the debugging process of the program by the integrated development environment through the multi-threaded concurrent execution mode, each thread may repeatedly debug all / part of the code set with key points. As shown in Figure 3 (a), during the debugging process of the program by the integrated development environment, the time lines of the started thread 39 and thread 40 will respectively display multiple / multiple groups of key points with different positions but the same code lines (for example, key points 31 and 35 are displayed multiple times on time line 39, and key point 48 is displayed multiple times on time line 40). In other words, after each thread debugs the code passing through the key point, the integrated development environment will display the key point on the time line corresponding to the thread. The different positions of the key points with the same code lines on the same time line indicate that the time points when the thread runs the program passing the key point are different. Each key point can also correspond to its own debugging information (i.e., the variable value of the variable to be observed, code exception information, etc.). As can be seen from Figure 3 (a), the integrated development environment can more clearly represent the debugging information of the code that each thread has debugged (or is called the execution process) through the time line. The key points 31, 35 and 48 here can be first-class key points.

[0078] FIG3( b ) shows a flow chart of a 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:

[0079] S301: In response to a first debugging operation on a target program, the integrated development environment debugs the target program through a first target code position of a first code file corresponding to the target program.

[0080] For example, the target program here can be referred to as a program, a program to be debugged, or a debugged program. The first debugging operation is a debugging operation performed on the target program after the developer uses an integrated development environment to open the code of the target program. 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. 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 the second type of key point is set.

[0081] S302: The integrated development environment displays at least a first timeline and a second timeline corresponding to a first target code position, wherein 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.

[0082] Exemplarily, during the debugging process of multi-threaded concurrent execution of a target program, the integrated development environment can 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 first code line information corresponding to the first breakpoint can be displayed on the first timeline, and at least one second breakpoint and 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 located before the first target code position. In other words, the first breakpoint and the second breakpoint can be code lines with first-type key points set in the first code file, and the code lines corresponding to the first breakpoint and the second breakpoint are located before the code line corresponding to the first target code position.

[0083] In some implementations, the lines of code in the first code file corresponding to the first breakpoint and the second breakpoint may be the same, and the first code line information and the second code line information displayed on the first timeline and the second timeline are also the same. The first breakpoint corresponds to first hit time information, which indicates the time when the first thread running the target program passed the first breakpoint; the second breakpoint corresponds to second hit time information, which indicates the time when the second thread running the target program passed the second breakpoint.

[0084] In some implementations, the starting position of the first timeline displayed in the debugging area of ​​the integrated development environment can be the same as the starting position of the second timeline, that is, the 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, 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 position of the first timeline and the starting position of the second timeline. 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 time sequence in which the first thread and the second thread corresponding to the first timeline and the second timeline are started.

[0085] In some implementations, when debugging a target program and passing through a first target code location of a first code file corresponding to the target program, the code area of ​​the integrated development environment switches to display the first code file, that is, the code area of ​​the integrated development environment currently displays the first code file.

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

[0087] S301a: Debugging the target program through the second target code position of the first code file corresponding to the target program.

[0088] 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.

[0089] S302a: Displaying a third breakpoint and third code line information corresponding to the third breakpoint on the first timeline, wherein the third breakpoint corresponds to the second target code position.

[0090] For example, when the first thread is debugging 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, where the code line corresponding to the third breakpoint is located before the code line corresponding to the second target code position.

[0091] In some implementations, the third breakpoint corresponds to the third hit time information, and the third hit time information indicates 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 relative to 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.

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

[0093] S301b: In response to the second debugging operation for 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.

[0094] For example, the second debugging operation is the next debugging operation performed by the developer using the integrated development environment on the target program. The third target code location can be a code line in the second code file, for example, the third target code location can be a code line in the second code file where the second type of key point is set.

[0095] S302b: 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, wherein the fourth breakpoint and the fifth breakpoint correspond to code positions before the third target code position in the second code file.

[0096] Illustratively, the fourth breakpoint and the fifth breakpoint may be code lines having first-type key points 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.

[0097] In some implementations, when the debugging target program passes through a third target code location in the second code file, the code area of ​​the integrated development environment switches to displaying the second code file. The first code line information is hidden on the first timeline, and the second code line information is hidden on the second timeline. The first timeline and the second timeline may only display code line information for breakpoints set in the second code file currently displayed by the integrated development environment, and not display code line information for breakpoints set in first code files not currently displayed.

[0098] The program debugging method of the embodiment of the present application shown in FIG3(b) above may further include a process as shown in FIG3(e), including:

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

[0100] For example, the backtracking operation can involve a developer clicking a first breakpoint on a first timeline to backtrack debugging information about thread behavior corresponding to the first timeline. The code area of ​​the integrated development environment can be switched to display the first code file and highlight code in the first code file based on the first code line information of the first breakpoint.

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

[0102] For example, in addition to displaying the first debugging information of the first breakpoint, the debugging area of ​​the integrated development environment can also 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.

[0103] After introducing the program debugging method provided by the present application and the effects brought about by the program debugging method, the following introduces an architectural diagram of a program development product applicable to the program debugging method of an embodiment of the present application through FIG4 .

[0104] As shown in Figure 4, program development product includes integrated development environment 400 and debugger 500.Wherein, integrated development environment 400 includes debugging module 401, wherein, debugging module 401 has the debugging capability for program (including: forward debugging or reverse debugging etc.), and debugging module 401 can interact with debugger 500.In the embodiment of the present application, the debugger 500 here can be used for debugging program line by line according to the execution order corresponding to the program written, and debugger 500 can correspond to the programming language corresponding to the program written one by one, that is, debugger 500 can be the debugging function module provided by the runtime environment of programming language.In certain embodiments, when the developer opens the code of the program through the integrated development environment to start the debugging program, debugger 500 can receive debugging instructions from debugging module 401, and debug the program based on receiving debugging instructions.After the developer uses integrated development environment 400 to start program debugging, debugging module 401 can send debugging instructions to debugger 500, obtain and save the debugging information returned by debugger 500. The debugging module 401 can also display debugging information within the visual interface of the integrated development environment. During the debugging process of concurrent multi-threaded execution, the debugging information of the program can be displayed by threading in combination with the code line information of key points in the program, that is, providing a visual debugging capability for multi-threaded execution. The debugger 500 is used to debug the program, that is, to execute the corresponding code of the program in a debugging manner and monitor / track the debugging information of the program during the debugging process (such as changes in variables in the storage area, changes in the stack, etc.).

[0105] The debugging module 401 of the integrated development environment 400 shown in FIG4 , which may also be referred to as a program debugging device, is further described below with reference to FIG5 . As shown in FIG5 , the debugging module 401 may include: a debugging server 4011 , a debugging plug-in 4012 and a timeline interface module 4013 .

[0106] The debugging server 4011 can interact with the debugger 500. After the developer uses the integrated development environment 400 to start program debugging, the debugging server 4011 can send debugging instructions to the debugger 500, and the debugger 500 can debug the program according to the debugging instructions. The debugging server 4011 can obtain and save the debugging information returned by the debugger 500. The debugging information here can include all debugging information generated during the debugging process of the debugger 500, including: the number of lines of code debugged, exception information generated, etc. (also known as debugging information required for forward debugging); as well as debugging information and hit time, thread information, and code line information of all key points set in the code. The debugging information of key points can include: the variable values ​​of variables to be observed when the program runs through the key points, the usage of system resources, etc. The debugging server 4011 can store the debugging information, thread information, and code line information of all key points in an orderly manner based on the hit time, that is, store the corresponding relationship between the debugging information of the key points and the hit time, thread information, and code line information of the code line. The corresponding relationship can also be called the basic debugging information of the key points. The debugging server 4011 may also return the saved debugging information required for the normal debugging of the program and the basic debugging information of all key points to the debugging plug-in 4012 .

[0107] The debugging plug-in terminal 4012 is used to display debugging information required for forward debugging in some functional areas of the application interface of the integrated development environment 400, such as displaying exception information in the console area 105. The debugging plug-in terminal 4012 is also used to send the basic debugging information of all key points received to the timeline interface module 4013.

[0108] 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 timeline rendering work 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 correspondence between the debugging information of the key points and the thread information, the thread line display effect is rendered, that is, the timeline and the key points on the timeline are rendered; according to the correspondence between the debugging information of the key points and the hit time, the position of the key points (basic timing) is rendered on the timeline; according to the correspondence between the debugging information of the key points and the stop code line information, the code line information display effect corresponding to the key points is rendered on the timeline.

[0109] In some embodiments, timeline interface module 4013 may be a debugging functional submodule managed by debugging plug-in 4012. Debugging plug-in 4012 may also include any number of other debugging functional submodules. Debugging plug-in 4012 included in debugging module 401 is optional. In other words, debugging server 4011 may directly manage any number of other debugging functional submodules, including timeline interface module 4013. Debugging module 401 may be configured as a separate functional module in integrated development environment 400.

[0110] FIG6 shows a flow diagram of interaction between each functional module in the debugging module 401 described in FIG5 and the debugger 500. The flow diagram may include the following steps.

[0111] S601 : The debugger 500 debugs the debuggee 600 in response to the debugging instruction sent by the debugging server 4011 .

[0112] Exemplarily, the debugged program 600 here may also be referred to as a target program or a program to be debugged, and the debugging instructions here may be debugging instructions generated by a developer using an integrated development environment to open the program code and then perform debugging operations on the debugged program 600.

[0113] S602 : When the debugger 500 hits a key position in the debugged program 600 , the debugger 500 returns debugging information to the debugging server 4011 .

[0114] Exemplarily, the debugging information here may include debugging information corresponding to the debugged program 600 generated when the debugger 500 hits a key position in debugging the debugged program 600, that is, when the debugger 500 debugs or runs the debugged program 600 passing the code line where the key point is located, including: generated exception information, etc. (also known as debugging information required for forward debugging); and debugging information of all key points set in the code and hit time, thread information, and stop code line information.

[0115] S603: The debugging server 4011 automatically saves the debugging information of the key points, and stores the debugging information of all key points in order according to the hit time.

[0116] Exemplarily, the debugging server 4011 can store the correspondence between the debugging information of the key points and the hit time information (i.e., the time when the debugged program 600 passes the key point), thread information, and the stop code line information. The correspondence can also be called the basic debugging information of the key points.

[0117] 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 4012.

[0118] Exemplarily, the debugging plug-in terminal 4012 is used to display debugging information required for forward debugging in a portion of the functional area on the application interface of the integrated development environment, such as displaying exception information and the like.

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

[0120] Exemplarily, the debugging plug-in terminal 4012 here can also send the received basic debugging information of all key points to the timeline interface module 4013. The timeline interface module 4013 specifically displays the basic debugging information of all key points in the function area on the application interface of the integrated development environment.

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

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

[0123] It can be seen that after the integrated development environment 400 of Figure 1 applies the various functional modules of the debugging module 401 shown in Figure 5, without changing the functions included in the original functional areas of the integrated development environment 400, clearer program debugging information can be displayed in one or more functional areas. For example, during the debugging process of multi-threaded concurrent execution, the thread line display effect can be displayed in the debugging area 102 on the application interface of the integrated development environment 400, so that developers can locate the exceptions / problems in the program more quickly.

[0124] In some embodiments, the debugging module 401 of the integrated development environment 400 described in FIG5 can not only display debugging information corresponding to the same or different key points in the code of the program being debugged by multiple threads through a thread line display effect during the debugging process of concurrent multi-threaded execution, but also support developers to backtrack the debugging information of the thread behavior corresponding to the timeline by clicking a key point in one of the timelines, that is, a backtracking operation. The following is a flow diagram of the process of implementing backtracking debugging information between the various functional modules in the debugging module 401 and the debugger 500, which can include the following steps.

[0125] S801: In response to a developer clicking on any key point in the timeline interface module 4013, the timeline interface module 4013 notifies the debugging plug-in terminal 4012 to obtain debugging information of the corresponding key point.

[0126] For example, 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 FIG1 . The notification sent by the timeline interface module 4013 to the debugging plug-in terminal 4012 can be regarded as a notification instruction sent by the timeline interface module 4013. The notification can carry basic debugging information of the key point, including the hit time, thread information, and code line information of the key point.

[0127] S802: After receiving the notification, the debugging plug-in end 4012 requests the debugging server end 4011 for debugging information of the corresponding key points.

[0128] Exemplarily, the debugging plug-in end 4012 forwards the notification to the debugging server end 4011 .

[0129] S803: The debugging server 4011 obtains the debugging information of the corresponding key points and returns it to the debugging plug-in 4012.

[0130] Illustratively, the debugging server 4011 may search for debugging information of key points based on the saved debugging information and the basic debugging information of the key points carried in the notification, and return the information to the debugging plug-in 4012 .

[0131] S804: The debugging plug-in end 4012 refreshes the functional area of ​​the integrated development environment according to the debugging information of the returned key points.

[0132] For example, the functional area here can also be referred to as the debugging page of the integrated development environment, such as the debugging area 102 and code area 103 of the integrated development environment shown in Figure 1. The debugging area 102 may include a thread window, a stack window, and a variable window, respectively used to display the variable values ​​of the variables to be observed, the usage of system resources, thread information, stack information, etc. The code area 103 can display code highlights (source code highlights) based on the code line information corresponding to the debugging information of key points. This enables developers to backtrack the debugging information of specific key points on the timeline.

[0133] It can be seen that the various functional modules corresponding to the debugging module 401 of the integrated development environment 400 described in Figures 6 and 8 can support the visualization of thread information and current line number information of key points based on the timeline, and support backtracing. In particular, in a multi-threaded scenario, the thread information of the key points can be displayed, which can be used to determine the timing relationship of thread behavior, thereby improving the efficiency of locating multi-threaded problems; at the same time, the current line number information of the key points is also displayed, which can be used to determine which of the multiple key points is the key point for which debugging information needs to be viewed, and backtracing can be performed directly by clicking on the key point.

[0134] After introducing the process interaction of the integrated development environment to implement the program debugging method in the embodiment of the present application through the above Figures 6 and 8, the application scenario of the application interface of the integrated development environment (i.e., program development product) applicable to the program debugging method is introduced below.

[0135] As shown in FIG9(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. Specifically, a developer may set key points for the code corresponding to the source code file (hashtable.c in the figure) displayed in the code area 103. As shown in FIG9(a), the developer may set key points for code lines 127, 130, and 133. The key points set for code lines 127 and 130 may be first-class key points, while the key point set for code line 133 may be second-class key points. After the developer initiates debugging of the program using the debug control ① in the toolbar area 101, as shown in FIG9(b), during the debugging process of concurrent multi-threaded execution, the first thread debugging or running the program passes through code lines 127 and 130 (also referred to as key points 127 and 130) and pauses execution at code line 133 (key point 133). The debugging area 102 can display the timeline 1 corresponding to the first thread, wherein the key points corresponding to code lines 127, 130, and 133 at different locations and the code line information corresponding to the key points are displayed on the timeline 1. For example, the code line information is displayed at the location of the key point on the timeline 1 or to the side of the key point. The different locations of the key points indicate that the first thread debugger passes through the key points at different times. As can be seen, the key point corresponding to code line 133 may be located later on the timeline 1. In some embodiments, the timeline 1 may also only display the key points corresponding to code lines 127 and 130, i.e., the first type of key points. The debugging area 102 can display the debugging information of the first thread debugging program passing through code line 133 (e.g., the variable value 110 of the variable to be observed xxxxx, etc.). If the first thread repeatedly debugs code lines 127 and 130, multiple groups of key points and code line information corresponding to code lines 127 and 130 will be displayed on the timeline 1. The different locations of the multiple groups of key points indicate that the first thread debugger passes through each key point at different times. As shown in FIG9( c ), the first thread debugs through code lines 127 and 130 twice, and two groups (the first group and the second group) of key points corresponding to code lines 127 and 130 are displayed on timeline 1 respectively.

[0136] Continuing with FIG9(c), if the developer clicks on the label of the key point 130 in the second group (the second group) on timeline 1 to backtrack the debugging information of the thread behavior key point 130 corresponding to timeline 1, as shown in FIG9(d), the debugging information displayed in the debugging area 102 will also change (e.g., the variable value of the variable to be observed xxxxx is 111). If the developer clicks on the label of the first group (the first group) on timeline 1 to backtrack the debugging information of the thread behavior key point 130 corresponding to timeline 1, as shown in FIG9(e), the debugging information displayed in the debugging area 102 will also change (e.g., the variable value of the variable to be observed xxxxx is 222).

[0137] It can be seen that after debugging the code passing through the key point through the first thread, the key point will be displayed on timeline 1. The different positions of the key point on the same line of code on the same timeline 1 indicate that the first thread debugging program passed the key point at different times. Developers can click the label of the key point on timeline 1 to trace the debugging information of the key point and realize visual debugging positioning of the code.

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

[0139] In some embodiments, if there are more than two threads (such as the first thread to the fourth thread) debugging program, as shown in Figures 9(h) to 9(i), the debugging area 102 can display a scroll control 1021, and the developer can control the scroll control 1021 to switch between the timelines corresponding to multiple threads, for example: scrolling to display timeline 1 to timeline 4.

[0140] It can be seen that in the application scenario of the integrated development environment applicable to the program debugging method described in Figures 9(a) to 9(h), the target program or the program to be debugged corresponds to only one source code file. In other implementations, 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 code line information of the key points set in the source code file currently displayed by the integrated development environment. For source code files that have been opened but not displayed, the code line information of the key points set in the source code file is not displayed. For source code files that have not been opened, the key points set in the source code file and the code line information are not displayed.

[0141] As shown in Figure 10(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. The developer opens two source code files corresponding to the program in the code area 103 (the first source code file is hashtable.c in the figure, and the second source code file is xxxxfile.c). The execution order of the first source code file can be earlier than the second source code file, and during the debugging process, 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 code lines 127 and 130 of the first source code file. As shown in Figure 10(b), the developer can also switch to the second source code file in the code area 103 and set key points for code lines 128 and 131 of the second source code file.

[0142] After the developer initiates debugging of the program using the debug control ① in the toolbar area 101, as shown in FIG10(c), during the debugging process of concurrent multi-threaded execution, the integrated development environment can start the first thread and the second thread. The first thread and the second thread debug the program through code lines 127 and 130 of the first source code file, respectively. The code area 103 displays the code of the first source code file, and the debugging area 102 can display timelines 1 and 2 corresponding to the first thread and the second thread. Timelines 1 and 2 will display the key points and code line information corresponding to code lines 127 and 130 in the first source code file. As shown in FIG10(d), the first thread and the second thread debug the program through code lines 128 and 131 of the second source code file. The code area 103 displays the code of the second source code file, and timelines 1 and 2 will additionally display the key points and code line information corresponding to code lines 128 and 131 in the second source code file. At this time, in some implementations, timeline 1 and timeline 2 will no longer display the code line information of the key points corresponding to code lines 127 and 130 in the first source code file.

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

[0144] It can be seen that in the application scenarios of the integrated development environment applicable to the program debugging method described in the above Figures 10(a) to 10(e), when 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 can only display the code line information of the key points set in the source code file currently displayed by the integrated development environment, and not display the code line information of the key points set in the source code files not currently displayed, so that developers can locate the anomalies / problems in the code more quickly during the debugging process.

[0145] The above describes in detail the method of the embodiment of the present application. In order to facilitate better implementation of the above scheme of the embodiment of the present application, correspondingly, related equipment for cooperating in implementing the above scheme is also provided below.

[0146] Figure 11 is a schematic diagram of the structure of an electronic device 1100 for running an integrated development environment provided by the present application. As shown in Figure 11, 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 connected to each other through an internal bus 1140, or communication can be achieved through other means such as wireless transmission. The embodiment of the present application takes 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 computer 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, and a status signal bus. However, for the sake of clarity, various buses are labeled as bus 1140 in the figure.

[0147] 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 hardware chip may be an application-specific integrated circuit (ASIC), a programmable logic device (PLD), or a combination thereof. The 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 digitally stored instructions, such as digitally stored instructions in software or firmware programs stored in the memory 1130, enabling the electronic device 1100 to provide a variety of services.

[0148] Memory 1030 is used to store program code, and is controlled by processor 1110 for execution to perform the processing steps of the obstruction identification method in the above-mentioned embodiment. The program code may include one or more software modules, which may be the software modules provided in the embodiment of FIG8 , 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 the multiple APs, and the signal strength between multiple AP pairs. The generation unit is used to generate path loss value pairs between the terminal and the AP pairs, as well as path loss values ​​for the AP pairs, based on the acquired power of the multiple APs, the signal strength between the terminal and the multiple APs, and the signal strength between the multiple AP pairs. The determination unit is used to compare a first path loss value and a second path loss value between a first AP and a second AP to determine whether there is an obstruction between the first AP and the second AP. The first path loss value is the measured signal loss between the first AP and the second AP, and the second path loss value is a path loss value inferred from the path loss value pairs between the terminal and each of the multiple AP pairs.

[0149] Memory 1130 may include volatile memory, such as random access memory (RAM); memory 1030 may also include non-volatile memory (NVM), such as read-only memory (ROM), flash memory, a hard disk drive (HDD), or a solid-state drive (SSD); and memory 1130 may also include a combination of the above. Memory 1130 may store program code to specifically execute steps S510 to S530 and the optional steps in the embodiment of FIG. 5 , which will not be further described here.

[0150] The communication interface 1120 can 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.

[0151] It should be noted that FIG11 is only a possible implementation of an embodiment of the present application. In actual applications, the electronic device 1100 may also include more or fewer components, which is not limited here.

[0152] It should be understood that this embodiment can be implemented by a general physical server, for example, an ARM server or an X86 server, or it can 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. This application does not make any specific limitations.

[0153] The electronic device 1100 shown in FIG11 may also be a computer cluster composed of at least one server, which is not specifically limited in this application.

[0154] An embodiment of the present application further provides a computer-readable storage medium, in which instructions are stored. When the computer-readable storage medium is executed on a processor, the method flow shown in FIG5 is implemented.

[0155] It is understood that the structures illustrated in the embodiments of the present application do not constitute specific limitations on electronic devices. In the embodiments of the present application, electronic devices (such as mobile phones, car computers, etc.) may include more or fewer components than shown in the illustrations, or combine or separate certain components, or arrange the components differently. The illustrated components may be implemented in hardware, software, or a combination of software and hardware.

[0156] 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 software is used for implementation, 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 process or function according to the embodiment of the present application is generated in whole or in part. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another computer-readable storage medium. For example, the computer instructions can be transmitted from a website, computer, server or data center to another website, computer, server or data center via a wired (e.g., coaxial cable, optical fiber, digital subscriber line) or wireless (e.g., infrared, wireless, microwave, etc.) method. The computer-readable storage medium can be any available medium that a computer can access or a data storage device such as a server or data center that includes one or more available media integrations. The available medium can be a magnetic medium (e.g., a floppy disk, a hard disk, a tape), an optical medium (e.g., a DVD), or a semiconductor medium (e.g., a solid-state hard disk).

[0157] Those skilled in the art will appreciate that all or part of the processes in the embodiments of the present application can be implemented by a computer program that instructs the relevant hardware to perform the processes. The program can be stored in a computer-readable storage medium, and 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 code, such as read-only memory (ROM) or random access memory (RAM), a magnetic disk, or an optical disk.

[0158] It should be understood that although the terms "first," "second," and the like may be used herein to describe various features, these features should not be limited by these terms. These terms are used merely to distinguish and should not be understood to indicate or imply relative importance. For example, a first feature may be referred to as a second feature, and similarly, a second feature may be referred to as a first feature, without departing from the scope of the embodiments of the present application.

[0159] In addition, the various operations will be described as multiple separate operations in a manner that is most helpful for understanding the embodiments of the present application; however, the order of description should not be interpreted as implying that these operations must rely on the order of description, and many of the 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 processing can be terminated, but it can also have additional operations not included in the drawings. The processing can correspond to a method, function, procedure, subroutine, subprogram, etc.

[0160] Unless the context dictates otherwise, the terms "comprising," "having," and "including" are synonymous. The phrase "A / B" means "A or B." The phrase "A and / or B" means "(A), (B), or (A and B)."

[0161] As used herein, the term "module" may refer to, be part of, or include: memory (shared, dedicated, or group) for running one or more software or firmware programs, application-specific integrated circuits (ASICs), electronic circuits and / or processors (shared, dedicated, or group), combinational logic circuits, and / or other suitable components that provide the functionality.

[0162] In the accompanying 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 required. Instead, in the embodiments of the present application, these features may be described in a manner and / or order different from that shown in the illustrative drawings. In addition, the structural or method features included in a specific drawing do not mean that such features are required to be included. In the embodiments of the present application, these features may not be included, or they may be combined with other features.

[0163] The embodiments of the present application are described in detail above with reference to the accompanying drawings. However, the application of the technical solution of the present application is not limited to the various applications mentioned in the embodiments of the present application. Various structures and variations can be easily implemented with reference to the technical solution of the present application to achieve the various beneficial effects mentioned herein. Various changes made within the scope of knowledge possessed by ordinary technicians in this field without departing from the purpose of the present application should be included in the scope of the patent 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, wherein 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, wherein: 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 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: a straight line passing through the first breakpoint and the second breakpoint is not parallel to a straight line passing through the starting positions of the first timeline and the second timeline.

6. The method according to any one of claims 1-5, wherein: 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-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 to 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 on the target program, debug the target program from the first code file to the third target code location of the second code file corresponding to the target program and passing through the second code file; Display at least one fourth breakpoint and the fourth code line information corresponding to the fourth breakpoint on the first timeline, and display 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 locations in the second code file before the third target code location.

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 location 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 on the first breakpoint, the code area of the integrated development environment is switched to display the first code file and the code highlighting the first code line information in the first code file.

14. The method according to any one of claims 10-12, characterized in that, Further includes: In response to a backtracking operation on the first breakpoint, the debugging 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 code line information.

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

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 on the target program, debugs the target program through the first target code location of the 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 location in the debugging area of the integrated development environment, where the first timeline corresponds to the first thread running the target program, and the second timeline corresponds to the 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 on the target program, debugs the target program through the first target code location of the 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 location, where the first timeline corresponds to the first thread running the target program, and the second timeline corresponds to the 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 program stored in the memory is executed, the processor is used to implement the method according to any one of claims 1-15.

Images