JP2024128281A - Debugging device, debugging system, debugging method, and debugging program - Google Patents

Abstract

[Problem] In a fault-tolerant server, it is possible to perform debugging in one system and continue business in the other system not performing debugging. [Solution] The debugging device comprises a setting unit configured to read a portion including an instruction for setting a breakpoint in a program to be debugged into a debug area in the memory of each of the systems operating in synchronization, and to rewrite the instruction with a breakpoint instruction in a system used for debugging among the systems operating in synchronization, thereby suppressing page-out of the debug area, and an exception processing unit configured to release the synchronization of the systems operating in synchronization when a breakpoint exception occurs. [Selected Figure] Figure 1

Description

The present invention relates to a debugging device, a debugging system, a debugging method, and a debugging program.

Generally, when a user debugs, they need to set breakpoints in the business AP, OS, drivers, etc., and stop the business AP or the entire system at the set breakpoints in order to obtain debugging information such as the server's registers, stack, and memory data.

On the other hand, there are fault-tolerant (FT) servers, which are configured to prevent the entire system from stopping, that is, servers that continue processing normally even if some of their components fail. A fault-tolerant server is a highly available server that has duplicated hardware components and is equipped with a mechanism that prevents the system from stopping even when a failure occurs.

For availability, the FT server has a duplicated system, with the memory contents of both systems being made identical, and lockstep technology, which synchronizes the processors of each system on a clock-by-clock basis for redundancy, ensures that both systems operate in exactly the same way. This means that in the event of a failure, the affected CPU subsystem can be logically isolated, allowing operation to continue on the healthy system.

However, using normal means, it is not possible to set a breakpoint on only one of the FT server systems, so when a breakpoint is set for debugging, both FT server systems must be stopped. In other words, in a duplicated FT server, due to lockstep technology that synchronizes the processors and memory of both systems on a clock-by-clock basis to provide redundancy, it is not possible to stop only one system at a breakpoint, even after the two systems are separated. Therefore, just like with a general-purpose server, when a breakpoint is set for debugging, it is necessary to stop the business AP or the entire system.

Related technologies include prohibiting swap-out when relocating files (Patent Document 1), checking the CPU information of both systems with a single external debugger to investigate causes such as desynchronization of the FT servers (Patent Document 2), desynchronizing the FT server and splitting it into two systems, continuing business operations on one while taking a backup on the other, thereby taking a backup without affecting business operations (Patent Document 3), monitoring breakpoints set in a program and stopping program execution when a certain condition is met (Patent Document 4), and splitting the FT server into two systems that operate independently by intentionally and temporarily desynchronizing it (Patent Document 5).

Japanese Patent Application Publication No. 62-245445 Patent No. 5477725 JP 2013-206052 A JP 2013-206061 A JP 2022-036778 A

Since both systems in a duplicated FT server operate in the same way, it should be sufficient to perform debugging on only one of the systems, and operations should be able to continue on the system not being debugged. However, for the reasons mentioned above, this was not possible, which was an issue.

The present invention provides a debugging device, a debugging system, a debugging method, and a debugging program.

A first aspect of the present invention is a debugging device including a setting unit configured to read a portion of a program to be debugged, including an instruction for setting a breakpoint, from a debug area of each memory of systems operating in synchronization with each other, and to rewrite the instruction with a breakpoint instruction in a system used for debugging among the systems operating in synchronization with each other, thereby suppressing a page-out of the debug area;
an exception handler configured to desynchronize the synchronously operating systems when a breakpoint exception occurs;
The present invention is characterized by comprising:

A second aspect of the present invention is a debugging system including:
The above debugging equipment;
The present invention is characterized by comprising:

