Debugging multiple related processes simultaneously

Details Debugging multiple related processes simultaneously Debugging multiple related processes simultaneously

1999-08-31

2003-02-04

Dam, Tuan Q. (Department: 2124)

Data processing: software development, installation, and managem

Software program development tool

Testing or debugging

C717S131000

Reexamination Certificate

active

06516460

ABSTRACT:

BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates to debugging multiple related processes simultaneously. More particularly, this invention relates to debugging multiple related processes simultaneously from one instance of a debugger
2. Prior Art
As part of the development of software applications, software programmers frequently must “debug” their code to ensure it operates properly and without interruption. There are numerous debugging methods and techniques, including special debugging application programming interfaces and breakpoints. To aid programmers, debugging programs or debuggers have been developed. Debuggers can be stand-alone or integrated into another software application such as an object-oriented application development environment.
Many of the current state-of-the-art debuggers do not simultaneously debug multiple related processes (programs) using one instance of the debugger. Related processes are processes that are spawned, directly or indirectly, from a single process. For example, a parent process may spawn child related processes and in turn, the child related processes may act as a parent process spawning further child related processes; all processes spawned in this manner are related to each other. To debug related processes, a user often must start one or more instances of a debugger to debug a parent process and its child process(es). And, an example of debuggers heretofore not simultaneously debugging multiple related processes using one instance of a debugger are those designed for the Microsoft Windows NT® and Windows® 95 operating systems.
Debugging multiple related processes simultaneously can be important since processes often work in conjunction with other processes. One such example is the “Producer”/“Consumer” problem where one process produces data or information that another process requires as input. Being able to debug both the Producer process and Consumer process simultaneously has advantages, especially when the communication between the two processes are asynchronous and the events sent between the Producer and Consumer occur at non-deterministic rates or occur in a non-deterministic ordering. Being able to debug both processes simultaneously gives the user more control in recreating the specific ordering of events that generate a failure in processing. Further, being able to debug both processes simultaneously from the same instance of the debugger provides usability gains and convenience by for example allowing the user to view information flowing between processes and the states of the processes.
In the Windows NT and Windows 95 operating systems, the problem of debugging related processes can be understood by examining the application programming interface (API) functions these operating systems provide which allow debuggers to perform process control. In particular, the functions WaitForDebugEvent( ) and ContinueDebugEvent( ) are provided by Windows NT and Windows 95 to debug a process. The first function, WaitForDebugEvent( ), monitors for the occurrence of a debug event in a process that has been initiated for debugging by the function ContinueDebugEvent( ). When a debug event occurs in a process, that process is stalled. Debug events can include the spawning of a child process or a programming fault. The second function, ContinueDebugEvent( ), initiates debugging of a process and continues debugging of a process if the process has been stalled due to the occurrence of a debug event observed by the function WaitForDebugEvent( ). A key constraint that both these functions share is that only the thread that created the process being debugged can call WaitForDebugEvent( ) or ContinueDebugEvent( ). Therefore, debugging related processes in a single instance of a debugger has been constrained. As has been known in the art debugging related processes can be performed by invoking multiple instances of a debugger. Invoking multiple instances of a debugger has the apparent disadvantages of using more computer resources such as processing and memory.
As a pseudocode example, the following function, CreateProcesso ( ), can be used to create a process on the Windows NT and Windows 95 operating systems:
BOOL CreateProcess(LPCTSTR lpApplicationName,
LPSTR lpCommandLine,
LPSECURITY_ATTRIBUTES lpProcessAttributes,
LPSECURITY_ATTRIBUTES lpThreadAttributes,
BOOL bInheritHandles,
DWORD dwCreationFlags,
LPVOID lpEnvironment,
LPCTSTR lpCurrentDirectory,
LPSTARTUPINFO lpStartupInfo,
LPPROCESS_INFORMATION lpProcessInformation
);
The debugger loads the debuggee by making a call to CreateProcess( ). The thread which executes this call becomes the only thread that can thereafter make calls to WaitForDebugEvent( ) and ContinueDebugEvent( ). We can now refer to this thread as being “special”. Pseudocode to perform this might be as follows:
//executing on “special” debugger thread
//
PROCESS_INFORMATION process_info;
STARTUPINFO startup_info={0};
startup_info.cb=sizeof(STARTUPINFO);
CreateProcess(NULL,
“example.exe”,
NULL,
NULL,
False,
DEBUG_PROCESS¦ CREATE_NEW_CONSOLE|
NORMAL_PRIORITY_CLASS,
NULL,
NULL,
&startup_info,
&process_info);
DWORD process_id=process_info.dwProcessId;
DWORD thread_id=process_info.dwThreadId;
Next, in order to run the newly created process, the debugger must issue a ContinueDebugEvent( ) from the “special” thread. This allows the newly created debuggee process to begin execution:
// executing on “special” debugger thread
//
ContinueDebugEvent(process_id,thread_id,DBG_CONTINUE);
In order to receive notifications about events occurring in the debuggee, the debugger must then issue a WaitForDebugEvent( ) on the “special”thread. If INFINITE is specified as the second argument to the call, then the WaitForDebugEvent( ) blocks indefinitely until an event occurs:
// executing on “special” debugger thread
// blocks until an event occurs
//
DEBUG_EVENT debug_event;
WaitForDebugEvent(&debug_event, INFINITE);
The debugger can be considered as being in a cycle or loop. Once WaitForDebugEvent( ) returns with an event, the debugger would respond to the event (such as a breakpoint being hit or a child process being spawned) and perform some action based on the event. Then, to restart the debuggee, the debugger would return back on a loop to call ContinueDebugEvent( ) again which will restart the debuggee. The pseudocode for such a cycle might be as follows:
// executing on “special” debugger thread
//
DEBUG_EVENT debug_event;
for (;;) {
// let the debuggee process run
//
ContinueDebugEvent(process_id,thread_id,DBG_CONTINUE);
// blocks until an event occurs
//
WaitForDebugEvent(&debug_event,INFINITE);
// handle the event that occurred
//
FunctionToHandleDebugEvent(debug_event);
}
FunctionToHandleDebugEvent( ) will handle the event (such as a breakpoint) returned via the call to WaitForDebugEvent( ) by, for example, updating the state and views of the debugger and/or allowing the user to examine the state of the debuggee or terminate the loop. When the user has finished examining the state of the debuggee, the call to FunctionToHandleDebugEvent( ) will return back to the loop in order to restart the debuggee (unless terminate within FunctionToHandleDebugEvent( )). Indeed, FunctionToHandleDebugEvent( ) can block (not return) until the user wants to restart the debuggee.
This flow of control works well when debugging a single process via this “special” thread. A problem arises when a child process is created by the process being debugged. If the debuggee at some point spawns another process (for example, for WaitForDebugEvent( ) returns a CREATE_PROCESS_DEBUG_EVENT) then the debugger must manage the newly created process on the same “special” thread.
To handle the additional process(es), the above loop would need to be modified. ContinueDebugEvent( ) would need to be called for all processes being debugged, not just the original process. This modification is shown below by the addition of the forEachProcessBeingDebugged pseudo-instruction.
// executing on “special”

Affiliated with

Also associated with

Rating

Debugging multiple related processes simultaneously does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Debugging multiple related processes simultaneously, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Debugging multiple related processes simultaneously will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3178766