WO2014120200A1 - Methods and apparatus for debugging of remote systems - Google Patents

Methods and apparatus for debugging of remote systems Download PDF

Info

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
Application number
PCT/US2013/024116
Other languages
French (fr)
Inventor
Nadav MARGALIT
Michael MISHALOV
Original Assignee
Hewlett-Packard Development Company, L.P.
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hewlett-Packard Development Company, L.P. filed Critical Hewlett-Packard Development Company, L.P.
Priority to US14/765,321 priority Critical patent/US9720803B2/en
Priority to CN201380072013.3A priority patent/CN104937560B/en
Priority to EP13873828.1A priority patent/EP2951698A4/en
Priority to PCT/US2013/024116 priority patent/WO2014120200A1/en
Publication of WO2014120200A1 publication Critical patent/WO2014120200A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • G06F11/3636Software debugging by tracing the execution of the program
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/362Software debugging
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/36Preventing errors by testing or debugging software
    • G06F11/3664Environments 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

What is claimed is:
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.
PCT/US2013/024116 2013-01-31 2013-01-31 Methods and apparatus for debugging of remote systems WO2014120200A1 (en)

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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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

Patent Citations (6)

* Cited by examiner, † Cited by third party
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)

* Cited by examiner, † Cited by third party
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