A third aspect of the present invention is a debugging method comprising the steps of: reading, into a debug area of a memory of each of systems operating in synchronization with each other, a portion of a program to be debugged that includes an instruction at which a breakpoint is set; rewriting, in a system used for debugging among the systems operating in synchronization with each other, the instruction with a breakpoint instruction; and suppressing a page-out of the debug area;
desynchronizing said synchronously operating systems when a breakpoint exception occurs;
The present invention is characterized by having the following.

A fourth aspect of the present invention provides a setting unit configured so that a debug program reads out a portion of a program to be debugged, including an instruction at which a breakpoint is set, into a debug area of each memory of systems operating in synchronization with each other, and rewrites the instruction in a system used for debugging among the systems operating in synchronization with each other with a breakpoint instruction, thereby suppressing page-out of the debug area; and an exception processing unit configured to release synchronization between the systems operating in synchronization with each other when a breakpoint exception occurs.
The present invention is characterized in that the computer functions as a

According to this invention, the user can continue running a business AP on one side of the FT server while stopping the other side at a breakpoint to obtain the necessary debug information.

FIG. 2 is a diagram showing the configuration of a debugging device according to an embodiment of the present invention. FIG. 2 illustrates the synchronized and de-synchronized states of an FT server according to an embodiment of the invention. 4 is a flowchart of setting a breakpoint according to an embodiment of the present invention. FIG. 4 is a diagram showing the memory states (1) of system 0 and system 1 at each step in FIG. 3. FIG. 4 is a diagram showing the memory states (2) of system 0 and system 1 at each step in FIG. 3. FIG. 4 is a diagram showing the memory states (3) of System 0 and System 1 at each step in FIG. 3. FIG. 4 is a diagram showing the memory states (4) of System 0 and System 1 at each step in FIG. 3. FIG. 4 is a diagram showing the memory states (5) of System 0 and System 1 at each step in FIG. 3. 13 is a flowchart showing a process from debugging to recovery in an FT server according to an embodiment of the present invention. FIG. 13 illustrates the synchronized and de-synchronized states of an FT server according to another embodiment of the present invention.

First, the basic configuration and operation of an embodiment of the present invention will be described. The user sets a breakpoint. A breakpoint is set by rewriting an instruction in a relevant memory location into an instruction that generates a breakpoint exception. The opportunity to start debugging occurs when the FT server executes this instruction and a breakpoint exception occurs. This opportunity makes it possible to release the synchronization of the FT server and split it into two systems (system 0 and system 1) that operate independently. While the synchronization is released, system 0 and system 1 can each be operated for different purposes.

In one embodiment, the above debugging method can be realized using a debugging device. The debugging device may realize its functions using hardware and software, for example, by reading a program from a disk of the server and having the server's processor execute the program. Alternatively, the functions of the debugging device may be realized as a circuit or device within the server. The debugging device may be controlled using commands from a terminal.

Figure 1 is a diagram showing the configuration of a debugging device according to an embodiment of the present invention. The debugging device 100 includes a setting unit 110 and an exception processing unit 120. The setting unit 110 is configured to read a portion of a program to be debugged that includes an instruction for setting a breakpoint in a debug area of each memory of systems operating synchronously in a fault-tolerant server, and rewrite the instruction with a breakpoint instruction in a system used for debugging among the systems operating synchronously, thereby suppressing page-out of the debug area. The exception processing unit 120 is configured to release the synchronization of the systems operating synchronously in the fault-tolerant server when a breakpoint exception occurs.

In this way, by taking advantage of the feature of the FT server that it can be desynchronized and divided into two systems that operate independently, a business AP can be run on one system of the FT server while the other system of the FT server stops the business AP with an instruction that has a breakpoint set, allowing the user to obtain debug information such as register, stack, and memory data.

Below, we will explain in more detail the configuration and operation of an FT server in an embodiment of the present invention.

Figure 2 is a diagram showing the synchronized and desynchronized states of the FT server 10 according to an embodiment of the present invention. The left side of Figure 2 shows the synchronized state, and the right side shows the desynchronized state after desynchronization.

