WO2014120200A1 - Methods and apparatus for debugging of remote systems - Google Patents
Methods and apparatus for debugging of remote systems Download PDFInfo
- Publication number
- WO2014120200A1 WO2014120200A1 PCT/US2013/024116 US2013024116W WO2014120200A1 WO 2014120200 A1 WO2014120200 A1 WO 2014120200A1 US 2013024116 W US2013024116 W US 2013024116W WO 2014120200 A1 WO2014120200 A1 WO 2014120200A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- computer system
- software code
- data
- remote computer
- data elements
- Prior art date
Links
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
- G06F11/3636—Software debugging by tracing the execution of the program
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/362—Software debugging
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/36—Preventing errors by testing or debugging software
- G06F11/3664—Environments for testing or debugging software
Definitions
- a debugger is a software application that a programmer may use to debug software code.
- a debugger typically contains tools to assist a programmer in the debugging process, such as allowing the software code to be executed one line at a time, allowing the programmer to examine the contents of certain data structures associated with the software code, and so forth.
- FIG. 1 is a block diagram of an example debugging system constructed in accordance with the teachings of this disclosure.
- FIG. 2 is a block diagram of an example implementation of the example debugger of FIG. 1 .
- FIG. 3 is JAVA code representative of an annotation declaration for use in the example debugging system of FIG. 1 .
- FIGS. 4 and 5 are flowcharts representative of example machine readable instructions that may be executed to implement the example debugging system of FIG. 1 .
- FIG. 6 is a block diagram of an example processing system capable of executing the example machine readable instructions of FIGS. 4 and 5 to implement the example debugging system of FIG 1 .
- Software code on the remote computer system can be remotely debugged by a programmer who is physically present at the local computer system by establishing a network connection between the local computer system and the remote computer system.
- maintaining a network connection between the local computer system and the remote computer system while the software code is being debugged may consume significant resources on the remote computer system. This resource usage can potentially prevent the remote computer system from running other applications or processes.
- software code can be debugged entirely on a local computer system, wherein software code on the local computer system is the same as the software code on the remote computer system at the time when a programmer starts debugging. After debugging on the local computer system is complete, any changes made to the software code on the local computer system can be made to the software code on the remote computer system.
- This approach of debugging software entirely on the local computer system may not maintain an open connection between the local computer system and the remote computer system while debugging. However, this approach does not perform debugging using the data on the remote computer system.
- software code When software code is executed, it typically manipulates some amount of data. For example, software code might access data from a database, create several variables or other data objects to use while the software code is executing and add, delete or modify data from the database. As such, when the software code is executing it operates on data that may vary during and/or as a result of execution of the software code. Software code often responds differently when operating on different data. For example, certain bugs in software code might only appear when the software code is operating on certain data. Therefore, in order to effectively debug software code on a remote computer system from a local computer system, examples disclosed herein provide the local computer system with access to data on the remote computer system. In some examples, the data connection between the local computer system and the remote computer system is not maintained throughout the debugging to reduce the resource load on the remote computer system.
- Example methods, apparatus, and/or articles of manufacture disclosed herein provide a mechanism for offline debugging of a remote computer system
- the term offline is expressly defined to mean a state in which a data connection utilized for retrieving data for the debugging from a remote computer system is closed such that there can be no further communication on the data connection without taking an action to establish the data connection.
- examples disclosed herein allow for debugging of software code on a remote computer system from a local computer system, using data from the remote computer system without maintaining an open connection between the local computer system and the remote computer system.
- certain (e.g., key) sections of the software code are marked to indicate that those sections contain data elements that will likely be of interest (e.g., important) for debugging.
- This marked software code is present on both the local computer system and the remote computer system.
- the example software code to be debugged resides on both the example local computer system and the example remote computer system. During normal operation, the example software code executes on the example remote computer system.
- the example local computer system establishes a connection to the example remote computer system and requests marked data.
- the example remote computer system copies a data snapshot including the requested data to the example local computer system.
- the connection between the local computer system and the remote computer system is closed.
- the example software code is then executed on the example local computer system using the data copied from the example remote computer system while the connection remains closed, thereby reducing the usage of network resources.
- the software code is debugged on the local computer system using a debugger.
- an open connection is not maintained between the example local computer system and the example remote computer system during the full duration of the debugging process (e.g., the open connection is only maintained during the time it takes to copy a data snapshot from the remote computer system to the local computer system)
- the use of the remote computer system's resources is reduced (e.g., minimized).
- the software code executes on the local computer system in the same manner that the software code executes on the remote computer system. Accordingly, any bugs that would be present upon execution of the example software code on the example remote computer system will also be present upon execution of the software code on the example local computer system.
- the example software code can be debugged on the example local computer system just as if the software code were being debugged on the example remote computer system.
- the local computer system if updated data from the example remote computer system is needed while the example software is being debugged on the example local computer system, the local computer system establishes a new connection to the remote computer system to receive the updated data (e.g., a new data snapshot) from the remote computer system.
- the updated data e.g., a new data snapshot
- a copy of the debugged software code is transferred to the example remote computer system so that the remote computer system has the same debugged software code as the local computer system.
- FIG. 1 is a block diagram of an example debugging system 100 constructed in accordance with the teachings of this disclosure.
- the example system 1 00 of FIG. 1 includes a local computer system 102 and a remote computer system 1 10.
- the local computer system 102 is able to communicate with the remote computer system 1 1 0 and vice versa via a network 1 1 6.
- the example network 1 1 6 allows a connection to be selectively made and/or torn down between the example local computer system 102 and the example remote computer system 1 10.
- the example network 1 16 may be implemented using any type of public or private network such as, but not limited to, the Internet, a telephone network, a local area network (LAN), a cable network, and/or a wireless network.
- LAN local area network
- cable network and/or a wireless network.
- each of the example local computer system 102 and the example remote computer system 1 10 of FIG. 1 includes a communication interface that enables connection to the network via Ethernet, a digital subscriber line (DSL), a telephone line, a coaxial cable and/or a wireless connection, etc.
- the example local computer system 1 02 of FIG. 1 includes a debugger 104 and software code 106A.
- the example remote computer system 1 10 includes a data fetcher 1 12, a data storage 1 14 and software code 106B.
- the example software code 106A on the example local computer system 102 is initially similar to (e.g., identical to) the example software code 106B on the example remote computer system 1 10.
- the example software code 106A on the example local computer system 102 and/or the example software code 106B on the example remote computer system 1 10 include marked sections 108.
- the marked sections 108 identify variables, objects and/or other data elements that are to be copied from the example remote computer system 1 10 to the example local computer system 102 prior to debugging the example software code 1 06A on the local computer system 102.
- the example debugger 104 of the example local computer system 102 is used to debug the example software code 106A resident on the local computer system 1 02.
- the example debugger 104 establishes a connection between the example local computer system 102 and the example remote computer system 1 1 0 via the example network 1 16.
- the example debugger 1 04 copies data from the remote computer system 1 10 to the local computer system 102 and stores the copied data.
- the example debugger 104 compiles and/or executes the example software code 106A on the example local computer system 102 using the data copied from the example remote computer system 1 1 0.
- the example debugger 1 04 detects and/or corrects errors in the example software code 106A on the example local computer system 102.
- the example software code 106B executes on the example remote computer system 1 10 during normal operation of the remote computer system 1 1 0.
- the software code 106B on the remote computer system 1 10 is identical to the software code 1 06A on the local computer system 102.
- the software code 1 06A, 106B is written in the JAVA programming language.
- the example software code 106A, 106B may be written in any other programming language that can be compiled and/or executed on the local computer system 102 and the remote computer system 1 10.
- the example software code 106A on the example local computer system 102 and/or the example software code 106B on the example remote computer system 1 10 contain marked sections 108.
- the marked sections 108 of the example software code 106A, 106B identify data elements, such as variables and/or other objects that are to be copied from the example remote computer system 1 10 to the example local computer system 102 when the software code 106A is to be debugged on the local computer system 1 02.
- the marked sections 1 08 may be identified in any desired fashion (e.g., manually, automatically, etc.).
- the marked sections 108 are identified using JAVA annotations.
- JAVA annotations are a feature of the JAVA programming language that allows metadata to be added to JAVA software code.
- JAVA annotations can be used to supply metadata to variables, methods, classes and/or other elements in JAVA code.
- Annotations are implemented in JAVA code using the '@' symbol followed immediately by an annotation type name, such as, for example @Override, @Deprecated or @SuppressWarnings.
- @Override, @Deprecated and @SuppressWarnings are three annotation types built into the JAVA language. An annotation type is followed in JAVA code by the element or elements to be annotated.
- custom user-defined annotations can also be used in JAVA code.
- JAVA annotations can be used for several purposes including providing documentation and providing information to the compiler among other possibilities.
- JAVA annotations are used to identify the example marked sections 108 of the example software code 106A, 106B to identify data elements in the software code 1 06A, 106B that are to be copied from the remote computer system 1 10 to the local computer system 102 to facilitate debugging.
- JAVA annotations added to the software code 1 06A, 106B indicate to a compiler that software instructions are to be inserted (i.e., injected) into the source code 106A at the positions of the annotations.
- the injected code sections indicate that values for identified data elements are to be loaded from the example data proxy 202 that contains the data snapshot transferred from the example remote computer system 1 10. Accordingly, when the compiled code 1 06A is executed on the example local computer system 102 during debugging, the previously injected code sections cause the execution to utilize the data in the example data proxy 202, which has been cloned from the relevant data on the remote computer system 1 1 0.
- the example software code 1 06A, 1 06B includes JAVA annotations to identify the marked sections 108
- any other method of identifying marked sections 108 in the example software code 106A, 106B could be additionally and/or alternatively utilized.
- the example software code 106A, 106B and the marked sections 108 may be implemented in any past, present and/or future programming language.
- the marked sections 108 of the example software code 1 06A, 106B allow for the values of the identified data elements to be copied from the example remote computer system 1 10 to the example local computer system 102 while the software code 1 06B is executing on the remote computer system 1 10.
- the values of the data elements identified in the marked sections 108 of the software code 106B might be made accessible from the data storage 1 14.
- the example marked sections 108 of the example software code 106A, 106B are marked during the software
- the marked sections 1 08 identify data elements of interest (e.g., key data elements) utilized by the example software code 1 06A, 106B.
- the marked sections 108 might identity data elements used by the example software code 106A, 1 06B that are only accessible by the example remote computer system 1 10 such as data from a database on the remote computer system 1 10. Identifying data elements of interest whose values are to be copied from the example remote computer system 1 10 to the example local computer system 102 prior to debugging allows the local computer system 102 to automatically obtain the data and to execute the example software code 106A to get the same or similar results that would be obtained by executing the example software code 106B on the remote computer system 1 10. The example software code 106A can then be debugged on the example local computer system 102 using the example debugger 104.
- the example data fetcher 1 12 on the example remote computer system 1 1 0 retrieves data elements to be copied from the example remote computer system 1 10 to the example local computer system 102 upon request by the example activator 200 of the example debugger 104.
- the data fetcher 1 12 retrieves data elements from the data storage 1 14.
- the example data fetcher 1 12 After retrieving the requested data elements, the example data fetcher 1 12 causes the retrieved data elements to be packaged and sent to the example local computer system via the example network 1 16. Alternatively, the data elements may be sent in any other manner.
- the example data storage 1 14 is a file or other data structure on the example remote computer system 1 10 that stores data elements to be copied from the remote computer system 1 10 to the example local computer system 102.
- the JAVA annotations in the marked sections 108 of the software code 106B specify that the values of data elements identified in the marked sections 108 that are to be stored in the data storage 1 14 while the software code 106B executes on the remote computer system 1 1 0.
- the values of data elements in the software code 106B, including the data elements identified in the marked sections 108 might change according to the instructions (e.g., data manipulations) in the software code 1 06B.
- the JAVA annotations cause the corresponding values in the example data storage 1 14 to be updated as well. Because the data elements are to be retrieved from the example data storage 1 14, the example data fetcher 1 12 retrieves data elements from the data storage 1 14 while the example software code 1 06B executes on the example remote computer system 1 1 0 without disturbing the execution of the software code 106B.
- the data storage 1 14 is the heap of the remote computer system 1 10, which is the area of memory on a computer system where data elements used by a JAVA application are stored.
- the data storage 1 14 could be another area of memory of the remote computer system 1 10 and/or a combination of one or more registers or other data storage structures on the remote computer system 1 1 0 where data elements to be transferred to the local computer system 102 are stored.
- data elements identified in the marked sections 108 of the software code 1 06B are copied from the data storage 1 14 to the local computer system 1 02 by the data fetcher 1 12.
- the software code 106A, 106B does not include marked sections 108.
- other methods of selecting data elements to be copied from the remote computer system 1 10 to the local computer system 102 are utilized such as manually inserting code into the software code 1 06A on the local computer system 102, manually selecting data elements to be copied from the remote computer system 1 10 to the local computer system 102, and so forth.
- FIG. 2 is a block diagram of an example implementation of the example debugger 1 04 of FIG. 1 .
- the example debugger 104 of FIG. 2 includes an activator 200, a data proxy 202, a compiler 204, and an executor 206.
- the example activator 200 of FIG. 2 initiates a data connection between the example local computer system 102 and the example remote computer system 1 10 and makes a request for the remote computer system 1 10 to transfer data (e.g., a data snapshot) to the local computer system 102.
- the data copied from the example remote computer system 1 10 to the example local computer system 102 includes values for data elements identified in the marked sections 108 of the example software code 106A.
- the activator 200 specifies which of the data elements identified in the marked sections 108 of the software code 106B are to be copied from the remote computer system 1 10 to the local computer system 102.
- the activator 200 may instruct the remote computer system 1 10 to copy every data element identified in the marked sections 108 of the software code 1 06B to the local computer system 102 after the activator 200 establishes a connection between the local computer system 102 and the remote computer system 1 10.
- the example activator 200 performs the above described actions while the example software code 106B executes on the example remote computer system 1 10 without interrupting the execution of the software 106B on the remote computer system 1 10.
- the example activator 200 closes the connection between the local computer system 102 and the remote computer system 1 10.
- updated data e.g., an updated data snapshot
- the example data proxy 202 of FIG. 2 is a file or other data structure that stores the data elements copied from the example remote computer system 1 10 to the example local computer system 102.
- the example software code 106B executes on the example remote computer system 1 10
- some of the data elements in the software code 106B are populated with values from sources available to the remote computer system 1 1 0, such as, for example a database on the remote computer system 1 1 0.
- the software code 1 06A may not have access to the resources available to the example remote computer 1 1 0 because the software code 1 06A only executes on the local computer system 102 after the connection to the remote computer system 1 1 0 is closed.
- the example debugger 104 populates the appropriate data elements identified in the marked sections 108 of the example software code 1 06A with values from the example data proxy 202 when the software code 1 06A executes on the example local computer system 102.
- the data in the example data proxy 202 on the example local computer system 102 acts as a proxy for data accessible by the example remote computer system 1 10.
- the example software code 106A executes on the local computer system 1 02 using the same data as the example software code 106B accesses on the remote computer system 1 1 0.
- the compiler 204 compiles the software code 106A on the local computer system 102 after the activator 200 closes the connection between the local computer system 102 and the remote computer system 1 10.
- the compiler 204 inserts software instructions into the software code 1 06A at the positions of the JAVA annotations in the software code 106A.
- the compiler 204 may not compile the software code 1 06A (e.g., where the software code 106A is precompiled and/or where the software code 106A is written in a programming language that does not need to be compiled to be executed, such as a scripting language).
- the compiler 204 is implemented through the commercially available software application EclipseTM or another integrated development environment (IDE).
- the executor 206 executes the software code 106A on the local computer system 102 after and/or while the compiler 204 compiles the software code 106A. In other examples, the executor 206 executes the software code 106A on the local computer system 102 after the activator 200 closes the connection with the remote computer system 1 10 (e.g., where the software code 106A does not need to be compiled to be executed). In some examples, the executor 206 is implemented through EclipseTM or another IDE.
- the example software code 106A completes execution on the example local computer system 102 or while the software code 1 06A is executing on the local computer system 102, bugs in the software code 106A can be identified and/or the software code 1 06A can be debugged.
- the debugger 1 04 provides tools to assist in the modification of the software code 1 06A to correct "bugs.”
- the debugged software code 106A is copied to the remote computer system in place of the software code 106B such that the software code 1 06A on the local computer system is identical to the software code 1 06B on the remote computer system 1 10.
- the modified data is stored on the local computer system 1 02, such as in a file or a database, so that it can later be retrieved.
- the executed software code 1 06A modifies the data in the data proxy 202 on the local computer system 102
- the modified data is stored to a mock object (e.g., NULL) and cannot be later retrieved.
- FIGS. 1 and 2 While an example manner of implementing the debugging system 100 has been illustrated in FIGS. 1 and 2, one or more of the elements, processes and/or devices illustrated in FIG. 1 and/or FIG. 2 may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other way. Further, the example debugger 104, the example data fetcher 1 12, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the example debugging system 100 of FIG. 1 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware.
- any of the example debugger 104, the example data fetcher 1 12, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the example debugging system 1 00 of FIG. 1 could be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), microprocessor(s), hardware processor(s), and/or field programmable logic device(s) (FPLD(s)), etc.
- the example debugger 104 When any of the system or apparatus claims of this patent are read to cover a purely software and/or firmware implementation, at least one of the example debugger 104, the example data fetcher 1 12, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the example debugging system 100 of FIG. 1 is hereby expressly defined to include a tangible computer readable storage medium such as a memory, DVD, CD, Blu-ray, etc. storing the software and/or firmware.
- example debugger 104 the example data fetcher 1 1 2, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the example debugging system 100 of FIG. 1 , and/or may include more than one of any or all of the illustrated elements, processes and devices.
- FIG. 3 illustrates an example JAVA annotation declaration 300 that may be part of the example software code 106A, 1 06B.
- the example JAVA annotation declaration 300 of FIG. 3 declares an annotation type named 'Marked.'
- Line 302 of the example of FIG. 3 uses the '@Retention' command to specify that the custom '@Marked' annotation is to be retained at run-time to allow marked elements to be accessed at run-time.
- Line 304 of the example of FIG. 3 uses the '@Target' command to specify that the custom '@Marked' annotation applies to methods.
- the '@interface' command uses the '@interface' command to name the custom annotation as 'Marked.' A definition of the '@Marked' annotation could specify, for example, that all elements annotated with the '@Marked' annotation are to be available to an external application while the JAVA code is executing.
- the '@Marked' annotation may then be utilized in the JAVA code to mark sections of data to be copied from the example remote computer system 1 10 to the example local computer system 102 for use in debugging.
- the values of the marked sections 108 available to an external application and/or computer system at run-time, the values of the marked sections during run-time can be copied to the example local computer system 102 while the example software code 106B executes on the example remote computer system 1 10.
- FIGS. 4 and/or 5 are flowcharts representative of example machine readable instructions for implementing the example debugging system 100 of FIG. 1 and/or FIG. 2.
- the machine readable instructions comprise program(s) for execution by a processor such as the processor 612 shown in the example computer 600 discussed below in connection with FIG. 6.
- the program(s) may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 612, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 61 2 and/or embodied in firmware or dedicated hardware.
- a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 612
- DVD digital versatile disk
- Blu-ray disk a memory associated with the processor 612
- the entire program and/or parts thereof could alternatively be executed by a device other than the processor 61 2 and/or embodied in firmware or dedicated hardware.
- FIGS. 4 and/or 5 many other methods of implementing the example debugging system 100 of FIG. 1 may alternatively be used.
- FIGS. 4 and/or 5 may be implemented using coded instructions (e.g., computer readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information).
- coded instructions e.g., computer readable instructions
- a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information
- FIGS. 4 and/or 5 may be implemented using coded instructions (e.g., computer readable instructions) stored on a non-transitory computer readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information).
- a non-transitory computer readable storage medium is expressly defined to include any type of computer readable storage device and/or disk and to exclude propagating signals.
- the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term
- FIG. 4 begins when the example local computer system 102 initiates debugging by acquiring data elements from the example remote computer system 1 10 (block 402).
- the data proxy 202 of the debugger 1 04 acquires data elements of interest (e.g., marked data elements) from the remote computer system 1 10 (block 402).
- the example local computer system 102 e.g., the executor 206) then executes the example software code 1 06A after closing the connection between the local computer system 102 and the example remote computer system 108 (block 404).
- the example local computer system 102 e.g., the debugger 104) then debugs the software code (block 406) and the example process of FIG. 4 ends.
- FIG. 5 is a more detailed flowchart representative of example machine readable instructions for implementing the example debugging system 100 of FIG. 1 and/or FIG. 2.
- FIG. 5 begins when the example activator 200 initiates debugging by establishing a connection between the example local computer system 1 02 and the example remote computer system 1 10 via the example network 1 1 6 (block 502).
- the example activator 200 requests that data elements identified within the marked sections 108 of the example software code 1 06B be copied from the example remote computer system 1 10 to the example local computer system 102 (block 504).
- the example data fetcher 1 12 retrieves a data snapshot of the requested data elements from the example data storage 1 14 (block 506).
- the retrieved data snapshot is then copied to the example data proxy 202 on the example local computer system 102 (block 508).
- the example activator 200 terminates the connection between the example local computer system 102 and the example remote computer system 1 1 0 (block 51 0).
- the example debugger 104 loads the values of the data elements in the example data proxy 202 into the appropriate data elements of the example software code 106A (block 512).
- the example software code 1 06A on the example local computer system 102 is then executed using the data loaded from the example data proxy 202 (block 514).
- the software code 106B on the remote computer system 1 10 continues to execute throughout this process.
- the execution of the example software code 106A on the example local computer system 1 02 will produce the same results as the execution of the example software code 1 06B on the remote computer system 1 10.
- the execution and debugging of the example software code 106A on the local computer system 102 does not consume the resources of the remote computer system 1 10.
- the software code 106A is debugged (block 516).
- the debugger 1 04 provides tools to assist with debugging of the software code 1 06A.
- the example software code 106A is debugged entirely on the example local computer system 102 and no data connection to the example remote computer system 1 10 is maintained while the software code 106A is debugged.
- the example debugging system 100 determines whether a request is made to retrieve new, additional and/or updated data from the example remote computer system 1 10 (block 518). If such a request is made, then control passes back to block 502 and a new connection is established between the example local computer system 102 and the example remote computer system 1 10. If such a request is not made, the example process of FIG. 5 ends.
- FIG. 6 is a block diagram of a processor platform 600 capable of executing the instructions of FIGS. 4 and/or 5 to implement the example debugging system 1 00 of FIG. 1 .
- the processor platform 600 can be, for example, a server, a personal computer, an Internet appliance, a DVD player, a CD player, a Blu-ray player, a gaming console, a personal video recorder, a smart phone, a tablet, a printer, or any other type of computing device.
- the processor platform 600 of the instant example includes a processor 61 2.
- processor refers to a logic circuit capable of executing machine readable instructions.
- the processor 612 can be implemented by one or more microprocessors or controllers from any desired family or manufacturer.
- the processor 612 includes a local memory 613 (e.g., a cache) and is in communication with a main memory including a volatile memory 614 and a nonvolatile memory 616 via a bus 61 8.
- the volatile memory 614 may be
- the non-volatile memory 616 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 614, 616 is controlled by a memory controller.
- the processor 612 of the illustrated example provides commands to the debugger 104 of FIGS. 1 and 2 to implement the debugger.
- the processor platform 600 also includes an interface circuit 620.
- the interface circuit 620 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.
- One or more input devices 622 are connected to the interface circuit 620.
- the input device(s) 622 permit a user to enter data and commands into the processor 61 2.
- the input device(s) can be implemented by, for example, a keyboard, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.
- One or more output devices 624 are also connected to the interface circuit 620.
- the output devices 624 can be implemented, for example, by display devices (e.g., a liquid crystal display, a cathode ray tube display (CRT), a printer and/or speakers).
- the interface circuit 620 thus, typically includes a graphics driver card.
- the interface circuit 620 also includes a communication device such as a modem or network interface card to facilitate exchange of data with external computers via a network 626 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.).
- a network 626 e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.
- the network 626 may be used to implement the example network 1 1 6 of FIG. 1 .
- the processor platform 600 also includes one or more mass storage devices 628 for storing software and data.
- mass storage devices 628 include floppy disk drives, hard drive disks, compact disk drives and digital versatile disk (DVD) drives.
- the coded instructions 632 of FIG. 6 may be stored in the mass storage device 528, in the volatile memory 514, in the non-volatile memory 616, and/or on a removable storage medium such as a CD or DVD. In the illustrated example, the coded instructions 632 may be used to implement the example software code 1 06A of FIG. 1 .
Abstract
Methods and apparatus for debugging of remote systems are disclosed. An example apparatus includes an activator to establish a connection between a first computer system and a second computer system, a data fetcher to transfer values of a first set of data elements from the second computer system to the first computer system via the connection, an executor to execute a first software code on the first computer system using the transferred values of the first set of data elements after the connection is closed, and a debugger to debug the first software code on the first computer system after the executor executes the first software code on the first computer system.
Description
METHODS AND APPARATUS FOR DEBUGGING OF REMOTE SYSTEMS
BACKGROUND
[0001] When software code is written, updated, and maintained, it may need to be debugged in order to ensure proper functionality. Software source code often contains errors or "bugs" that cause the software code to not function properly or as expected when it is compiled and/or executed. In order for the software code to function properly, these bugs may be identified and/or corrected by a programmer through the process of debugging. Debugging can be assisted by the use of a debugger. A debugger is a software application that a programmer may use to debug software code. A debugger typically contains tools to assist a programmer in the debugging process, such as allowing the software code to be executed one line at a time, allowing the programmer to examine the contents of certain data structures associated with the software code, and so forth.
BRIEF DESCRIPTION OF THE DRAWINGS
[0002] FIG. 1 is a block diagram of an example debugging system constructed in accordance with the teachings of this disclosure.
[0003] FIG. 2 is a block diagram of an example implementation of the example debugger of FIG. 1 .
[0004] FIG. 3 is JAVA code representative of an annotation declaration for use in the example debugging system of FIG. 1 .
[0005] FIGS. 4 and 5 are flowcharts representative of example machine readable instructions that may be executed to implement the example debugging system of FIG. 1 .
[0006] FIG. 6 is a block diagram of an example processing system capable of executing the example machine readable instructions of FIGS. 4 and 5 to implement the example debugging system of FIG 1 .
DETAILED DESCRIPTION
[0007] Often, software debugging is performed by a programmer who is physically present at the computer system that contains the software code to be debugged. However, it is sometimes not possible, not practical and/or not convenient for the programmer to be physically present at the computer system that contains the software code to be debugged. In these situations, a programmer may be present at one computer system (i.e., a local computer system), which is connected via a network to another computer system (i.e., a remote computer system) at a different location that contains the software code that is to be debugged. Using known networking software, the programmer can operate the remote computer system from the local computer system. This allows the programmer to debug the software code on the remote computer system using a debugger on the remote computer system while being physically present at the local computer system.
[0008] Software code on the remote computer system can be remotely debugged by a programmer who is physically present at the local computer system by establishing a network connection between the local computer system and the remote computer system. However, maintaining a network connection between the local computer system and the remote computer system while the software code is being debugged may consume significant resources on the remote computer system. This resource usage can potentially prevent the remote computer system from running other applications or processes.
[0009] As an alternative, software code can be debugged entirely on a local computer system, wherein software code on the local computer system is the same as the software code on the remote computer system at the time when a
programmer starts debugging. After debugging on the local computer system is complete, any changes made to the software code on the local computer system can be made to the software code on the remote computer system. This approach of debugging software entirely on the local computer system may not maintain an open connection between the local computer system and the remote computer system while debugging. However, this approach does not perform debugging using the data on the remote computer system.
[0010] When software code is executed, it typically manipulates some amount of data. For example, software code might access data from a database, create several variables or other data objects to use while the software code is executing and add, delete or modify data from the database. As such, when the software code is executing it operates on data that may vary during and/or as a result of execution of the software code. Software code often responds differently when operating on different data. For example, certain bugs in software code might only appear when the software code is operating on certain data. Therefore, in order to effectively debug software code on a remote computer system from a local computer system, examples disclosed herein provide the local computer system with access to data on the remote computer system. In some examples, the data connection between the local computer system and the remote computer system is not maintained throughout the debugging to reduce the resource load on the remote computer system.
[0011] Example methods, apparatus, and/or articles of manufacture disclosed herein provide a mechanism for offline debugging of a remote computer system As used herein, the term offline is expressly defined to mean a state in which a data connection utilized for retrieving data for the debugging from a remote computer system is closed such that there can be no further communication on the data connection without taking an action to establish the data connection. In particular, examples disclosed herein allow for debugging of software code on a remote computer system from a local computer system, using data from the remote computer system without maintaining an open connection between the local computer system and the remote computer system. As described in greater detail below, certain (e.g., key) sections of the software code are
marked to indicate that those sections contain data elements that will likely be of interest (e.g., important) for debugging. This marked software code is present on both the local computer system and the remote computer system.
[0012] In examples disclosed herein, the example software code to be debugged resides on both the example local computer system and the example remote computer system. During normal operation, the example software code executes on the example remote computer system. When the example software code is to be debugged, in examples disclosed herein the example local computer system establishes a connection to the example remote computer system and requests marked data. The example remote computer system then copies a data snapshot including the requested data to the example local computer system. In examples disclosed herein, after the requested data is transferred from the example remote computer system to the example local computer system, the connection between the local computer system and the remote computer system is closed. The example software code is then executed on the example local computer system using the data copied from the example remote computer system while the connection remains closed, thereby reducing the usage of network resources. In examples disclosed herein, after the example software code completes execution on the example local computer system and/or while the software code is executing on the local computer system, the software code is debugged on the local computer system using a debugger.
[0013] Because an open connection is not maintained between the example local computer system and the example remote computer system during the full duration of the debugging process (e.g., the open connection is only maintained during the time it takes to copy a data snapshot from the remote computer system to the local computer system), the use of the remote computer system's resources is reduced (e.g., minimized). Moreover, by executing the example software code on the example local computer system using the same data that is present on the example remote computer system, the software code executes on the local computer system in the same manner that the software code executes on the remote computer system. Accordingly, any bugs that would be
present upon execution of the example software code on the example remote computer system will also be present upon execution of the software code on the example local computer system. As such, the example software code can be debugged on the example local computer system just as if the software code were being debugged on the example remote computer system.
[0014] In some examples disclosed herein, if updated data from the example remote computer system is needed while the example software is being debugged on the example local computer system, the local computer system establishes a new connection to the remote computer system to receive the updated data (e.g., a new data snapshot) from the remote computer system. After debugging of the example software code on the example local computer system is complete, in some disclosed examples a copy of the debugged software code is transferred to the example remote computer system so that the remote computer system has the same debugged software code as the local computer system.
[0015] FIG. 1 is a block diagram of an example debugging system 100 constructed in accordance with the teachings of this disclosure. The example system 1 00 of FIG. 1 includes a local computer system 102 and a remote computer system 1 10. In the illustrated example, the local computer system 102 is able to communicate with the remote computer system 1 1 0 and vice versa via a network 1 1 6. The example network 1 1 6 allows a connection to be selectively made and/or torn down between the example local computer system 102 and the example remote computer system 1 10. The example network 1 16 may be implemented using any type of public or private network such as, but not limited to, the Internet, a telephone network, a local area network (LAN), a cable network, and/or a wireless network. To enable communication via the example network 1 1 6, each of the example local computer system 102 and the example remote computer system 1 10 of FIG. 1 includes a communication interface that enables connection to the network via Ethernet, a digital subscriber line (DSL), a telephone line, a coaxial cable and/or a wireless connection, etc.
[0016] The example local computer system 1 02 of FIG. 1 includes a debugger 104 and software code 106A. The example remote computer system 1 10 includes a data fetcher 1 12, a data storage 1 14 and software code 106B. The example software code 106A on the example local computer system 102 is initially similar to (e.g., identical to) the example software code 106B on the example remote computer system 1 10. The example software code 106A on the example local computer system 102 and/or the example software code 106B on the example remote computer system 1 10 include marked sections 108. The marked sections 108 identify variables, objects and/or other data elements that are to be copied from the example remote computer system 1 10 to the example local computer system 102 prior to debugging the example software code 1 06A on the local computer system 102.
[0017] The example debugger 104 of the example local computer system 102 is used to debug the example software code 106A resident on the local computer system 1 02. The example debugger 104 establishes a connection between the example local computer system 102 and the example remote computer system 1 1 0 via the example network 1 16. The example debugger 1 04 copies data from the remote computer system 1 10 to the local computer system 102 and stores the copied data. The example debugger 104 compiles and/or executes the example software code 106A on the example local computer system 102 using the data copied from the example remote computer system 1 1 0. The example debugger 1 04 detects and/or corrects errors in the example software code 106A on the example local computer system 102.
[0018] The example software code 106B executes on the example remote computer system 1 10 during normal operation of the remote computer system 1 1 0. In some examples, the software code 106B on the remote computer system 1 10 is identical to the software code 1 06A on the local computer system 102. In the illustrated example, the software code 1 06A, 106B is written in the JAVA programming language. Alternatively, the example software code 106A, 106B may be written in any other programming language that can be compiled and/or executed on the local computer system 102 and the remote computer system 1 10.
[0019] As mentioned above, the example software code 106A on the example local computer system 102 and/or the example software code 106B on the example remote computer system 1 10 contain marked sections 108. The marked sections 108 of the example software code 106A, 106B identify data elements, such as variables and/or other objects that are to be copied from the example remote computer system 1 10 to the example local computer system 102 when the software code 106A is to be debugged on the local computer system 1 02. The marked sections 1 08 may be identified in any desired fashion (e.g., manually, automatically, etc.).
[0020] In the illustrated example, the marked sections 108 are identified using JAVA annotations. JAVA annotations are a feature of the JAVA programming language that allows metadata to be added to JAVA software code. JAVA annotations can be used to supply metadata to variables, methods, classes and/or other elements in JAVA code. Annotations are implemented in JAVA code using the '@' symbol followed immediately by an annotation type name, such as, for example @Override, @Deprecated or @SuppressWarnings.
@Override, @Deprecated and @SuppressWarnings are three annotation types built into the JAVA language. An annotation type is followed in JAVA code by the element or elements to be annotated.
[0021] In addition to the built-in annotation types, custom user-defined annotations can also be used in JAVA code. JAVA annotations can be used for several purposes including providing documentation and providing information to the compiler among other possibilities. In the illustrated example, JAVA annotations are used to identify the example marked sections 108 of the example software code 106A, 106B to identify data elements in the software code 1 06A, 106B that are to be copied from the remote computer system 1 10 to the local computer system 102 to facilitate debugging.
[0022] In some examples, JAVA annotations added to the software code 1 06A, 106B indicate to a compiler that software instructions are to be inserted (i.e., injected) into the source code 106A at the positions of the annotations. The injected code sections indicate that values for identified data elements are to be loaded from the example data proxy 202 that contains the data snapshot
transferred from the example remote computer system 1 10. Accordingly, when the compiled code 1 06A is executed on the example local computer system 102 during debugging, the previously injected code sections cause the execution to utilize the data in the example data proxy 202, which has been cloned from the relevant data on the remote computer system 1 1 0.
[0023] Although the example software code 1 06A, 1 06B includes JAVA annotations to identify the marked sections 108, any other method of identifying marked sections 108 in the example software code 106A, 106B could be additionally and/or alternatively utilized. Similarly, although the above examples are implemented in JAVA, the example software code 106A, 106B and the marked sections 108 may be implemented in any past, present and/or future programming language. The marked sections 108 of the example software code 1 06A, 106B allow for the values of the identified data elements to be copied from the example remote computer system 1 10 to the example local computer system 102 while the software code 1 06B is executing on the remote computer system 1 10. For example, the values of the data elements identified in the marked sections 108 of the software code 106B might be made accessible from the data storage 1 14. The example marked sections 108 of the example software code 106A, 106B are marked during the software
development process of the software code 106A, 106B.
[0024] In the illustrated example, the marked sections 1 08 identify data elements of interest (e.g., key data elements) utilized by the example software code 1 06A, 106B. For example, the marked sections 108 might identity data elements used by the example software code 106A, 1 06B that are only accessible by the example remote computer system 1 10 such as data from a database on the remote computer system 1 10. Identifying data elements of interest whose values are to be copied from the example remote computer system 1 10 to the example local computer system 102 prior to debugging allows the local computer system 102 to automatically obtain the data and to execute the example software code 106A to get the same or similar results that would be obtained by executing the example software code 106B on the remote computer
system 1 10. The example software code 106A can then be debugged on the example local computer system 102 using the example debugger 104.
[0025] The example data fetcher 1 12 on the example remote computer system 1 1 0 retrieves data elements to be copied from the example remote computer system 1 10 to the example local computer system 102 upon request by the example activator 200 of the example debugger 104. In the illustrated example of FIG. 1 , the data fetcher 1 12 retrieves data elements from the data storage 1 14. After retrieving the requested data elements, the example data fetcher 1 12 causes the retrieved data elements to be packaged and sent to the example local computer system via the example network 1 16. Alternatively, the data elements may be sent in any other manner.
[0026] The example data storage 1 14 is a file or other data structure on the example remote computer system 1 10 that stores data elements to be copied from the remote computer system 1 10 to the example local computer system 102. In the illustrated example, the JAVA annotations in the marked sections 108 of the software code 106B specify that the values of data elements identified in the marked sections 108 that are to be stored in the data storage 1 14 while the software code 106B executes on the remote computer system 1 1 0. During execution of the example software code 106B on the example remote computer system 1 10, the values of data elements in the software code 106B, including the data elements identified in the marked sections 108, might change according to the instructions (e.g., data manipulations) in the software code 1 06B. In the illustrated example, as the values of the data elements identified in the marked sections 108 of the example software code 106B change, the JAVA annotations cause the corresponding values in the example data storage 1 14 to be updated as well. Because the data elements are to be retrieved from the example data storage 1 14, the example data fetcher 1 12 retrieves data elements from the data storage 1 14 while the example software code 1 06B executes on the example remote computer system 1 1 0 without disturbing the execution of the software code 106B.
[0027] In some examples, the data storage 1 14 is the heap of the remote computer system 1 10, which is the area of memory on a computer system
where data elements used by a JAVA application are stored. In other examples, the data storage 1 14 could be another area of memory of the remote computer system 1 10 and/or a combination of one or more registers or other data storage structures on the remote computer system 1 1 0 where data elements to be transferred to the local computer system 102 are stored. In foregoing examples, data elements identified in the marked sections 108 of the software code 1 06B are copied from the data storage 1 14 to the local computer system 1 02 by the data fetcher 1 12.
[0028] In some examples, the software code 106A, 106B does not include marked sections 108. In these examples, other methods of selecting data elements to be copied from the remote computer system 1 10 to the local computer system 102 are utilized such as manually inserting code into the software code 1 06A on the local computer system 102, manually selecting data elements to be copied from the remote computer system 1 10 to the local computer system 102, and so forth.
[0029] FIG. 2 is a block diagram of an example implementation of the example debugger 1 04 of FIG. 1 . The example debugger 104 of FIG. 2 includes an activator 200, a data proxy 202, a compiler 204, and an executor 206.
[0030] The example activator 200 of FIG. 2 initiates a data connection between the example local computer system 102 and the example remote computer system 1 10 and makes a request for the remote computer system 1 10 to transfer data (e.g., a data snapshot) to the local computer system 102. The data copied from the example remote computer system 1 10 to the example local computer system 102 includes values for data elements identified in the marked sections 108 of the example software code 106A. In the illustrated example, the activator 200 specifies which of the data elements identified in the marked sections 108 of the software code 106B are to be copied from the remote computer system 1 10 to the local computer system 102. In other examples, the activator 200 may instruct the remote computer system 1 10 to copy every data element identified in the marked sections 108 of the software code 1 06B to the local computer system 102 after the activator 200 establishes
a connection between the local computer system 102 and the remote computer system 1 10.
[0031] The example activator 200 performs the above described actions while the example software code 106B executes on the example remote computer system 1 10 without interrupting the execution of the software 106B on the remote computer system 1 10. In response to completion of the transfer of the requested data from the example remote computer system 1 1 0 to the example local computer system 102, the example activator 200 closes the connection between the local computer system 102 and the remote computer system 1 10. At a later time, a new connection may be established by the example activator 200 and updated data (e.g., an updated data snapshot) may be transferred from the remote computer system 1 10 to the local computer system 102.
[0032] The example data proxy 202 of FIG. 2 is a file or other data structure that stores the data elements copied from the example remote computer system 1 10 to the example local computer system 102. When the example software code 106B executes on the example remote computer system 1 10, some of the data elements in the software code 106B are populated with values from sources available to the remote computer system 1 1 0, such as, for example a database on the remote computer system 1 1 0. However, when the example software code 1 06A executes on the example local computer system 102, the software code 1 06A may not have access to the resources available to the example remote computer 1 1 0 because the software code 1 06A only executes on the local computer system 102 after the connection to the remote computer system 1 1 0 is closed. Instead, the example debugger 104 populates the appropriate data elements identified in the marked sections 108 of the example software code 1 06A with values from the example data proxy 202 when the software code 1 06A executes on the example local computer system 102. The data in the example data proxy 202 on the example local computer system 102 acts as a proxy for data accessible by the example remote computer system 1 10.
Accordingly, the example software code 106A executes on the local computer system 1 02 using the same data as the example software code 106B accesses on the remote computer system 1 1 0.
[0033] In the illustrated example, the compiler 204 compiles the software code 106A on the local computer system 102 after the activator 200 closes the connection between the local computer system 102 and the remote computer system 1 10. In the illustrated example, during compilation, the compiler 204 inserts software instructions into the software code 1 06A at the positions of the JAVA annotations in the software code 106A. In some examples, the compiler 204 may not compile the software code 1 06A (e.g., where the software code 106A is precompiled and/or where the software code 106A is written in a programming language that does not need to be compiled to be executed, such as a scripting language). In some examples, the compiler 204 is implemented through the commercially available software application Eclipse™ or another integrated development environment (IDE).
[0034] In the illustrated example, the executor 206 executes the software code 106A on the local computer system 102 after and/or while the compiler 204 compiles the software code 106A. In other examples, the executor 206 executes the software code 106A on the local computer system 102 after the activator 200 closes the connection with the remote computer system 1 10 (e.g., where the software code 106A does not need to be compiled to be executed). In some examples, the executor 206 is implemented through Eclipse™ or another IDE.
[0035] After the example software code 106A completes execution on the example local computer system 102 or while the software code 1 06A is executing on the local computer system 102, bugs in the software code 106A can be identified and/or the software code 1 06A can be debugged. In some examples, the debugger 1 04 provides tools to assist in the modification of the software code 1 06A to correct "bugs." In some examples, after the software code 1 06A is debugged, the debugged software code 106A is copied to the remote computer system in place of the software code 106B such that the software code 1 06A on the local computer system is identical to the software code 1 06B on the remote computer system 1 10. In some examples, after the executed software code 106A modifies the data in the data proxy 202 on the local computer system 102, the modified data is stored on the local computer
system 1 02, such as in a file or a database, so that it can later be retrieved. In other examples, after the executed software code 1 06A modifies the data in the data proxy 202 on the local computer system 102, the modified data is stored to a mock object (e.g., NULL) and cannot be later retrieved.
[0036] While an example manner of implementing the debugging system 100 has been illustrated in FIGS. 1 and 2, one or more of the elements, processes and/or devices illustrated in FIG. 1 and/or FIG. 2 may be combined, divided, rearranged, omitted, eliminated and/or implemented in any other way. Further, the example debugger 104, the example data fetcher 1 12, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the example debugging system 100 of FIG. 1 may be implemented by hardware, software, firmware and/or any combination of hardware, software and/or firmware. Thus, for example, any of the example debugger 104, the example data fetcher 1 12, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the example debugging system 1 00 of FIG. 1 could be implemented by one or more circuit(s), programmable processor(s), application specific integrated circuit(s) (ASIC(s)), programmable logic device(s) (PLD(s)), microprocessor(s), hardware processor(s), and/or field programmable logic device(s) (FPLD(s)), etc. When any of the system or apparatus claims of this patent are read to cover a purely software and/or firmware implementation, at least one of the example debugger 104, the example data fetcher 1 12, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the example debugging system 100 of FIG. 1 is hereby expressly defined to include a tangible computer readable storage medium such as a memory, DVD, CD, Blu-ray, etc. storing the software and/or firmware. Further still, the example debugger 104, the example data fetcher 1 1 2, the example data storage 1 14, the example activator 200, the example data proxy 202, the example compiler 204, the example executor 206 and/or, more generally, the
example debugging system 100 of FIG. 1 , and/or may include more than one of any or all of the illustrated elements, processes and devices.
[0037] FIG. 3 illustrates an example JAVA annotation declaration 300 that may be part of the example software code 106A, 1 06B. The example JAVA annotation declaration 300 of FIG. 3 declares an annotation type named 'Marked.' Line 302 of the example of FIG. 3 uses the '@Retention' command to specify that the custom '@Marked' annotation is to be retained at run-time to allow marked elements to be accessed at run-time. Line 304 of the example of FIG. 3 uses the '@Target' command to specify that the custom '@Marked' annotation applies to methods. Line 306 of the example of FIG. 3 uses the '@interface' command to name the custom annotation as 'Marked.' A definition of the '@Marked' annotation could specify, for example, that all elements annotated with the '@Marked' annotation are to be available to an external application while the JAVA code is executing. The '@Marked' annotation may then be utilized in the JAVA code to mark sections of data to be copied from the example remote computer system 1 10 to the example local computer system 102 for use in debugging. By making the values of the marked sections 108 available to an external application and/or computer system at run-time, the values of the marked sections during run-time can be copied to the example local computer system 102 while the example software code 106B executes on the example remote computer system 1 10.
[0038] FIGS. 4 and/or 5 are flowcharts representative of example machine readable instructions for implementing the example debugging system 100 of FIG. 1 and/or FIG. 2. In the example flowcharts of FIGS. 4 and/or 5, the machine readable instructions comprise program(s) for execution by a processor such as the processor 612 shown in the example computer 600 discussed below in connection with FIG. 6. The program(s) may be embodied in software stored on a tangible computer readable storage medium such as a CD-ROM, a floppy disk, a hard drive, a digital versatile disk (DVD), a Blu-ray disk, or a memory associated with the processor 612, but the entire program and/or parts thereof could alternatively be executed by a device other than the processor 61 2 and/or embodied in firmware or dedicated hardware. Further,
although the example program(s) is described with reference to the flowcharts illustrated in FIGS. 4 and/or 5, many other methods of implementing the example debugging system 100 of FIG. 1 may alternatively be used. For example, the order of execution of the blocks may be changed, and/or some of the blocks described may be changed, eliminated, or combined.
[0039] As mentioned above, the example processes of FIGS. 4 and/or 5 may be implemented using coded instructions (e.g., computer readable instructions) stored on a tangible computer readable storage medium such as a hard disk drive, a flash memory, a read-only memory (ROM), a compact disk (CD), a digital versatile disk (DVD), a cache, a random-access memory (RAM) and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term tangible computer readable storage medium is expressly defined to include any type of computer readable storage device and/or disk and to exclude propagating signals. Additionally or alternatively, the example processes of FIGS. 4 and/or 5 may be implemented using coded instructions (e.g., computer readable instructions) stored on a non-transitory computer readable medium such as a hard disk drive, a flash memory, a read-only memory, a compact disk, a digital versatile disk, a cache, a random-access memory and/or any other storage media in which information is stored for any duration (e.g., for extended time periods, permanently, brief instances, for temporarily buffering, and/or for caching of the information). As used herein, the term non-transitory computer readable storage medium is expressly defined to include any type of computer readable storage device and/or disk and to exclude propagating signals. As used herein, when the phrase "at least" is used as the transition term in a preamble of a claim, it is open-ended in the same manner as the term
"comprising" is open ended. Thus, a claim using "at least" as the transition term in its preamble may include elements in addition to those expressly recited in the claim.
[0040] FIG. 4 begins when the example local computer system 102 initiates debugging by acquiring data elements from the example remote computer
system 1 10 (block 402). For example, the data proxy 202 of the debugger 1 04 acquires data elements of interest (e.g., marked data elements) from the remote computer system 1 10 (block 402). The example local computer system 102 (e.g., the executor 206) then executes the example software code 1 06A after closing the connection between the local computer system 102 and the example remote computer system 108 (block 404). The example local computer system 102 (e.g., the debugger 104) then debugs the software code (block 406) and the example process of FIG. 4 ends.
[0041] FIG. 5 is a more detailed flowchart representative of example machine readable instructions for implementing the example debugging system 100 of FIG. 1 and/or FIG. 2. FIG. 5 begins when the example activator 200 initiates debugging by establishing a connection between the example local computer system 1 02 and the example remote computer system 1 10 via the example network 1 1 6 (block 502). The example activator 200 then requests that data elements identified within the marked sections 108 of the example software code 1 06B be copied from the example remote computer system 1 10 to the example local computer system 102 (block 504). After the example remote computer system 1 10 receives this request from the example activator 200, the example data fetcher 1 12 retrieves a data snapshot of the requested data elements from the example data storage 1 14 (block 506). The retrieved data snapshot is then copied to the example data proxy 202 on the example local computer system 102 (block 508). In response to receiving the data snapshot at the example data proxy 202 on the example local computer system 102, the example activator 200 terminates the connection between the example local computer system 102 and the example remote computer system 1 1 0 (block 51 0).
[0042] Once the example data proxy 202 receives a copy of the data snapshot from the example remote computer system 1 10 and the connection to the remote computer system 1 10 is closed, the example debugger 104 loads the values of the data elements in the example data proxy 202 into the appropriate data elements of the example software code 106A (block 512). The example software code 1 06A on the example local computer system 102 is then
executed using the data loaded from the example data proxy 202 (block 514). In some examples, the software code 106B on the remote computer system 1 10 continues to execute throughout this process. Because the data in the example data proxy 202 was copied from the example remote computer system 1 10, the execution of the example software code 106A on the example local computer system 1 02 will produce the same results as the execution of the example software code 1 06B on the remote computer system 1 10. By closing the connection to the example remote computer system 1 10, the execution and debugging of the example software code 106A on the local computer system 102 does not consume the resources of the remote computer system 1 10.
[0043] After the example software code 106A completes execution on the example local computer system 102 and/or while the software code 106A is executing, the software code 106A is debugged (block 516). In some examples, the debugger 1 04 provides tools to assist with debugging of the software code 1 06A. The example software code 106A is debugged entirely on the example local computer system 102 and no data connection to the example remote computer system 1 10 is maintained while the software code 106A is debugged. The example debugging system 100 then determines whether a request is made to retrieve new, additional and/or updated data from the example remote computer system 1 10 (block 518). If such a request is made, then control passes back to block 502 and a new connection is established between the example local computer system 102 and the example remote computer system 1 10. If such a request is not made, the example process of FIG. 5 ends.
[0044] FIG. 6 is a block diagram of a processor platform 600 capable of executing the instructions of FIGS. 4 and/or 5 to implement the example debugging system 1 00 of FIG. 1 . The processor platform 600 can be, for example, a server, a personal computer, an Internet appliance, a DVD player, a CD player, a Blu-ray player, a gaming console, a personal video recorder, a smart phone, a tablet, a printer, or any other type of computing device.
[0045] The processor platform 600 of the instant example includes a processor 61 2. As used herein, the term "processor" refers to a logic circuit capable of
executing machine readable instructions. For example, the processor 612 can be implemented by one or more microprocessors or controllers from any desired family or manufacturer.
[0046] The processor 612 includes a local memory 613 (e.g., a cache) and is in communication with a main memory including a volatile memory 614 and a nonvolatile memory 616 via a bus 61 8. The volatile memory 614 may be
implemented by Synchronous Dynamic Random Access Memory (SDRAM), Dynamic Random Access Memory (DRAM), RAMBUS Dynamic Random Access Memory (RDRAM) and/or any other type of random access memory device. The non-volatile memory 616 may be implemented by flash memory and/or any other desired type of memory device. Access to the main memory 614, 616 is controlled by a memory controller. The processor 612 of the illustrated example provides commands to the debugger 104 of FIGS. 1 and 2 to implement the debugger.
[0047] The processor platform 600 also includes an interface circuit 620. The interface circuit 620 may be implemented by any type of interface standard, such as an Ethernet interface, a universal serial bus (USB), and/or a PCI express interface.
[0048] One or more input devices 622 are connected to the interface circuit 620. The input device(s) 622 permit a user to enter data and commands into the processor 61 2. The input device(s) can be implemented by, for example, a keyboard, a mouse, a touchscreen, a track-pad, a trackball, isopoint and/or a voice recognition system.
[0049] One or more output devices 624 are also connected to the interface circuit 620. The output devices 624 can be implemented, for example, by display devices (e.g., a liquid crystal display, a cathode ray tube display (CRT), a printer and/or speakers). The interface circuit 620, thus, typically includes a graphics driver card.
[0050] The interface circuit 620 also includes a communication device such as a modem or network interface card to facilitate exchange of data with external computers via a network 626 (e.g., an Ethernet connection, a digital subscriber line (DSL), a telephone line, coaxial cable, a cellular telephone system, etc.). In
the illustrated example, the network 626 may be used to implement the example network 1 1 6 of FIG. 1 .
[0051] The processor platform 600 also includes one or more mass storage devices 628 for storing software and data. Examples of such mass storage devices 628 include floppy disk drives, hard drive disks, compact disk drives and digital versatile disk (DVD) drives.
[0052] The coded instructions 632 of FIG. 6 may be stored in the mass storage device 528, in the volatile memory 514, in the non-volatile memory 616, and/or on a removable storage medium such as a CD or DVD. In the illustrated example, the coded instructions 632 may be used to implement the example software code 1 06A of FIG. 1 .
[0053] Although certain example apparatus, methods, and articles of manufacture have been disclosed herein, the scope of coverage of this patent is not limited thereto. On the contrary, this patent covers all apparatus, methods, and articles of manufacture fairly falling within the scope of the claims of this patent.
Claims
1 . An apparatus comprising:
an activator to establish a connection between a first computer system and a second computer system;
a data fetcher to transfer values of a first set of data elements from the second computer system to the first computer system via the connection;
an executor to execute a first software code on the first computer system using the transferred values of the first set of data elements after the connection is closed; and
a debugger to debug the first software code on the first computer system after the executor executes the first software code on the first computer system.
2. The apparatus of claim 1 , wherein the first software code contains the first set of data elements and the first set of data elements are marked in the first software code using code annotations.
3. The apparatus as defined in claim 1 , wherein the second computer system executes the first software code in response to the activator closing the connection between the first computer system and the second computer system.
4. The apparatus as defined in claim 1 , wherein after the debugger debugs the first software code, the activator re-establishes the connection and the data fetcher transfers updated values of the first set of data elements to the first computer system for debugging the first software code again.
5. The apparatus of claim 1 , wherein the first software code is written in the JAVA programming language.
6. A method comprising:
establishing a connection between a first computer system and a second computer system, wherein the first computer system and the second computer system contain a first software code and wherein the first software code contains a first set of data elements;
acquiring the values of the first set of data elements from the second computer system via the connection;
executing the first software code on the first computer system using the values of the first set of data elements after the connection between the first computer system and the second computer system is closed; and
debugging the first software code on the first computer system after executing the first software code on the first computer system.
7. The method of claim 6, wherein the debugging is performed offline.
8. The method of claim 6, further comprising executing the software code on the second computer system in response to closing the connection between the first computer system and the second computer system.
9. The method of claim 6, further comprising copying the debugged software code from the first computer system to the second computer system.
10. The method of claim 6, further comprising, after debugging the first software code, re-establishing the connection to acquire updated values of the first set of data elements from the second computer system to debug the first software code again.
1 1 . A tangible machine readable storage medium comprising instructions that, when executed, cause a first computer system to at least:
acquire values of a first set of data elements from a second computer system;
execute a first software code on the first computer system using the values of the first set of data elements in response to a closing of a connection between the first computer system and the second computer system; and
debug the first software on the first computer system after executing the first software code on the first computer system.
12. A storage medium as defined in claim 1 1 , wherein the first set of data elements are marked using JAVA annotations.
13. A storage medium as defined in claim 1 1 , wherein the instructions, when executed, cause the first computer system to copy the debugged software code from the first computer system to the second computer system.
14. A storage medium as defined in claim 1 1 , wherein the instructions, when executed, cause the first computer system to acquire updated values of the first set of data elements from the second computer system for use in debugging the first software code again.
15. A storage medium as defined in claim 1 1 , wherein the first software code is written in the JAVA programming language.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US14/765,321 US9720803B2 (en) | 2013-01-31 | 2013-01-31 | Methods and apparatus for debugging of remote systems |
CN201380072013.3A CN104937560B (en) | 2013-01-31 | 2013-01-31 | Method and apparatus for remote system debugging |
EP13873828.1A EP2951698A4 (en) | 2013-01-31 | 2013-01-31 | Methods and apparatus for debugging of remote systems |
PCT/US2013/024116 WO2014120200A1 (en) | 2013-01-31 | 2013-01-31 | Methods and apparatus for debugging of remote systems |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2013/024116 WO2014120200A1 (en) | 2013-01-31 | 2013-01-31 | Methods and apparatus for debugging of remote systems |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2014120200A1 true WO2014120200A1 (en) | 2014-08-07 |
Family
ID=51262764
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2013/024116 WO2014120200A1 (en) | 2013-01-31 | 2013-01-31 | Methods and apparatus for debugging of remote systems |
Country Status (4)
Country | Link |
---|---|
US (1) | US9720803B2 (en) |
EP (1) | EP2951698A4 (en) |
CN (1) | CN104937560B (en) |
WO (1) | WO2014120200A1 (en) |
Families Citing this family (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US10318403B2 (en) * | 2016-05-17 | 2019-06-11 | International Business Machines Corporation | Code update based on detection of change in runtime code during debugging |
US10162730B2 (en) | 2017-01-24 | 2018-12-25 | Dell Products, L.P. | System and method for debugging software in an information handling system |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
EP1408410A1 (en) | 2002-09-30 | 2004-04-14 | Sap Ag | Remote debugging of computer programs |
US20070174715A1 (en) * | 2004-01-21 | 2007-07-26 | Sap Ag | Remote debugging |
US7673180B1 (en) * | 2005-05-05 | 2010-03-02 | Sun Microsystems, Inc. | Method and apparatus for dispatching a remote debugging agent in a distributed computing environment |
WO2011016595A1 (en) * | 2009-08-03 | 2011-02-10 | 강원대학교 산학협력단 | Web-based software debugging apparatus for remote debugging and method thereof |
US20110088015A1 (en) * | 2001-07-10 | 2011-04-14 | Ryan Shillington | System and method for remotely debugging application programs |
Family Cites Families (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5630049A (en) * | 1994-11-30 | 1997-05-13 | Digital Equipment Corporation | Method and apparatus for testing software on a computer network |
US5892941A (en) * | 1997-04-29 | 1999-04-06 | Microsoft Corporation | Multiple user software debugging system |
WO2002023344A2 (en) * | 2000-09-15 | 2002-03-21 | Wind River Systems, Inc. | System and method for communicating software debug, diagnostic and maintenance information between devices |
US7543277B1 (en) | 2003-06-27 | 2009-06-02 | American Megatrends, Inc. | Method and system for remote software debugging |
US20050216895A1 (en) | 2004-03-23 | 2005-09-29 | Tran Hieu T | Method and apparatus for remote debugging of kernel and application software |
US20060174225A1 (en) | 2005-02-01 | 2006-08-03 | International Business Machines Corporation | Debugging a High Level Language Program Operating Through a Runtime Engine |
GB0513185D0 (en) * | 2005-06-30 | 2005-08-03 | Ibm | A method system and software tool for emulating a portal application |
US7783799B1 (en) * | 2006-08-31 | 2010-08-24 | American Megatrends, Inc. | Remotely controllable switch and testing methods using same |
US8015201B1 (en) | 2007-02-22 | 2011-09-06 | Netapp, Inc. | Servicing daemon for live debugging of storage systems |
US8239839B2 (en) | 2007-12-21 | 2012-08-07 | Sap Ag | Asynchrony debugging using web services interface |
US8589887B2 (en) * | 2010-10-20 | 2013-11-19 | International Business Machines Corporation | Registration-based remote debug watch and modify |
US8621118B1 (en) * | 2010-10-20 | 2013-12-31 | Netapp, Inc. | Use of service processor to retrieve hardware information |
US9292395B2 (en) * | 2010-12-07 | 2016-03-22 | Nec Corporation | Debug stub server, debug method, and program |
-
2013
- 2013-01-31 US US14/765,321 patent/US9720803B2/en active Active
- 2013-01-31 CN CN201380072013.3A patent/CN104937560B/en active Active
- 2013-01-31 WO PCT/US2013/024116 patent/WO2014120200A1/en active Application Filing
- 2013-01-31 EP EP13873828.1A patent/EP2951698A4/en not_active Withdrawn
Patent Citations (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20110088015A1 (en) * | 2001-07-10 | 2011-04-14 | Ryan Shillington | System and method for remotely debugging application programs |
US20040123271A1 (en) * | 2002-09-26 | 2004-06-24 | Jutta Bindewald | Remote debugging through firewalls |
EP1408410A1 (en) | 2002-09-30 | 2004-04-14 | Sap Ag | Remote debugging of computer programs |
US20070174715A1 (en) * | 2004-01-21 | 2007-07-26 | Sap Ag | Remote debugging |
US7673180B1 (en) * | 2005-05-05 | 2010-03-02 | Sun Microsystems, Inc. | Method and apparatus for dispatching a remote debugging agent in a distributed computing environment |
WO2011016595A1 (en) * | 2009-08-03 | 2011-02-10 | 강원대학교 산학협력단 | Web-based software debugging apparatus for remote debugging and method thereof |
Non-Patent Citations (1)
Title |
---|
See also references of EP2951698A4 |
Also Published As
Publication number | Publication date |
---|---|
CN104937560B (en) | 2018-04-10 |
EP2951698A4 (en) | 2016-10-05 |
CN104937560A (en) | 2015-09-23 |
US9720803B2 (en) | 2017-08-01 |
US20150370686A1 (en) | 2015-12-24 |
EP2951698A1 (en) | 2015-12-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11853774B2 (en) | Dynamically loaded plugin architecture | |
US11467816B1 (en) | Method and system of running an application | |
US8978023B2 (en) | Canonical mechanism for securely assembling features into a mobile application | |
US9477450B2 (en) | Manual refinement of specialized classes in runtime environments | |
WO2018099292A1 (en) | Process management method and apparatus | |
US20080320282A1 (en) | Method And Systems For Providing Transaction Support For Executable Program Components | |
US20160232017A1 (en) | System and Method for Reloading Constructors | |
US20170078369A1 (en) | Event-responsive download of portions of streamed applications | |
WO2019005228A1 (en) | Automated source code adaption to inject features between platform versions | |
CN109670299A (en) | A kind of method and electronic equipment creating Python sandbox environment | |
US20130055217A1 (en) | Breakpoint synchronization for modified program source code | |
CN106909441B (en) | Disk direct I/O access method based on JVM | |
US7966600B2 (en) | Distributed resource understanding tool management | |
US9639375B2 (en) | Generation of language bindings for libraries using data from compiler generated debug information | |
WO2019047510A1 (en) | Ios platform dylib file hiding method, storage medium, electronic apparatus and system | |
WO2022127557A1 (en) | Code analysis method and related device | |
US20120311552A1 (en) | Runtime optimization of application bytecode via call transformations | |
US9720803B2 (en) | Methods and apparatus for debugging of remote systems | |
CN104679556B (en) | Application program method for burn-recording and system | |
CN111880804A (en) | Application program code processing method and device | |
US9417871B2 (en) | Automatic generation of certificate of origin (COO) for software systems | |
JP2009015428A (en) | Program update method, information processor, program, and recording medium | |
CN111949301B (en) | Application program hot update method, device and computer readable storage medium | |
JP2009524876A (en) | External setting of processing contents for script | |
Lawall et al. | Tarantula: Killing driver bugs before they hatch |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 13873828 Country of ref document: EP Kind code of ref document: A1 |
|
WWE | Wipo information: entry into national phase |
Ref document number: 2013873828 Country of ref document: EP |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
WWE | Wipo information: entry into national phase |
Ref document number: 14765321 Country of ref document: US |