| Entries |
| Document | Title | Date |
|---|
| 20080209405 | DISTRIBUTED DEBUGGING FOR A VISUAL PROGRAMMING LANGUAGE - A system for distributed debugging of a visual programming language computer application. The system includes an execution environment such as a runtime environment to execute a visual programming language computer application. The system also includes a debugging engine to manipulate execution of the a visual programming language application being debugged. Both the execution environment and the debugging engine offer data and methods over a network connection such that either a networked or local debugger user interface may debug the visual programming language computer application. The debugger user interface may be instantiated on a world wide web browser using a received image file representing the visual programming language application, the debugging state, and presentation logic. More than one debugger user interface may interact with the debugging engine at one, allowing distributed debugging of the visual programming language application. | 08-28-2008 |
| 20080235668 | OPERATING SYSTEM SUPPORT FOR THREAD-LEVEL BREAKPOINTS - A computer implemented method, apparatus, and computer usable program code for processing breakpoints. A breakpoint is detected during execution of a process. A thread that is currently executing is identified as an identified thread. A determination is made as to whether the breakpoint is applicable to the identified thread. In response to the determination that the breakpoint is applicable to the identified thread, the execution of the process is halted. Execution of the process continues without halting execution of the process if the breakpoint is inapplicable to the identified thread. | 09-25-2008 |
| 20080244535 | Logging and Replaying Input/Output Events for a Virtual Machine - Methods for logging and replaying input/output (I/O) events for a virtual machine (VM). The I/O events may be asynchronous or synchronous. In particular, one embodiment is a computer-implemented method for logging input/output (I/O) events for a virtual machine, the method including: executing the virtual machine from a checkpoint; and logging external events, including I/O events; wherein logging an I/O event comprises logging the event, and then, logging I/O data relating to the I/O event. | 10-02-2008 |
| 20080250397 | System And Method For Implementing Software Breakpoints In An Interpreter - A method for implementing software breakpoints in a software program to be executed by a interpreter, comprising the steps of executing a look-up, in a main loop of the interpreter, the look-up function searching a list of breakpoint addresses to determine whether a breakpoint instruction is to be executed at the address referenced by the interpreter's current instruction pointer instead of the program instruction, and maintaining, in memory, the list of breakpoints addresses separately from the program code, such that the breakpoint list can be altered separately from the program code. | 10-09-2008 |
| 20080270996 | APPARATUS AND METHOD FOR AUTOMATICALLY EXTRACTING INTERFACE OF EMBEDDED SOFTWARE - Provided is an apparatus and method for automatically extracting an interface of embedded software. The method defines an interface of embedded software as a test item for test of the interface of the embedded software, and generates an interface symbol corresponding to the defined test item. The location of the interface symbol is determined, and a test case is generated based on the interface symbol and its location in the software. Embodiments of the invention thus facilitate the testing of software at interfaces between layers in the software. | 10-30-2008 |
| 20080276226 | DEVICE, METHOD AND COMPUTER PROGRAM PRODUCT FOR EVALUATING A DEBUGGER SCRIPT - A method for evaluating a debugger script, the method includes: (i) receiving a debugger script that includes a first debugger breakpoint that is associated with a certain program line number; and determining a validity of the first debugger breakpoint in response to a comparision between expected content associated with the first debugger breakpoint and between an actual content of at least a portion of a certain program line group that comprises a certain program line identified by the certain program line number. | 11-06-2008 |
| 20080282234 | DYNAMIC EMULATION MODE SWITCHING - In at least some embodiments, a computing system includes a processor and a debug module coupled to the processor. The debug module controls an emulation environment for debugging code, the emulation environment having a first mode that enables time-critical code to execute while non-time-critical code is halted and a second mode that halts execution of both time-critical code and non-time-critical code. The computing system also includes switch logic in communication with the processor and the debug module, wherein the switch logic enables dynamic switching between the first and second modes. | 11-13-2008 |
| 20080301648 | Model oriented debugging - A system and method for debugging a business application that has been generated according to a model are disclosed. A system includes a debugger that generates a model-oriented debugging view based on a model-oriented development environment that generates the business application. The model-oriented debugging view uses debugging information determined from a Java virtual machine that executes the business application to generate one or more breakpoints in the model-oriented debugging view. | 12-04-2008 |
| 20090013313 | DEBUG DEVICE, DEBUG METHOD, AND PROGRAM - The debug device of the present invention is a debug device which stops execution of a program based on one of a conditional break for stopping the program regardless of the condition of a predicated instruction and an unconditional break for stopping the program only when the condition of the predicated instruction is true. The debug device includes: a receiving unit which receives a breakpoint according to an operation by a user; a determination unit which determines the received break point as the unconditional break or the conditional break; and a stop unit operable to stop the program based on the unconditional break or the conditional break determined by the determination unit. | 01-08-2009 |
| 20090024985 | TASK CONTROL METHOD AND SEMICONDUCTOR INTEGRATED CIRCUIT - A task control method by which when a multiprocessor device having processors executes application software tasks, checkpoints have been buried in the application software tasks in advance. In course of execution of each application software task, the checkpoints are used to make an inquiry about passed one of the checkpoints in the task. Then, the progress of each task is judged based on the current passed checkpoint identified as a result of the inquiry and a passed budget corresponding to the passed checkpoint. Based on a result of the judgment, a resource shared by the tasks is controlled, and a new passed budget is set. Thus, the restriction on the scope of application of an application software program is reduced. | 01-22-2009 |
| 20090070747 | System for Adding Code Commentary to Source Code During Software Debugging - Software debugging having means for linking with source code commentary relating to the source code's execution is provided. An advantage is achieved by storing the code commentary received from a user during software debugging about a program's execution directly alongside the source code. | 03-12-2009 |
| 20090083716 | PROFILING METHOD AND PROGRAM - A profiling method for collecting, using a computer, information on an execution status of a target program. Information collection is performed for the target program using an interrupt handler that is initiated in response to an interrupt that occurs when a predetermined condition is satisfied. The profiling method includes specifying a target range in which information collection is to be performed using the interrupt handler, in the target program,; and setting information collected by the interrupt handler in a memory when the interrupt occurs in the target range. | 03-26-2009 |
| 20090119646 | Detection of a Fault by Long Disturbance - A method for detecting faults by perturbations during execution of a computerized code in an electronic device. The computer code includes a sensitive process. The method includes a step of executing a redundant procedure of the sensitive process and a step of inserting a delay between the sensitive process and the redundant procedure. A trapping procedure is executed during the delay. The trapping procedure is sensitive to perturbations and supplies, in the absence of perturbation, a predictable result. | 05-07-2009 |
| 20090119647 | DEVICE AND METHOD FOR INSPECTING SOFTWARE FOR VULNERABILITIES - Provided is a device and method for inspecting software for vulnerabilities which fuzzes the software by function. The device for inspecting software for vulnerabilities includes a target function selecting module for selecting a function of the software for vulnerabilities to be inspected, a comparison file generating module for generating a first file including the selected function and a second file not including the selected function, a binary pattern comparing module for detecting a changed or added binary pattern by comparing binary values of the first file and the second file, a test case generating module for generating at least one test case based on the detected binary pattern, and a vulnerability verifying module for inspecting vulnerabilities based on the at least one test case and generating a vulnerability inspection result. Accordingly, by intensively fuzzing a part of the software which is changed or added according to the function of the software, software vulnerabilities can be found by each function and fuzzing efficiency can be improved. | 05-07-2009 |
| 20090125888 | EXPRESSION-LEVEL DEBUGGING WITHOUT FORMAT CHANGES - A debugging tool pauses or stops the execution of a computer program midway through the evaluation of a single line of source code that contains multiple expressions. A debugging tool pauses or stops the execution of a computer program after evaluating and executing one or more expressions within a particular line of source code, but before evaluating and executing one or more other expressions within that same particular line of source code. Thus, programmers can use such a debugging tool to debug a computer program at a level of granularity that is finer than source code line-level. Programmers can use such a debugging tool to debug a computer program, using breakpoints and/or stepping, at an expression-level of granularity. | 05-14-2009 |
| 20090125889 | SYSTEM AND PROGRAM PRODUCT FOR EXECUTING PROGRAM TO THEREBY TEST THE PROGRAM - In a system for carrying out a program to be tested, an interrupt generator is provided; this program includes a plurality of routines designed to be called and executed in a predetermined order. The interrupt generator generates an interrupt request every time one of the plurality of routines is called. A determining unit is provided in the system. The determining unit determines whether a sequence of instructions in the program is normal based on historical information indicative of whether the interrupt request corresponding to at least one of the plurality of routines is generated. | 05-14-2009 |
| 20090125890 | BREAKPOINT MANAGEMENT AND RECONCILIATION FOR EMBEDDED SCRIPTS IN A BUSINESS INTEGRATION LANGUAGE SPECIFIED PROGRAM PROCESS - A method, system and apparatus for breakpoint management and reconciliation for business integration language specified programs. The system includes a business integration language development environment; debug tooling accessible through the environment; and, breakpoint management and reconciliation logic coupled to the debug tooling. The business integration language development environment includes a BPEL development environment cooperatively coupled to a BPEL engine. The debug tooling includes a script display for displaying textual portions of an embedded script; and, at least one other display selected from the group consisting of a graphical process flow display, a debug module display and a breakpoint module display. | 05-14-2009 |
| 20090138857 | DEVICE, SYSTEM, AND METHOD OF TESTING COMPUTER PROGRAMS - Device, system, and method of testing computer programs. For example, an apparatus for testing computer programs includes: a debugger to detect a breakpoint in a computer program, and to issue an event indicating one or more properties of the breakpoint; and an event processing engine to control the operation of the debugger based on event processing analysis that takes into account the event issued by the debugger. | 05-28-2009 |
| 20090150870 | Method, Apparatus, and Computer Program Product for Implementing Enhanced Template Debug - A template debug mechanism is provided for executing an operation on at least one breakpoint within a program that includes a template. In one embodiment, in response to a first selection, a breakpoint is set in all expansions of the template and a multiple breakpoints icon is displayed. Preferably, the user may request display of a breakpoint properties dialog box listing each of the template expansions in which the multiple breakpoints are set. In response to a second selection, a breakpoint is set in only the current expansion of the template that is active in the call stack, and a single breakpoint icon is displayed. In response to the third selection, any breakpoint set in any expansion of the template is removed. Preferably, the first, second and third selections are respectively made by the user with a first, second and third click of an input device. | 06-11-2009 |
| 20090158257 | Systems and Methods for Graphics Hardware Design Debugging and Verification - Disclosed are systems and methods for debugging and analyzing graphics hardware designs. Hardware designs are represented by a software model implemented in a programming language. Graphics operations can be executed in the software model as well as in reference software models to allow a user to analyze the accuracy of a graphics hardware design and/or a device driver implementation. | 06-18-2009 |
| 20090164981 | Template Based Asynchrony Debugging Configuration - A system and method for debugging a running process of an application or component are disclosed. A debugging agent runs one or more templates. Each template is configured with a breakpoint set defined in debugging code for stopping execution of the running process according to one or more breakpoints. One or more debugging clients each includes a user interface for defining at least one of the one or more templates. Each debugging client is selectable to receive debugging information of the running process based on the breakpoint set. | 06-25-2009 |
| 20090178030 | SYSTEM, METHOD AND PROGRAM FOR EXECUTING A DEBUGGER - A method for controlling a debugger, the method includes: determining whether to execute a certain breakpoint of the debugger in view of certain breakpoint conditional information and in view of at least one previous visit, during the execution of the debugger, to at least one other breakpoint of the debugger; and selectively executing the certain breakpoint in response to the determination. | 07-09-2009 |
| 20090254888 | DEBUG TOURS FOR SOFTWARE DEBUGGING - Embodiments of the present invention address deficiencies of the art in respect to source code debugging and provide a method, system and computer program product for debug tours for debugging source code. In an embodiment of the invention, a debugger data processing system can be provided. The system can include a debugger executing in a host computing platform, and a debug tour manager coupled to the debugger. The debug tour manager can include program code enabled to load a debug tour of an ordered set of breakpoints established during a prior debugging session of source code, to apply the breakpoints in the debug tour to separately loaded source code, and to execute the source code and to invoke the applied breakpoints in an order prescribed by the ordered set within the debugger. | 10-08-2009 |
| 20090313610 | Advisory warning and workaround indications to user when stopped between load and store conditional instructions while using source level debuggers - A load store advisory program sets a breakpoint within a portion of a program, determines if the breakpoint will cause unexpected behavior, and generates a warning if it is determined that the breakpoint will cause unexpected behavior. The unexpected behavior may be the result of setting a breakpoint within a load-store sequence that, because of the breakpoint, will repeatedly fail. | 12-17-2009 |
| 20090313611 | Dynamically Patching Computer Code Using Breakpoints - A first section of executable computer code of a computer program is dynamically patched by performing the following. A breakpoint is inserted at the first section of executable computer code. During execution of the computer program, an instruction counter is incremented on an instruction-by-instruction basis through the computer program. The instruction counter indicates a current instruction of the computer program being executed. The breakpoint where the instruction counter points to the first section of executable computer code is encountered, which results in a breakpoint handler being called. The breakpoint handler changes the instruction pointer to instead point to a second section of executable computer code. The second section of executable computer code is a patched version of the first section of executable computer code. Upon the breakpoint handler returning, the second section of executable computer code is executed in lieu of the first section of executable computer code. | 12-17-2009 |
| 20090320001 | SYSTEM, METHOD AND PROGRAM PRODUCT FOR MONITORING CHANGES TO DATA WITHIN A CRITICAL SECTION OF A THREADED PROGRAM - A method, system and program product for monitoring changes to a variable within a critical section of a threaded program. The method includes establishing, using a debugging tool, a watch for monitoring changes to a variable that occur outside of the critical section and executing a portion of the threaded program with a debugger. Further, the method includes determining, using the tool, whether or not a thread has executed a start breakpoint set for the critical section, if the thread has executed the start breakpoint set, determining whether or not the thread has executed an end breakpoint set for the critical section, and if the thread has not executed the end breakpoint set, displaying any watches triggered responsive to updates to the variable that occur outside of the critical section, such that, only updates to the variable that occur outside of the critical section will trigger the displaying. | 12-24-2009 |
| 20090328008 | DYNAMICALLY MONITORING APPLICATION BEHAVIOR - A dynamic verification system is described that enables application developers to safely include significant custom business logic in their applications. The dynamic verification system receives application behavior criteria that specify behavior of an application of interest to an application host. The system executes an application and instruments an application execution environment to detect application behavior that meets the application behavior criteria. The system determines when the application has performed an action that satisfies the application behavior criteria and provides a notification about the application behavior that occurred that a system administrator can use to take action against the application. | 12-31-2009 |
| 20100064283 | METHOD, COMPUTER PROGRAM PRODUCT, AND HARDWARE PRODUCT FOR HANDLING BREAKPOINTS IN AN ASYNCHRONOUS DEBUG MODEL - Breakpoints are handled in an asynchronous debug model by building a queue of basic operations to run a debug application program interface (API). User commands are each broken down into a simple command and placed on the queue. In response to a debug event, a new simple command is generated. If, when a first command on the queue is processed, a thread is not stopped at a location with an installed breakpoint, an operation corresponding to the first command is started, the operation is removed from the queue, and a next operation is started. If the thread is stopped at the location with the breakpoint, the thread performs a hop. When the hop terminates, the first command is removed from the queue. If the first command is a run command, and there is no cause to stop the thread, the run command is moved to the end of the queue. | 03-11-2010 |
| 20100077385 | DEBUGGER EXCEPTION FILTERING WITH TARGET-BASED RULES - Filtering exceptions on a target computing device to selectively interrupt a host computing device based on rules. The rules represent user-defined scenarios, and each rule includes one or more criteria and a break decision. Upon detecting an exception on the target computing device, the target computing device evaluates the rules based on the criteria and information about the exception without notifying the host computing device. For example, a score is calculated for each rule, and the rule with the highest score is selected. The break decision associated with the selected rule is applied. For example, the break decision indicates that the exception is of interest and the host computing device should be notified, or that the exception does not match a scenario of interest and execution should continue without a break. | 03-25-2010 |
| 20100095281 | Internal Function Debugger - A stealthy internal function (IF) debugger that leverages control flow detours can escape detection by traditional anti-debugging methods. Software that attempts to impede reverse engineering via dynamic analysis, by using anti-debugging or packing measures can be thwarted by using a stealthy IF debugger. Data mining through an IF utility can aid reverse engineering by constructing a data and code flow analysis after an execution of a program. | 04-15-2010 |
| 20100162217 | Debugging System Using Static Analysis - A debugging system for compiled code may include static analysis of the compiled code to determine current values for variables at a paused location within the compiled code. The static analysis may consist of liveness analysis to determine which variables are ‘live’ and in which memory locations those variables are stored. The variables and their values may be presented to a user. The debugging system may include mechanisms for setting stop points, for pausing and continuing execution, as well as stepping through a step or group of steps. Other static analysis may include unwind information that may determine a point in the code from where the current function was called, as well as partial decompilation of the source code to produce a representation of the compiled code that is closer to that of the source code. | 06-24-2010 |
| 20100169867 | DEFINING A CONDITIONAL BREAKPOINT - Among other disclosed subject matter, a computer program product is tangibly embodied in a computer-readable storage medium and includes instructions that when executed by a processor perform a method for defining a conditional breakpoint in an application program. The method includes receiving a selection of an event in an application program by a user, the event selected for activating a conditional breakpoint that interrupts execution of the application program. The method includes receiving at least one condition of multiple predefined conditions that are associated with the event and made available to the user for selection, the condition selected by the user to condition activation of the conditional breakpoint. The method includes implementing the conditional breakpoint in relation to the application program, the conditional breakpoint configured to interrupt execution of the application program upon the event occurring provided that the condition is satisfied. | 07-01-2010 |
| 20100192134 | MAPPING BREAKPOINTS BETWEEN WEB BASED DOCUMENTS - The present invention extends to methods, systems, and computer program products for mapping breakpoints between Web based documents. Embodiments of the invention facilitate extracting corresponding client script blocks from different Web based documents to disassociate the client script blocks with their relative locations within the Web based documents. From the extracted client side script blocks, a position for mapping a breakpoint from one client side script block another client side script block can be determined. The breakpoint is then copied from the one client script block and inserted into the determined position in the other client script block. The client script blocks can then be re-associated with their relative locations in the Web based documents from which they were extracted. | 07-29-2010 |
| 20110029958 | TIME-BASED BREAKPOINTS IN DEBUGERS - A time-based breakpoint facility is provided for debugging a program upon expiration of a timer. More particularly, encountering a break exception during an execution of a program results in determining if the break exception is raised by a trigger or by a breakpoint. If the break exception is raised by the trigger, steps include breaking the program execution, starting a timer and resuming the program execution without passing control to a user interface thread until the started timer expires. If the break exception is raised by the breakpoint, steps include breaking the program execution, passing control to the user interface thread, performing a debugging operation, and resuming the program execution upon indication of the user interface thread. | 02-03-2011 |
| 20110035731 | Automated Unpacking of Portable Executable Files - Automated unpacking of a portable executable file includes setting a debugging breakpoint at an original entry point address of a packed portable executable file. A debugging process is executed for the packed portable executable file to obtain a debugged portable executable file in memory. One or more of import address table data and relocation table data are collected during execution of the debugging process for the packed portable executable file. The debugged portable executable file in memory is copied to a storage medium, and the debugging process is terminated. | 02-10-2011 |
| 20110107310 | Debugging Device - A debugging tool for a time-triggered system comprises means for interrogating the system code to determine task details; means for modifying the system code to include breakpoints, the position of the breakpoints being determined by the task details; means for executing the modified system code; means for measuring the time between pre-determined ones of said breakpoints; and means for reporting the timing results to a user. | 05-05-2011 |
| 20110107311 | Communicating with Locally Networked Device from Remotely Hosted Browser Based Tool - Disclosed is a configuration for directly accessing a first computing system from a browser executing within a second computing system. One embodiment includes defining a browser code script for executing a predefined function call and defining a plurality of call functions executable by the browser code script. Each call function corresponds with a particular function on the first computing device. A direct communication link is established between a communication device driver on the second computing system and a communication device driver on the first computing system in response to the browser code script executing at least one call function of the plurality of call functions. | 05-05-2011 |
| 20110107312 | METHOD OF INTERRUPTION OF META LANGUAGE PROGRAM CODE EXECUTION - The invention relates to a computer implemented method of interruption of meta language program code ( | 05-05-2011 |
| 20110126175 | DEBUGGING METHOD AND DEBUGGING DEVICE USING HARDWARE BREAKPOINTS - A method for debugging a software program using a hardware break, the software program being executed on an information processing device including a processing unit and storage means writable and readable by the processing unit, the method includes: setting a hardware breakpoint in a hardware breakpoint table, the hardware breakpoint table being stored in the storage means and intended to store a plurality of hardware breakpoints; determining a hardware breakpoint to be set next, on the basis of a hardware breakpoint stored in the hardware breakpoint table and the value of a program counter of the processing unit executing the software program to be debugged; storing the determined hardware breakpoint in a hardware break setting register, the hardware break setting register being provided inside the information processing device and used to set a hardware breakpoint; and debugging a software program using the hardware breakpoint table. | 05-26-2011 |
| 20110131553 | ASSOCIATING PROBES WITH TEST CASES - A probe (hereinafter also referred to as a breakpoint) can be added into source code of an application program. The probe can be exported to a file or any other form of storage. The probe is then associated with a unique test case for the application program thereby creating a direct mapping between the application program and the test case for the application program. In one embodiment, the probe can be added to at least one of a function or module of the application program. | 06-02-2011 |
| 20110138364 | SEMICONDUCTOR VERIFICATION APPARATUS, METHOD, AND PROGRAM - A memory is provided for storing a control sequence of a clock cycle for each semiconductor device. The program sequence is calculated in advance and written in the memory by a program etc. on a computer. When the relevant semiconductor device is controlled, the contents of the memory are provided to the semiconductor device. | 06-09-2011 |
| 20110145797 | DEBUGGING EXTENSIBLE MARKUP LANGUAGE - Disclosed is method and system for debugging XML files or documents by inserting breakpoint into an XML file and converting the XML file into a byte code format, where the breakpoints are propagated into the byte code format and stored in runtime libraries. During runtime, on encountering the breakpoint, the location of the breakpoint is internally determined in the byte code and point to the location of the breakpoint in the XML file. | 06-16-2011 |
| 20110145798 | DEBUGGING MECHANISMS IN A CACHE-BASED MEMORY ISOLATION SYSTEM - Debugging software in systems with architecturally significant processor caches. A method may be practiced in a computing environment. The method includes acts for debugging a software application, wherein the software application is configured to use one or more architecturally significant processor caches coupled to a processor. The method includes beginning execution of the software application. A debugger is run while executing the software application. The software application causes at least one of reads or writes to be made to the cache in an architecturally significant fashion. The reads or writes made to the cache in an architecturally significant fashion are preserved while performing debugging operations that would ordinarily disturb the reads or writes made to the cache in an architecturally significant fashion. | 06-16-2011 |
| 20110191752 | Method and System for Debugging of Software on Target Devices - A system including a memory for storing a set of instructions executable by a processor. The instructions being operable to receive a definition of code information, parse the code information and generate a byte code expression for the code information, the generating including resolving the symbols of the code information, wherein the byte code expression relates to only memory access, register access and numerical operations of the code information. | 08-04-2011 |
| 20110231827 | METHODS AND APPARATUS FOR DEBUGGING PROGRAMS IN SHARED MEMORY - A system debugging program code stored in shared memory and executed by multiple processors or processing cores. Exemplary operation includes determining if an address associated with an executing instruction is outside a first address range associated with the first processor, determining if the address associated with the executing instruction is outside a second address range associated with the second processor; and then raising an emulation event based on the first comparison but not the second comparison. Exemplary embodiments are also capable of identifying instructions corresponding to breakpoints which are executed by only one of multiple processors that execute program code stored in the shared memory. | 09-22-2011 |
| 20110258613 | SOFTWARE DEBUGGER ACTIVATION BASED ON KEY PERFORMANCE INDICATORS - A software debugger is enabled and runs in the background for debugging a computer software program. The target criteria for one or more Key Performance Indicators of interest relating to the program performance are established before the program begins its execution. During execution, the debugger is activated and takes control of the program execution if a Key Performance Indicator meets its established criteria. The execution of the program is paused, and the program enters a debug mode during which an execution state of the program in system memory could be examined and modified. The debugger also provides functions for controlled execution like single-stepping, forwarding and rewinding. A user interface coupled to the debugger allows a user to interact with the debugger and control program execution. | 10-20-2011 |
| 20110258614 | Methods and Systems for Internally Debugging Code In an On-Demand Service Environment - A remote debug session for a server group is provided. A server group including multiple servers that perform workload sharing receives a request to debug code executed at the server group. The code is executed on behalf of a client of a database associated with the server group. One of the servers of the group initiates a debugging session and establishes a communication connection with the client. The one server maintains the connection open with the client for the duration of the debugging session. Subsequent requests related to the debug session can be handled in a number of ways by the server group, and all communication to the client about processing the requests is through the connection by the one server. | 10-20-2011 |
| 20110271259 | SYSTEMS AND METHODS FOR DEBUGGING APPLICATIONS USING DUAL CODE GENERATION - Systems and methods provide a debugger that debugs code using two versions of code, an optimized and a debuggable version of object code for subroutines, methods or functions. The debugger causes the appropriate version of the code to be executed depending on whether debug commands have been applied with respect to particular subroutines, methods or functions. | 11-03-2011 |
| 20110289486 | System and Method for Debugging Dynamically Generated Code of an Application - A system and method for debugging dynamically generated application code is provided. The system and method compare a received script chunk of the application to the contents of script tags of a source document, and if the script chunk does not match any of the contents of the script tags, it is identified as dynamically generated code. The identified dynamically generated code may then be stored in a separate file for further display and debugging. | 11-24-2011 |
| 20110307871 | Distributed Debugging - In an embodiment, a first debug agent at a first computer receives a packet. The first debug agent adds a debug command and an identifier of the first debug agent to the packet and sends the packet to a receiving computer. A second debug agent at the receiving computer removes the debug command and the identifier of the first debug agent from the packet and sends the packet to a second program that executes at the receiving computer. The second debug agent further executes the debug command, which causes the second program that executes on the receiving computer to halt execution at a breakpoint or address watch memory location. The second debug agent sends the state of the second program to the first debug agent, which presents, at the first computer, the state and a listing of the second program. | 12-15-2011 |
| 20110307872 | SCRIPT DEBUGGING - The present invention extends to methods, systems, and computer program products for script debugging. Embodiments of the invention serve as a plug-in to an existing debugger. The plug-in leverages the debuggers user-interface and engine. The plug-in can be a controller that subscribes to common notifications and is guided by a state machine, which stitches together a script control channel with an existing debug channel. | 12-15-2011 |
| 20110321017 | COMPUTER CODE DEBUGGING METHOD AND APPARATUS PROVIDING EXCEPTION BREAKPOINTS - A computer method and apparatus for debugging program code provides exception breakpoints with exception notification. Through a user interface, a user associates one or more exception breakpoints with respective different certain lines of code. A computer processor is configured to execute the subject program code in debug mode. During the executing, for each of the different certain lines of code, the processor: (a) pauses to pre-evaluate and determine tendency to throw an exception or spawn an interrupt, and (b) at the certain line of code, stops execution of the subject program code only if the pre-evaluating determined existence of a would-be exception or run-time interrupt. | 12-29-2011 |
| 20120005659 | DEBUGGING WORKFLOWS - Some embodiments of the inventive subject matter are directed to a debugging system (“system”) configured to access a work flow document. The workflow document may include references to flow activities connected by flow connectors, forming a workflow path. Some of the flow connectors may have breakpoints. The debugging system can insert command instructions for a hypertext transfer protocol (HTTP) request into the workflow document at locations associated with the flow connectors and initiate a test run of the workflow path. In some embodiments, during the test run, when one of the flow connectors is reached, the system executes the command instructions for the HTTP request, sending the HTTP request to a debugger application (“debugger”). If a breakpoint is associated with the flow connector, the debugger can delay response to the HTTP request, otherwise the debugger can respond immediately. A user can debug the workflow document during the delay. | 01-05-2012 |
| 20120042303 | Systems and Methods for Debugging an Application Running on a Parallel-Processing Computer System - A runtime system implemented in accordance with the present invention provides an application platform for parallel-processing computer systems. Such a runtime system enables users to leverage the computational power of parallel-processing computer systems to accelerate/optimize numeric and array-intensive computations in their application programs. This enables greatly increased performance of high-performance computing (HPC) applications. | 02-16-2012 |
| 20120047493 | BREAK ON NEXT CALLED FUNCTION OR METHOD IN JAVA DEBUGGER AGENT - Embodiments of the invention provide systems and methods for optimizing handling of breakpoints in a Java debugger agent. Embodiments provide a novel command that allows execution of the application in the debugger to stop or break at the beginning of a next called function or method (e.g., a “break on next called function” or “BNCF” command). When the BNCF command is given to the debugger, a flag may be set in the interpreter of the virtual machine to which the debugger is attached. On encountering a new method or function call, the flag is examined by the interpreter to determine whether it should stop or break in that call. If the flag is set, the interpreter will stop; otherwise the interpreter proceeds. | 02-23-2012 |
| 20120079459 | TRACING MULTIPLE THREADS VIA BREAKPOINTS - In an embodiment, a plurality of halted addresses of halted instructions are determined, at which execution of a plurality of threads of a program are halted. A respective next sequential instruction is computed, which is in the plurality of threads following the plurality of halted instructions. A respective next sequential breakpoint at the respective next sequential instruction in the plurality of threads is set. Execution of the plurality of threads is started after the setting the respective next sequential breakpoint. In response to the execution of each of the plurality of threads encountering the respective next sequential breakpoint and all of the plurality of threads halting, trace data is saved that describes the execution of each of the plurality of threads. | 03-29-2012 |
| 20120102469 | DETERMINISTIC APPLICATION BREAKPOINT HALTING BY LOGICALLY RELATING BREAKPOINTS IN A GRAPH - An operating system or virtual machine of an information handling system (IHS) initializes a debugger tool for breakpoint management of an application during debugging operations. The operating system or virtual machine initializes a directed acyclic graph (DAG) tool that employs a graphical user interface (GUI) or command line interface (CLI) for breakpoint generation and manipulation. A programmer generates breakpoints and breakpoint conditions that support the debug of application software during design, development and test. The programmer constructs one or more DAGs for use by the debugger and DAG tool. The programmer initializes the application for debugging operations. When the debugger encounters a breakpoint, the DAG tool interprets the breakpoint. If the encountered breakpoint is part of any DAG, the DAG tool determines eligibility for the encountered breakpoint to either break or not break depending on the rules of the DAG construct. The programmer may modify and add new breakpoints during debug and runtime operations of the application. | 04-26-2012 |
| 20120110552 | PROTECTING BREAKPOINTS IN A SOFTWARE DEBUGGER - A debugger that includes a breakpoint protection mechanism that detects when the program being debugged has been modified to overwrite one or more instructions corresponding to existing breakpoints. When the debugger halts execution of a program being debugged, all of the set breakpoints are checked by determining whether the instruction corresponding to each breakpoint has changed. If any of the instructions corresponding to the breakpoints has changed, the corresponding breakpoint is removed. An optional warning may be provided to the user to inform the user of any removed breakpoints. | 05-03-2012 |
| 20120110553 | IMPLEMENTING A STEP-TYPE OPERATION DURING DEBUGGING OF CODE USING INTERNAL BREAKPOINTS - Debugging of code of a computer program is facilitated by implementing a step-type operation using internal breakpoints to ensure debugger control of the code. During a debugging session, a step-type operation is implemented by setting active internal breakpoints on every line of code of every routine currently on the call stack referenced by the processor and on entry points of the code being debugged, and subsequently leaving in place, upon completion of the step-type operation, active internal breakpoints. Subsequent to implementing the step-type operation any active internal breakpoints encountered during execution of one or more other operations of the code and deemed unnecessary to completion of the other operation(s) are disabled, and the location of any internal breakpoints disabled during execution of the one or more other operations are tracked in a data structure(s) for subsequent use in reestablishing needed internal breakpoints for implementation of another step-type operation. | 05-03-2012 |
| 20120110554 | STEP-TYPE OPERATION PROCESSING DURING DEBUGGING BY MACHINE INSTRUCTION STEPPING CONCURRENT WITH SETTING BREAKPOINTS - Debugging of code of a computer program is facilitated by implementing, during a debugging session, a step-type operation by machine instruction stepping through the code, and concurrent therewith, setting up breakpoints to perform the step-type operation. Responsive to the machine instruction stepping reaching a next debuggable line of code prior to completion of setup of breakpoints to perform the step-type operation, the machine instruction stepping is discontinued, and the setting up of breakpoints to perform the step-type operation is discontinued. Alternatively, responsive to completing setup of the breakpoints to perform the step-type operation prior to machine instruction stepping reaching the next debuggable line of code, the machine instruction stepping is discontinued, and the code is executed to perform the step-type operation using the set breakpoints. | 05-03-2012 |
| 20120110555 | VARYING REMOVAL OF INTERNAL BREAKPOINTS DURING DEBUGGING OF CODE - Debugging of code of a computer program is facilitated by having a plurality of internal breakpoints associated with lines of code previously set by a processor, during a debugging session, while implementing one or more step-type operations. During execution of another operation, internal breakpoints are disabled as encountered and deemed unnecessary to completion of the another operation. A count of a number of interrupts of one or more interrupt-types experienced during execution of the another operation is maintained, and responsive to the count exceeding a threshold, the disabling is varied to remove at least N internal breakpoints responsive to encountering an internal breakpoint during execution of the another operation deemed unnecessary to completion of the another operation, where N≧2. | 05-03-2012 |
| 20120110556 | HOLDING THREADS IN A SOFTWARE DEBUGGER - A debugger includes a thread holding mechanism that analyzes the code being executed by multiple threads, and delays holding each thread that is currently executing system code external to the program until the thread is no longer executing the system code external to the program, or until some threshold is exceeded. Delaying holding of a thread that is executing system code external to the program avoids potential conditions that could lock up the debugger. | 05-03-2012 |
| 20120131558 | MANAGING BREAKPOINTS IN A MULTI-THREADED ENVIRONMENT - An electronic device is provided that, in an embodiment, saves a plurality of values for a variable specified by a condition after a respective plurality of encounters of a breakpoint by a program that modifies the variable. One of the plurality of values is selected based on a condition. A determination is made whether to stop execution of the program at the breakpoint based on the one of the plurality of the values. Execution of the program is stopped at the breakpoint if the determining is true. The program is allowed to continue to execute if the determining is false. | 05-24-2012 |
| 20120151452 | REMOTE DEBUGGING OF SERVER SIDE CODE WITHOUT BLOCKING OR HIGH-LEVEL PRIVILEGES - A server exposes debugger services to a plurality of debugger clients. One or more debugger clients can select a debug operation and establish a debug session in a thread of a server process for debugging user code. A two-way debug communication pipeline can be established between a debugger client and the server using standard encoding protocols and standard network transport protocols. A two-way debug communication pipeline can be established using HTTP where the server can initiate a communication with the debugger client using a long polling technique. When one of the threads of the server process is suspended, the other threads in the server process continue to execute. | 06-14-2012 |
| 20120167056 | DEBUGGER FOR A METADATA-CENTRIC DEVELOPMENT INFRASTRUCTURE - A computer system includes a metadata repository that is arranged and configured to store multiple meta-objects, at least one execution engine that is operably coupled to the metadata repository and that is arranged and configured to process one or more of the meta-objects during a runtime process and a debug manager that is operably coupled to the metadata repository and to the at least one execution engine and that is arranged and configured to provide an interface to the at least one execution engine and to manage one or more debug processes at a metadata level. | 06-28-2012 |
| 20120192160 | HANDLING BREAKPOINTS IN AN ASYNCHRONOUS DEBUG MODEL - Breakpoints are handled in an asynchronous debug model by building a queue of basic operations to run a debug application program interface (API). User commands are each broken down into a simple command and placed on the queue. In response to a debug event, a new simple command is generated. If, when a first command on the queue is processed, a thread is not stopped at a location with an installed breakpoint, an operation corresponding to the first command is started, the operation is removed from the queue, and a next operation is started. If the thread is stopped at the location with the breakpoint, the thread performs a hop. When the hop terminates, the first command is removed from the queue. If the first command is a run command, and there is no cause to stop the thread, the run command is moved to the end of the queue. | 07-26-2012 |
| 20120246624 | DEBUGGER-SET IDENTIFYING BREAKPOINTS AFTER COROUTINE YIELD POINTS - A debugger can step through target code in a computer program. The debugger can identify a coroutine yield point in the target code, and can obtain identifying information to identify continued processing of a coroutine instance triggered by the operator. The debugger can set a breakpoint at a location for continued stepping after the coroutine yield point. The breakpoint can have a condition of matching the identifying information with runtime information. The debugger can perform the coroutine instance and resume execution of the target code after the coroutine yield point. The debugger can also encounter the breakpoint in the target code, and can determine whether the condition of the breakpoint is met. If so, the debugger can pause execution of the target code at the breakpoint. If not, the debugger can continue execution of the target code past the breakpoint without pausing at the breakpoint. | 09-27-2012 |
| 20120266144 | STEPPING OUT OF AN ASYNCHRONOUS METHOD INTO ITS CONTINUATION IN A DEBUGGER - Stepping out of an asynchronous process. A method includes, as part of a computer program execution, at a caller, making an asynchronous function call from the caller to a callee. Associated with the asynchronous function call a continuation waits for the completion of the callee with respect to the asynchronous function call. The method further includes correlating a debugging indicator to the callee indicating that a user wishes to step out of the caller when the callee returns. An indication of completion of the callee with respect to the asynchronous function call and that a user wishes to step from the callee to the continuation is received. The debugging indicator is referenced and based on the debugging indicator execution at entry into the continuation is stopped. | 10-18-2012 |
| 20120284699 | Systems, Method, and Apparatus to Debug a Network Application - A method includes instantiating a cloned network that includes a second set of virtual service nodes. The second set of virtual service nodes includes at least one cloned virtual service node that is a clone of a corresponding virtual service node in a first set of virtual service nodes. The at least one cloned virtual service node has access to a history of events that occurred at the corresponding virtual service node in the first set of virtual service nodes. The method includes initiating an interactive debugging session that includes step by step processing of the events of the history of events. | 11-08-2012 |
| 20120304155 | System, Method And Program Product For Executing A Debugger - A method for controlling a debugger, the method includes: determining whether to execute a certain breakpoint of the debugger in view of certain breakpoint conditional information and in view of at least one previous visit, during the execution of the debugger, to at least one other breakpoint of the debugger; and selectively executing the certain breakpoint in response to the determination. | 11-29-2012 |
| 20120317552 | User-Specific Software Debugging - User-specific software debugging with user-specific step commands that includes: receiving a command to step execution to a source code module associated with a user; identifying routines in a call stack associated with the user; inserting, for each identified routine, a breakpoint at each source code line of the routine; inserting, for each source code module associated with the user and not in the call stack, a breakpoint at an entry point of the source code module; and executing the debuggee until the debuggee encounters one of the inserted breakpoints thereby halting execution of the debuggee. User-specific debugging with user-specific DLL load processing modes including: receiving a selection of a user-specific DLL processing mode; upon loading a DLL, retrieving a user identification; determining whether the DLL is associated with the user; and processing the DLL in accordance with user-specific DLL processing mode only if the DLL is associated with the user. | 12-13-2012 |
| 20120331449 | DEVICE, METHOD AND COMPUTER PROGRAM PRODUCT FOR EVALUATING A DEBUGGER SCRIPT - A method for evaluating a debugger script, the method includes: (i) receiving a debugger script that includes a first debugger breakpoint that is associated with a certain program line number; and determining a validity of the first debugger breakpoint in response to a comparison between expected content associated with the first debugger breakpoint and between an actual content of at least a portion of a certain program line group that comprises a certain program line identified by the certain program line number. | 12-27-2012 |
| 20130019228 | Resuming A Prior Debug SessionAANM Bates; Cary L.AACI RochesterAAST MNAACO USAAGP Bates; Cary L. Rochester MN US - Inserting, at debuggee source code lines, a breakpoint and executing. For each breakpoint encounter until exiting: encountering and removing the breakpoint, incrementing a first counter value, and resuming execution. Exiting includes saving the first counter value, a state of the call stack, and an exit location. In a second debug session, preparing the debuggee to resume from the exit location. Inserting, at the debuggee source code lines, a breakpoint and executing the debuggee. For each breakpoint encounter until a second counter value matches the first: encountering and removing the breakpoint, incrementing the second counter value, and resuming execution. When the first and second counter values match: inserting an exit location breakpoint at the exit location, executing the debuggee until encountering the exit location breakpoint, and providing the user control to resume debugging from the exit location only if the present state of the call stack matches the saved state. | 01-17-2013 |
| 20130031534 | Software Development With Information Describing Preceding Execution Of A Debuggable Program - Software development with information describing preceding execution of a debuggable program includes receiving, by a debugger from a compiler, a copy of a debuggable program, the debuggable program including one or more phantom breakpoints not encountered during a previous execution of the debuggable program, each phantom breakpoint inserted at a separate line of source code, phantom breakpoints encountered in a previous execution of the debuggable program being removed during the previous execution and not included in the copy of the debuggable program; executing, by the debugger, the copy of the debuggable program; upon each encounter of a breakpoint, determining, by the debugger, whether the encountered breakpoint is a phantom breakpoint; and if the encountered breakpoint is a phantom breakpoint, issuing, by the debugger, a warning indicating a point of straying execution. | 01-31-2013 |
| 20130055217 | BREAKPOINT SYNCHRONIZATION FOR MODIFIED PROGRAM SOURCE CODE - A method for breakpoint synchronization in program source code includes in response to creation of a breakpoint in the program source code, storing by a computer, in a breakpoint store, a line number of the breakpoint and line contents corresponding to text located at the stored line number in the program source code; in the event the program source code is modified, synchronizing the breakpoint with the modified program source code, wherein synchronizing the breakpoint with the modified program source code comprises: searching the modified program source code for the stored line contents; identifying an updated line number for the breakpoint; inserting the breakpoint at the updated line number in the modified program source code; and updating the breakpoint store with the updated line number. | 02-28-2013 |
| 20130086559 | RESUMING A PRIOR DEBUG SESSION - Inserting, at debuggee source code lines, a breakpoint and executing. For each breakpoint encounter until exiting: encountering and removing the breakpoint, incrementing a first counter value, and resuming execution. Exiting includes saving the first counter value, a state of the call stack, and an exit location. In a second debug session, preparing the debuggee to resume from the exit location. Inserting, at the debuggee source code lines, a breakpoint and executing the debuggee. For each breakpoint encounter until a second counter value matches the first: encountering and removing the breakpoint, incrementing the second counter value, and resuming execution. When the first and second counter values match: inserting an exit location breakpoint at the exit location, executing the debuggee until encountering the exit location breakpoint, and providing the user control to resume debugging from the exit location only if the present state of the call stack matches the saved state. | 04-04-2013 |
| 20130091494 | Suspending and Resuming a Graphics Application Executing on a Target Device for Debugging - Debugging a graphics application executing on a target device. The graphics application may execute CPU instructions to generate graphics commands to graphics hardware for generation of graphics on a display. A breakpoint for the graphics application may be detected at a first time. In response to detecting the breakpoint, one or more graphics commands which were executed by the graphics hardware proximate to the first time may be displayed. Additionally, source code corresponding to CPU instructions which generated the one or more graphics commands may be displayed. | 04-11-2013 |
| 20130104108 | PROTECTING BREAKPOINTS IN A SOFTWARE DEBUGGER - A debugger that includes a breakpoint protection mechanism that detects when the program being debugged has been modified to overwrite one or more instructions corresponding to existing breakpoints. When the debugger halts execution of a program being debugged, all of the set breakpoints are checked by determining whether the instruction corresponding to each breakpoint has changed. If any of the instructions corresponding to the breakpoints has changed, the corresponding breakpoint is removed. An optional warning may be provided to the user to inform the user of any removed breakpoints. | 04-25-2013 |
| 20130111452 | Pseudo Hardware Watch Points for Remote Debugging of Non-initialized Processors | 05-02-2013 |
| 20130117732 | TECHNIQUE TO IMPROVE PERFORMANCE OF SOFTWARE BREAKPOINT HANDLING - The debugging system is provided that includes a debugging module that receives an application having one or more software breakpoints such that when a target system encounters the one or more software breakpoints the debugging module starts handling of the one or more software breakpoints. A determination is made as to whether the one or more software breakpoints is a selective software breakpoint, if it is determined that the selective software breakpoint has been encountered, the debugging module eliminates instruction replacement for all other remaining breakpoints and execution of the original instruction of the application at the encountered breakpoint or eliminates instruction replacement for all other remaining breakpoints and reinstalls the encountered breakpoint. | 05-09-2013 |
| 20130152054 | SETTING BREAKPOINTS IN OPTIMIZED INSTRUCTIONS - A method, computer-readable storage medium, and computer system are provided. In an embodiment, in response to a command that requests setting a breakpoint at a line in a module, a determination is made whether a snapshot instruction exists before a machine instruction that implements a source statement at the line. If the snapshot instruction exists before the machine instruction that implements the source statement at the line, the breakpoint is set at the machine instruction that implements the source statement at the line. If the snapshot instruction does not exist before the machine instruction that implements the source statement at the line, the module is recompiled to add the snapshot instruction before the machine instruction that implements the source statement. | 06-13-2013 |
| 20130159978 | STATE CAPTURE AFTER EXECUTION IN DEPENDENT SEQUENCES - The execution of a dynamic code segment sequence that includes at least two code segments in sequence. The first code segment is first executed and the corresponding state of the environment is captured. The second code segment is then executed. When the second code segment is later re-executed, the first code segment is not re-executed again. Rather, the environmental state is set to be the captured state that existed when the first code segment originally executed. Then, the second code segment may be executed without spending the resources required to re-run the first code segment. This may be employed at authoring time, or after deployment time. | 06-20-2013 |
| 20130191815 | TSQL DEBUG BREAKPOINT INTEROPERABILITY ACROSS HETEROGENEOUS PROJECTS - TSQL debug breakpoint interoperability across heterogeneous project systems within an IDE can be provided. A user can set a breakpoint in the user's SQL source code and the breakpoint can be triggered by the code within another project. Breakpoints can be set and triggered within SQL source code tiles that reside in one or more SQL Database projects. Binding of the application project being debugged with one or more SQL Database projects that reside within the IDE session can be automated, SQL artifacts not found in any of the SQL Database projects can be debugged. | 07-25-2013 |
| 20130227530 | METHOD AND APPARATUS FOR DEBUGGING A PROGRAM OF A BUSINESS PROCESS - A method and apparatus for debugging a program of a business process, the method comprising: displaying a flowchart of the process on a display, said displaying being enabled by one or more plug-ins; enabling setting of a debugging breakpoint in the displayed flowchart of the process of the program; operating a simulator for creating a simulated runtime environment for executing the program as if the program is operating in actual application; executing the program using the simulator; continuously communicating status of the executing program from the simulator to one of the plug-ins; determining at one of the plug-ins whether the status of the executing program has reached the breakpoint set in the displayed flowchart of the process of the program; and suspending execution of the program when the plug-in determines that the status of the executing program has reached the breakpoint set in the displayed flowchart of the process of the program. | 08-29-2013 |
| 20130232473 | Code Coverage Detection with Scriptable Language Unmodified Source - Code coverage detection for interpreted scriptable programming languages avoids source code modification. Each program element of the script is performed by (a) using a debugger to proactively computationally indicate in a coverage data structure that the element was reached, and integrally (b) running non-logger executable code which corresponds to the element. Coverage of lines, statements, and other program elements during script execution can be measured even though the source code has not been instrumented with injected log statements. Proactively generated breakpoints pass control from each coverage-tracked program element into a code coverage debugger which updates the coverage data structure. Comments are skipped. Code coverage detection may be invoked from a command line, an Integrated Development Environment, or another context. The coverage data structure is correlated with the source code to produce a coverage map that is displayed to users showing which source code was performed. | 09-05-2013 |
| 20130247007 | MAKING DEBUGGER BEHAVIOR CONDITIONAL ON PAST PROGRAM STATE - A debugger variable is set; the variable is associated with: at least one location within a program to be debugged; and at least one expression that is valid within a scope of the location. A breakpoint associated with a location within the program is also set. Upon encountering the at least one location of the debugger variable during a current run of the program, a value of the at least one expression with which the debugger variable is associated is computed and assigned to the debugger variable. Upon encountering the location of the breakpoint during the current run of the program, the debugger is operated in at least one of a first manner and a second manner, depending on the value of the debugger variable; the first manner is different than the second manner. | 09-19-2013 |
| 20130263094 | SETTING BREAKPOINTS IN OPTIMIZED INSTRUCTIONS - A method, computer-readable storage medium, and computer system are provided. In an embodiment, a command is received that specifies a debug compile option and requests a compile of a module into object code. If the debug compile option specifies a first debug compile option, snapshot instructions are inserted immediately prior to each machine instruction in the object code at which a breakpoint was previously set. If the debug compile option specifies the first debug compile option, snapshot instructions are inserted immediately prior to each machine instruction in the object code that implements a control flow statement. | 10-03-2013 |
| 20130263095 | CONTROLLING ASYNCHRONOUS CALL RETURN - Aspects include controlling asynchronous call return in a program. At least one asynchronous call is detected in the program. Execution of the program is stopped at a breakpoint in response to detecting that the breakpoint is set in the program. At least one callback corresponding to the at least one asynchronous call is obtained. The at least one callback is inserted into one or more specified positions of the program respectively according to a user selection. Execution of the program continues from the breakpoint in response to the insertion of the at least one callback into the program. | 10-03-2013 |
| 20130283243 | Compiling Source Code For Debugging With Variable Value Restoration Based On Debugging User Activity - Compiling source code includes receiving, by an optimizing compiler from a debugger, a variable value modification profile that specifies locations in the source code at which variable values modified during a debug session; compiling the source code, including: inserting snapshots at one or more of the locations in the source code at which variable values were modified, each snapshot including a breakpoint; and only for each snapshot at a location in the source code at which variable values were modified: inserting, between the breakpoint and remaining source code at the location of the snapshot, a module of computer program instructions that when executed retrieves a current value of a variable and stores the current value in a register; and recording the location of each inserted snapshot; and providing, to the debugger by the optimizing compiler, the recorded locations of each inserted snapshot along with the compiled source code. | 10-24-2013 |
| 20130283244 | Debugging Extensible Markup Language - Disclosed is a method and system for debugging XML files or documents by inserting a breakpoint into an XML file and converting the XML file into a bytecode format, where the breakpoint is propagated into the bytecode format and stored in runtime libraries. During runtime, on encountering the breakpoint, the location of the breakpoint is internally determined in the bytecode and points to the location of the breakpoint in the XML file. | 10-24-2013 |
| 20130290937 | EFFICIENT EXTRACTION OF SOFTWARE DEPENDENCIES FROM PROGRAM CODE - Calls to stop functions are identified in a computer program file. The stop functions are functions that interact with external resources. Parameters of the calls to the stop functions that are references to the external resources are identified. An analysis is performed over the computer program file to find out possible values of the parameters of the calls. | 10-31-2013 |
| 20130318507 | APPARATUS, METHOD, AND SYSTEM FOR PROVIDING A DECISION MECHANISM FOR CONDITIONAL COMMITS IN AN ATOMIC REGION - An apparatus and method is described herein for conditionally committing and/or speculative checkpointing transactions, which potentially results in dynamic resizing of transactions. During dynamic optimization of binary code, transactions are inserted to provide memory ordering safeguards, which enables a dynamic optimizer to more aggressively optimize code. And the conditional commit enables efficient execution of the dynamic optimization code, while attempting to prevent transactions from running out of hardware resources. While the speculative checkpoints enable quick and efficient recovery upon abort of a transaction. Processor hardware is adapted to support dynamic resizing of the transactions, such as including decoders that recognize a conditional commit instruction, a speculative checkpoint instruction, or both. And processor hardware is further adapted to perform operations to support conditional commit or speculative checkpointing in response to decoding such instructions. | 11-28-2013 |
| 20140007058 | DETERMINING SNAPSHOT PLACEMENT | 01-02-2014 |
| 20140013312 | SOURCE LEVEL DEBUGGING APPARATUS AND METHOD FOR A RECONFIGURABLE PROCESSOR - Provided are a source level debugging apparatus and method for a coarse grained array (CGA)-based reconfigurable processor. The source level debugging apparatus may determine valid operations for setting a breakpoint in a result of source code scheduling using invalid operation information, and may set the breakpoint at an address corresponding to the determined valid operations. | 01-09-2014 |
| 20140033180 | ESTABLISHING CLOUD DEBUG BREAKPOINTS ASSIGNED TO USERS - In an embodiment, a cloud debug breakpoint, assigned to a first user, is established in a program at a first server in a cloud, wherein the first user selects the first server at which the program executes, from among servers in the cloud. The program at the servers in the cloud is executed, in response to requests from users. The program at the first server in the cloud is executed, in response to all requests from the first user to the program. If an identifier of a user that sent a request that the program was executing at a time that execution of the program at the first server reaches the cloud debug breakpoint matches an identifier of the first user assigned to the cloud debug breakpoint, the execution of the program is halted and control of a processor is given to a debugger. | 01-30-2014 |
| 20140033181 | REVERSE DEBUGGING - A method and reverse debugger are provided for reversely debugging a program. The method includes: obtaining debugging information of the program as outputted by a compiler, the debugging information including information related to extended basic blocks of the program; in response to the program entering into reverse debugging, setting a reverse debugging checkpoint at an entry address of at least one extended basic block; in response to the program reaching a set reverse debugging checkpoint, storing information required by debugging that corresponds to the reverse debugging checkpoint; in response to receiving a set reverse debugging target breakpoint, making the program return to a reverse debugging checkpoint located before the reverse debugging target breakpoint and nearest to the reverse debugging target breakpoint, obtaining information required to be stored by the debugging stored at the reverse debugging checkpoint, and continuing to execute the program till the reverse debugging target breakpoint. | 01-30-2014 |
| 20140033182 | BREAK ON NEXT CALLED FUNCTION OR METHOD IN JAVA DEBUGGER AGENT - Embodiments of the invention provide systems and methods for optimizing handling of breakpoints in a Java debugger agent. Embodiments provide a novel command that allows execution of the application in the debugger to stop or break at the beginning of a next called function or method (e.g., a “break on next called function” or “BNCF” command). When the BNCF command is given to the debugger, a flag may be set in the interpreter of the virtual machine to which the debugger is attached. On encountering a new method or function call, the flag is examined by the interpreter to determine whether it should stop or break in that call. If the flag is set, the interpreter will stop; otherwise the interpreter proceeds. | 01-30-2014 |
| 20140075418 | REPLACING CONTIGUOUS BREAKPOINTS WITH CONTROL WORDS - In an embodiment, a first execution path in a program is determined that has been executed a largest number of times, as compared to at least one other path in the program. Swapped instructions are replaced in the program with breakpoints, wherein the swapped instructions are not on the first execution path. The breakpoints that are not on the first execution path and that are contiguous to each other are replaced in the program with a control word. | 03-13-2014 |
| 20140115566 | STATE MACHINE CONTROL OF A DEBUGGER - A debugger utilizes a finite state machine to control when execution of a software application is suspended. The finite state machine uses breakpoints as transitions that move the finite state machine from a start state to an acceptance state. The debugger tracks when breakpoints used in the finite state machine occur. When the finite state machine reaches an acceptance state, the debugger suspends execution of the software application to allow a developer to observe and/or alter the program state or software application. The finite state machine may be generated by a developer as a graph or as a regular expression that is then converted into a finite state machine. In this manner, a developer may specify more complex conditions upon which to suspend execution of a debugger. | 04-24-2014 |
| 20140201718 | ANALYZING CONCURRENT DEBUGGING SESSIONS - Methods, apparatuses, and computer program products for analyzing concurrent debugging sessions are provided. Embodiments include a first debugger initiating a conditional breakpoint in a first debug session of a first application. The conditional breakpoint stops execution of the first application based on a condition of a value of a variable of a second application. Embodiments also include the first debugger requesting and receiving the value of the variable from a second debugger. Embodiments also include the first debugger evaluating the condition of the conditional breakpoint based on the received value of the variable. | 07-17-2014 |
| 20140201719 | ANALYZING CONCURRENT DEBUGGING SESSIONS - Methods, apparatuses, and computer program products for analyzing concurrent debugging sessions are provided. Embodiments include a first debugger initiating a conditional breakpoint in a first debug session of a first application. The conditional breakpoint stops execution of the first application based on a condition of a value of a variable of a second application. Embodiments also include the first debugger requesting and receiving the value of the variable from a second debugger. Embodiments also include the first debugger evaluating the condition of the conditional breakpoint based on the received value of the variable. | 07-17-2014 |
| 20140245269 | COMPACT ENCODING OF NODE LOCATIONS - Techniques for encoding node locations are provided. In some examples, a node in a hierarchy such as a document object model (DOM) may be expressed as a location path from the root node of the hierarchy to the node. Each node on the location path may be encoded using a mapping between the type and/or index of the node and a set of characters such as ASCII characters. The encoding of each node on the path be concatenated to form the encoded location path. The encoding seeks to minimize the length of the encoded location path. For example, in an embodiment, a single ASCII character may be used to encode both the type and the index of a node. In an embodiment, breakpoint locations may be encoded using methods provided to reduce storage and computing resource required. | 08-28-2014 |
| 20140289711 | INFORMATION PROCESSING APPARATUS AND DEBUGGING METHOD - An information processing apparatus includes a system memory, a cache system that includes a cache memory, and a plurality of cores, each of which accesses the system memory and the cache memory. The cache system stores in a cache line of the cache memory a break indicator that designates one or more of the plurality of cores. The cache system determine whether a first core in the plurality of cores that issues a request to read data from an address that corresponds to the cache line in which the break indicator is stored matches one of the cores designated by the break indicator. If the first core matches one of the cores designated by the break indicator, the cache system returns a break command to the first core. If the first core does not match one of the cores designated by the break indicator, the cache system returns the data to the first core. | 09-25-2014 |
| 20140310693 | IMPLEMENTING EDIT AND UPDATE FUNCTIONALITY WITHIN A DEVELOPMENT ENVIRONMENT USED TO COMPILE TEST PLANS FOR AUTOMATED SEMICONDUCTOR DEVICE TESTING - A method for debugging test procedures for automated device testing is disclosed. The method comprises receiving a command to update at least one modified test procedure modified during a first debugging session and saving state information for a test plan, wherein the state information comprises information regarding a breakpoint entry location, and wherein the modified test procedure is invoked within the test plan. The method subsequently comprises suspending execution of the test plan and unloading the modified test procedure. It also comprises compiling the modified test procedure to produce a compiled file and then reloading the test procedure into the test plan using the compiled file. Finally, it comprises resuming execution of the modified test procedure in a second debugging session and breaking the execution during the second debugging session at a breakpoint corresponding to the breakpoint entry location. | 10-16-2014 |
| 20140325488 | SYSTEMS AND METHODS FOR DEBUGGING APPLICATIONS USING DUAL CODE GENERATION - Systems and methods provide a debugger that debugs code using two versions of code, an optimized and a debuggable version of object code for subroutines, methods or functions. The debugger causes the appropriate version of the code to be executed depending on whether debug commands have been applied with respect to particular subroutines, methods or functions. | 10-30-2014 |
| 20140331210 | INSERTING IMPLICIT SEQUENCE POINTS INTO COMPUTER PROGRAM CODE TO SUPPORT DEBUG OPERATIONS - Arrangements described herein relate to inserting implicit sequence points into computer program code to support debug operations. Optimization of the computer program code can be performed during compilation of the computer program code and, during the optimization, implicit sequence points can be inserted into the computer program code. The implicit sequence points can be configured to provide virtual reads of symbols contained in the computer program code when the implicit sequence points are reached during execution of the computer program code during a debug operation performed on the computer program code after the computer program code is optimized and compiled. | 11-06-2014 |
| 20140344789 | STEP OVER OPERATION FOR MACHINE CODE FUNCTION CALLS - A method for implementing a step over operation by a debugger for an instruction in a routine includes receiving a step over command for an instruction and determining whether the instruction is a branch used for a function call. If the instruction is not a branch used for a function call, then the debugger treats the instruction as not a function call. If the instruction is a branch used for a function call, then the debugger determines whether the instruction is generated from source code. If the instruction is not generated from source code, then the debugger treats the instruction as not a function call. If the instruction is generated from source code, then the debugger treats the instruction as a function call. | 11-20-2014 |
| 20140344790 | EVALUATION OF STATEMENT-LEVEL BREAKPOINTS - A method for evaluating a breakpoint in a line of source code includes encountering the breakpoint and evaluating whether the breakpoint is at the start of the line. If the breakpoint is at the start of the line, then the debugger stops at the breakpoint and tracks the breakpoint. If the breakpoint is not at the start of the line, then the debugger evaluates whether the breakpoint is reached via a back branch. If the breakpoint is not at the start of the line and is reached via a back branch, then the debugger stops at the breakpoint and tracks the breakpoint. If the breakpoint is not at the start of the line and is not a back branch target, then the debugger passes the breakpoint and tracks the breakpoint. | 11-20-2014 |
| 20140366007 | DEBUGGING NATIVE CODE BY TRANSITIONING FROM EXECUTION IN NATIVE MODE TO EXECUTION IN INTERPRETED MODE - A dual-mode debugger can debug native code or interpreted code. Transitioning between modes can be triggered by defined bailout conditions. A program can be debugged by attaching a debugger and compiling the program into native code under the debugger. At defined points in the program, debugging can transition from native mode to interpreted mode. Debugging the native code can stop, current state can be captured, and an interpreter can be instantiated. An interpreter stack can be created and can be populated with the captured current state. Debugging operations which involve execution control: pausing execution, continuing execution, stepping into, out of or over a section of code and so on, can occur in interpreted mode, which is typically easier to implement. Debugging operations which involve inspection and modification of variables can occur in native mode. | 12-11-2014 |
| 20150033210 | METHOD AND SYSTEM FOR DEBUGGING A CHANGE-SET - Exemplary embodiment of include methods and systems for debugging a change-set. The method includes obtaining a change-set for debugging; calculating a code change region by using the change-set and generating breakpoints for debugging the change-set based on the code change region. In exemplary embodiments, breakpoints in a change-set can be set quickly and effectively. | 01-29-2015 |
| 20150033211 | PROGRAM DEBUGGER AND PROGRAM DEBUGGING - Debug information records associated with a weak function of the program are obtained. In response to receipt of an instruction of setting a breakpoint for the weak function in the program, breakpoint addresses corresponding one-to-one with each of the at least one debug information record are obtained. In response to the program being executed to a set breakpoint associated with the weak function, an address to which a program counter of the program points is obtained. A breakpoint address matching the address to which the program counter of the program points is obtained. A mark for the matching breakpoint address is set. In response to receipt of the instruction of setting a breakpoint for the weak function in the program again, a debug information record corresponding to the matching breakpoint address according to the at least one debug information record with the mark being set is obtained. | 01-29-2015 |
| 20150046908 | SYSTEM AND METHOD FOR HYPERVISOR BREAKPOINTS - Methods and systems allow the use of hypervisors to use software breakpoints in the same manner as hardware breakpoints. A program to be tested is executed by a hypervisor running a virtual machine. A memory page containing the location of a breakpoint is copied to a temporary memory page. Then a new page is written containing breakpoint instructions at specified memory locations. The new page is tagged as execute only, so the program to be tested is unaware of any changes to the program. If the program attempts to read from the changed memory page, it will read from the temporary memory page instead. Such a method can be used to search websites for malware in relative safety because of the inability of the malware to write to memory locations that are located on a page that is execute only. | 02-12-2015 |
| 20150058827 | BREAKING CODE EXECUTION BASED ON TIME CONSUMPTION - An on-chip system uses a time measurement circuit to trap code that takes longer than expected to execute by breaking code execution on excess time consumption. | 02-26-2015 |
| 20150067655 | Dynamic Debugging Method of a Software Module and Corresponding Device - When a module is loaded by the operating system kernel, dynamic information of the module, such as the memory addresses of the different sections of the module allocated by the operating system, is stored in a known variable, which is subsequently accessible by the debugging tool. Furthermore, an interrupt instruction that will allow the debugger to interrupt the running of the operating system following the complete loading of the module is inserted into the debugging tool in such a way as to retrieve the dynamic information necessary for the debugging of the module. | 03-05-2015 |
| 20150074653 | EXECUTING CODE ON A TEST INSTRUMENT IN RESPONSE TO AN EVENT - Automatic test equipment (ATE) may include: a test instrument to implement a communication protocol to communicate to a unit under test (UUT), where the test instrument is memory storing bytecode that is executable, and where the test instrument being configured to identify an event in communication between the test instrument and the UUT and, in response to the event, to execute the bytecode. The ATE may also include a test computing system to execute a test program and an editor program, where the editor program is for receiving human-readable code and for generating the bytecode from the human-readable code, and the test program is for registering the event with the test instrument and for downloading the bytecode to the test instrument for storage in the memory. | 03-12-2015 |
| 20150143344 | Diagnosing Production Applications - A debugging and diagnostics system allow for dynamic code generation that inserts code into a production application to identify snappoints or breakpoints that cause snapshots to be taken if predefined conditionals are satisfied. The snappoints are associated with locations in source code for the production application and include conditional statements that must be met to create a snapshot of the production application. The snappoints are used to generate a collection plan that is provided to the server running the production application. The server rewrites the code of the production application based upon the collection plan to insert instructions that create snapshots when the conditional statements are met. | 05-21-2015 |
| 20150293835 | SYSTEM ON CHIP AND VERIFICATION METHOD THEREOF - A verification method of a system on chip includes receiving a test generator and an exception handler; generating, by the test generator, a test program including an exception-causing instruction based on a test template; executing a first instruction at a first operating state as the test program is executed; stopping the execution of the test program and performing a fixed instruction sequence included in the exception handler when the exception-causing instruction is executed during the execution of the test program; and resuming the test program from a second instruction at a second operating state set after the fixed instruction sequence is performed, the second instruction corresponding to an address adjacent to an address of the exception-causing instruction. | 10-15-2015 |
| 20150331782 | VALIDATING CORRECTNESS OF EXPRESSION EVALUATION WITHIN A DEBUGGER - A method for validating correctness of expression evaluation within a debugger. The method includes determining a statement of interest comprising an expression recognized by a debugger program within one or more source program files of a debuggable program and generating a debug command file for the statement of interest. The method includes inserting a set of debug commands, comprising a first path for a baseline run and a second path for a test run for the statement of interest, into the debug command file, then causing the execution of the baseline run and test run. Results from the baseline run and results from the test run are compared to determine if the results from the baseline run are equivalent to the results from the test run. | 11-19-2015 |
| 20160062874 | DEBUG ARCHITECTURE FOR MULTITHREADED PROCESSORS - Debug architecture for multithreaded processors. In some embodiments, a method includes, in response to receiving a halt command, saving a context of a thread being executed by a processor core to a context memory distinct from the processor core; suspending execution of the thread; and initiating a debug of the thread using the context stored in the context memory. In other embodiments, an integrated circuit includes a processor core; a context management circuit coupled to the core; and a debug support circuit coupled to the context management circuit, the debug support circuit configured to send a halt request to the context management circuit and the context management circuit configured to, in response to having received the request, facilitate a debug operation by causing execution of a thread running on the core to be suspended and saving a context of the thread into a context memory distinct from the core. | 03-03-2016 |
| 20160092345 | PATH-SPECIFIC BREAK POINTS FOR STREAM COMPUTING - A plurality of processing elements having stream operators and operating on one or more computer processors receive a stream of tuples. A first stream operator adds a first attribute to a tuple received on a first port of the first stream operator. The first attribute indicates the first port and the first stream operator. A second stream operator adds a second attribute to a tuple received on a first port of the second stream operator. The second attribute indicates the first port of the second stream operator and the second stream operator. It is determined whether a debug tuple has been received by a third stream operator. A debug tuple is a tuple that includes the first and second attributes. An operation, such as halting execution or incrementing a count of debug tuples, is performed when it is determined that a debug tuple has been received. | 03-31-2016 |
| 20160140027 | REGRESSION TESTING WITH EXTERNAL BREAKPOINTS - Regression testing of software applications is described. Breakpoints are inserted in a programming code of an object to perform testing of all software applications that use the object. A processor in a computing device can receive data representing a programming code of a functionality of a software application rectifying a problem associated with the functionality of the software application. The processor can determine another software application executing the functionality. The processor can insert a breakpoint in the programming code of the functionality of the software application and the another software application. The breakpoint can be inserted at a location in the programming code of the software application where the problem was rectified. The processor can execute the programming code of the functionality including the inserted breakpoint. The processor can determine, based on the executing, whether the problem has been rectified in the software application and the another software application. | 05-19-2016 |
| 20160154636 | INSERTING IMPLICIT SEQUENCE POINTS INTO COMPUTER PROGRAM CODE TO SUPPORT DEBUG OPERATIONS | 06-02-2016 |
| 20160154637 | INSERTING IMPLICIT SEQUENCE POINTS INTO COMPUTER PROGRAM CODE TO SUPPORT DEBUG OPERATIONS | 06-02-2016 |
| 20160188439 | MANAGING ASSERTIONS WHILE COMPILING AND DEBUGGING SOURCE CODE - The present disclosure relates to maintaining assertions in an integrated development environment (IDE) tool. According to one embodiment, while the IDE tool is compiling the source code of a development project, the IDE tool generates at least a first compiler warning. The first compiler warning generally corresponds to at least one line of source code in a first source code component of the development project. A first set of assertions to add to the source code of the development project is determined based on the line of source code that resulted in the first compiler warning. The IDE tool adds the first set of assertions to the source code of the development project. The first set of assertions are compiled as part of the source code of the development project. | 06-30-2016 |
| 20160188440 | MANAGING ASSERTIONS WHILE COMPILING AND DEBUGGING SOURCE CODE - The present disclosure relates to maintaining assertions in an integrated development environment (IDE) tool. According to one embodiment, while the IDE tool is compiling the source code of a development project, the IDE tool generates at least a first compiler warning. The first compiler warning generally corresponds to at least one line of source code in a first source code component of the development project. A first set of assertions to add to the source code of the development project is determined based on the line of source code that resulted in the first compiler warning. The IDE tool adds the first set of assertions to the source code of the development project. The first set of assertions are compiled as part of the source code of the development project. | 06-30-2016 |
| 20160253253 | AUTOMATED UNPACKING OF PORTABLE EXECUTABLE FILES | 09-01-2016 |
| 20160378639 | DEBUGGING USING PROGRAM STATE DEFINITIONS - A program state definition comprises target values that correspond to problematic or unexpected output of a program. A debugger compares the target values of the program state definition to variable values of a program and stops execution of a program at a point where all target values are contained in variables of the program. By stopping execution of a program, the debugger allows a programmer to analyze the program at that point. Unlike a breakpoint, a program state definition is not tied to a specific line of code, variable, or function but, rather, has a scope of an entire program or a specified section of a program. | 12-29-2016 |
| 20180024908 | DEBUGGER THAT CORRELATES DIFFERING VALUES TO SYSTEM ENVIRONMENTS IN A DISTRIBUTED SYSTEM | 01-25-2018 |
| 20190146785 | Diagnosing Production Applications | 05-16-2019 |
| 20190146898 | ASSISTIVE, LANGUAGE-AGNOSTIC DEBUGGING WITH MULTI-COLLABORATOR CONTROL | 05-16-2019 |
| 20190146902 | DEVELOPMENT-TIME AWARENESS OF A PRODUCTION DEPENDENCY INJECTION ENVIRONMENT | 05-16-2019 |