The FT server 10 has two central processing unit (CPU) modules, two memories (not shown), two FT controllers, and two input/output (IO) modules. The IO module has a network interface card (NIC) and a disk (storage device). The FT server 10 connects to the network via the NIC. The CPU module and the IO module have debug ports. Debug port 0, debug port 1, debug port 0', and debug port 1' are provided in CPU module 0, CPU module 1, IO module 0, and IO module 1, respectively, and can be connected from the debug terminal 12 via the changeover switch 11.

In the synchronized state shown on the left side of Figure 2, one OS is running, and under the control of this OS, CPU module 0 and CPU module 1, FT controller 0 and FT controller 1 are synchronized, and IO module 0 (NIC 0, disk 0) and IO module 1 (NIC 1, disk 1) are duplicated.

In the desynchronized state shown on the right side of Figure 2, the OS operates separately as OS#1 and OS#2, and in the synchronized state, FT server 10 operates as a single system, but is now divided into two systems: system 0 (CPU module 0, memory for system 0, FT controller 0, IO module 0) and system 1 (CPU module 1, memory for system 1, FT controller 1, IO module 1). IO module 0 (NIC 0, disk 0) and IO module 1 (NIC 1, disk 1) remain duplicated. In other words, they are used in a duplicated state from system 1 and system 2.

When debugging is to be performed after desynchronization has been released, the debug terminal 12 is connected to the debug port (debug port 1) of the system to be debugged (here, system 1) using the changeover switch 11. Necessary debug information such as register information, stack information, and memory data is obtained using the debug command. Because the FT server 10 has been desynchronized and divided into two systems that operate independently, the OS and running processes are not aware that only one system is being operated. In other words, the user can extract data for analysis and investigation without being visible to the OS and running processes. After the user has finished debugging, system 0, which has continued to operate for business processing, becomes the master, system 1, which was used for debugging, is incorporated, and a synchronized state can be restored.

Next, the above-described flow of transition from a synchronized state to a desynchronized state and return to a synchronized state will be described in detail with reference to FIG. 3. FIG. 3 is a flowchart of setting a breakpoint according to an embodiment of the present invention.

The outline of Figure 3 is as follows. The user sets a breakpoint that will trigger debugging. A breakpoint is set by rewriting instructions in the relevant memory to instructions that will cause a breakpoint exception. As shown in Figure 3, when implementing the debugging method according to an embodiment of the present invention on the FT server 10, when rewriting instructions in memory, only the memory in one system is rewritten. Also, when the contents of memory are written to disk by paging out, a check is made to see if the memories in both systems match, so it is necessary to suppress paging out for pages with mismatched contents.

The specific procedure shown in FIG. 3 is as follows. In step S11, a page containing an instruction to set a breakpoint is paged in. For example, a program portion of a predetermined unit containing an instruction for setting a breakpoint in the business AP to be debugged is read from the disk to memory. The instruction to set a breakpoint is, for example, instructed by the user using the debug terminal 12. The other steps S11 to S15 may be executed by, for example, the setting unit 110 of the debugging device 100 in FIG. 1. When paging in, a debug area is loaded into a certain page (page number 0 in this case) of the memory of each system (FIG. 4). That is, in FIG. 4, a page containing an instruction to set a breakpoint is loaded as a debug area into page number 0 of the memory of each of systems 0 and 1. Next, in step S12, a page containing an instruction to set a breakpoint is locked in memory. For example, a general OS function (API) such as API mlock of the Linux (registered trademark) OS is used to lock the target memory area (FIG. 5). That is, the page with page number 0 of the memory of each of systems 0 and 1 is locked. After that, in step S13, both systems stop operating and the duplex state is released. That is, the FT server releases the synchronization of the memories of both systems (FIG. 6). In the released state of synchronization, in step S14, the instructions at the address where the breakpoint is set only in system 1 are rewritten. That is, only the instructions in the memory of system 1 to be debugged are rewritten (FIG. 7). After the rewriting, in step S15, duplex is restored and system operation is resumed. That is, the synchronized state is restored (FIG. 8). In this state, the contents of the memories of both systems are inconsistent, but because the memories are locked and page-outs are suppressed, the OS does not detect the memory inconsistency.

Next, the process from debugging to recovery in the FT server 10 will be described. After the procedure shown in FIG. 3 is performed, for example, the business AP to be debugged is operated in the FT server 10. In step S21 of FIG. 9, a breakpoint exception occurs only in the system 1 system, and the exception handler (exception processing unit 120 in FIG. 1) starts to execute. After the breakpoint exception occurs, in step S22, the synchronization between the system 0 system and the system 1 system is released. That is, the exception handler disconnects the system 1 system, and only the system 0 system continues to operate. In step S23, the switch connecting the debug port and the debug terminal 12 is connected to the system 1 system, and control is transferred to the debug terminal 12. In step S24, a debug command is received from the debug terminal 12, and debug information such as register, stack, and memory information is obtained. As a result, the user obtains necessary debug information such as register information, stack information, and memory data by the debug command. The system 0 system continues to operate the business AP. After debugging is completed, in step S25, only system 1 used for debugging is reset or powered off, thereby clearing the memory information of system 1. After that, in step S26, system 0, which continues to operate, becomes the master, and system 1 used for debugging is incorporated. Steps S25 and S26 may be performed by the user inputting commands individually, or the debugging device 100 in FIG. 1 may further include a recovery processing unit (not shown), and the user may use a command to cause the recovery processing unit to execute steps S25 and S26. In step S27, systems 0 and 1 are synchronized to continue operations. This causes the FT server 10 to return to duplication.

As described above, when a user debugs on the FT Server, the FT Server follows commands from the debugging terminal to rewrite instructions in memory only on the system being debugged to generate a breakpoint, and also suppresses page-outs so that memory inconsistencies between the two systems are not detected by page-outs. When a breakpoint exception occurs for debugging and the exception handler begins execution, the FT Server releases synchronization between the two systems and automatically cancels the lockstep function. This allows the user to independently collect fault information on only the system where the breakpoint was set, while the other system can continue operations without being affected by debugging.

As described above, the user can continue running business APs on one side of the FT server, while stopping them at a breakpoint on the other side, and obtain the necessary debug information such as register information, stack information, memory data, etc. In this case, the FT server's feature of being able to separate the processor and memory into two systems that can be desynchronized and run independently is utilized, so the fact that only one side is being used is not noticeable to the OS or running processes. In other words, data for analysis or investigation can be extracted without being seen by the OS or running processes.

Next, another embodiment of the present invention will be described with reference to FIG. 10. The synchronized state shown on the left side of FIG. 10 is the same as the synchronized state shown on the left side of FIG. 2. In the desynchronized state shown on the right side of FIG. 2, the OS operates separately as OS#1 and OS#2, and the duplication of IO module 0 (NIC0, disk 0) and IO module 1 (NIC1, disk 1) remains the same, but in the desynchronized state shown on the right side of FIG. 10, all systems, including the IO modules, are separated.

By intentionally disabling the FT server synchronization, the user can split it into two systems (system 0 and system 1) that operate independently, and while synchronization is disabled, separate tasks can be carried out on system 0 and system 1. In addition, when isolating one system (disabling synchronization), the user can obtain all of the data for that system by disconnecting everything, including the IO module.

After releasing the synchronization, the user connects a debug terminal to debug port 1', which is the debug port for the system used for debugging, and obtains the necessary debug information such as register information, stack information, and memory data using debug commands.

The OS has two paths to the IO modules, and if one of them fails, that bus is disconnected and operations continue on the other bus. Therefore, the degeneration of the IO module is visible from the operational system, but since both IO modules before disconnection were in a duplicated state and performed exactly the same operation, even after disconnecting one system, it is possible to continue operations on the other system while debugging the entire IO module of the disconnected system.

After debugging is completed, the FT server will make system 0, which was continuing operations, the master and incorporate system 1, which was used for debugging, and return to a synchronized state.

As mentioned above, when isolating one system (de-synchronization), everything is isolated, including the input/output (IO) module, allowing the user to obtain all of the data from the system. The OS has paths to two IO modules, and if a problem occurs on one of them, that bus is isolated and operations continue on the other bus. Therefore, unlike the above, the degeneration of the IO module is recognized from the operational system. Note that both IO modules are in a duplicated state before isolation and operate in exactly the same way, so even after isolating one system, it is possible to continue operations on the other system while debugging the entire IO module of the isolated system.

The processing steps performed by the computer system described above are stored in the form of a program on a computer-readable recording medium, and the computer reads and executes this program to perform the above processing. Here, computer-readable recording medium refers to a magnetic disk, magneto-optical disk, CD-ROM, DVD-ROM, semiconductor memory, etc. Also, this computer program may be distributed to a computer via a communication line, and the computer that receives the distribution may execute the program.

The above program may also be transmitted from a computer system in which the program is stored in a storage device or the like to another computer system via a transmission medium, or by transmission waves in the transmission medium. Here, the "transmission medium" that transmits the program refers to a medium that has the function of transmitting information, such as a network (communication network) such as the Internet or a communication line (communication line) such as a telephone line. The above program may also be one that realizes part of the above-mentioned functions. Furthermore, it may be a so-called difference file (difference program) that can realize the above-mentioned functions in combination with a program already recorded in the computer system.

The present invention can be used to debug systems that operate synchronously.

10, 20 FT server 11 switch 12 debug terminal 100 debug device 110 setting unit 120 exception processing unit

Claims (8)

1. A debugging device, comprising:
a setting unit configured to read a portion of a program to be debugged, including an instruction for setting a breakpoint, in a debug area of each memory of the systems operating in synchronization with each other, and to rewrite the instruction with a breakpoint instruction in a system used for debugging among the systems operating in synchronization with each other, thereby suppressing a page-out of the debug area;
an exception handler configured to desynchronize the synchronously operating systems when a breakpoint exception occurs;
1. A debugging apparatus comprising: The debugging device according to claim 1, wherein the exception processing section maintains duplication of the input/output modules of the synchronously operating system when a breakpoint exception occurs. The debugging device according to claim 1, wherein the exception processing unit separates input/output modules of the synchronously operating systems for each system when a breakpoint exception occurs. The debug device according to claim 1, further comprising a recovery processing unit configured to, after releasing the synchronization, synchronize the system by incorporating the system used for debugging into a system other than the system used for debugging that operates in synchronization with the system other than the system used for debugging as a master. The debugging device according to claim 1, wherein the setting unit is controlled by a debugging terminal. A fault-tolerant server;
A debugging device according to any one of claims 1 to 5,
A debugging system comprising: 1. A debugging method, comprising:
reading a portion of a program to be debugged including an instruction at which a breakpoint is set in the program to be debugged into a debug area of each memory of the systems operating in synchronization with each other, and rewriting the instruction with a breakpoint instruction in a system used for debugging among the systems operating in synchronization with each other, thereby suppressing a page-out of the debug area;
desynchronizing said synchronously operating systems when a breakpoint exception occurs;
A debugging method having the following steps: a setting unit configured to read a portion of a program to be debugged, including an instruction for setting a breakpoint, into a debug area of each memory of the systems operating in synchronization with each other, and to rewrite the instruction with a breakpoint instruction in a system used for debugging among the systems operating in synchronization with each other, thereby suppressing page-out of the debug area; and an exception processing unit configured to release the synchronization of the systems operating in synchronization with each other when a breakpoint exception occurs.
A debugging program that allows a computer to function as a

Images