IP Library Granted Patent US 8,756,583
Granted Patent B2
US 8,756,583 · App. 13/674,235 · Granted Jun 17, 2014

Thread-specific event management in a non-stop debugging environment

Inventor: Cary L. Bates (Rochester, MN)
Assignee: International Business Machines Corporation
View Patent ↗
Loading inventors, assignments & file history…
Monitor This Case
Get email alerts when status or documents change.
Order Certified Copies
Most orders are placed with the USPTO same day — all within 24 business hours.
Order via The Patent Place →
Pre-filled with this patent's details
Quick Facts
Patent No.
US 8,756,583
App. No.
13/674,235
Granted
Jun 17, 2014
Kind
B2
Abstract

A non-stop debugging environment includes a debugger configured to debug a multi-threaded debuggee. In the non-stop debugging environment, encountering an event by one of the threads stops execution of only the one thread without concurrently stopping execution of the other threads. Thread-specific events may managed in the non-stop debug environment by identifying, by the debugger for a thread of execution of the debuggee not currently executing, a thread-specific event associated with the thread; removing, by the debugger, the thread-specific event for all threads of the debuggee; and upon the thread resuming execution, replacing, by the debugger, the thread-specific event.

Claims (17)

1. A method of thread-specific event management in a non-stop debugging environment, the non-stop debugging environment comprising a debugger configured to debug a debuggee comprising a plurality of threads of execution, wherein encountering an event by one of the threads stop execution of only the one thread without concurrently stopping execution of the other threads, the method comprising:

identifying, by the debugger for a thread of execution of the debuggee not currently executing, a thread-specific event associated with the thread, wherein the thread specific event comprises predefined operation code previously inserted into original operational code for the thread of execution;

tracking a length of time the thread is not executing;

in response to determining that the length of time exceeds a predetermined threshold, removing, by the debugger, the thread-specific event for all threads of the debuggee while the thread of execution associated with the thread-specific event is not currently executing; and

upon the thread resuming execution, replacing, by the debugger, the thread-specific event.

2. The method of claim 1 further comprising tracking a number of encounters of the thread-specific event while the thread is not executing, wherein removing the thread-specific event for all threads of the debuggee further comprises removing the thread-specific event for all threads only if the number of encounters exceeds a predetermined threshold.

3. The method of claim 1 , further comprising:

receiving a user request to hold the thread from executing; and

stopping execution of the thread.

4. The method of claim 1 , further comprising encountering, by the thread, an event stopping execution of the thread.

5. The method of claim 1 , further comprising determining that the thread is in a wait state and, thereby, not currently executing.

6. The method of claim 1 further comprising:

receiving, by the debugger from an operating system, an indication that the thread is waiting for a lock restricting access to a resource;

stopping, by the debugger, execution of the thread;

at a time after removing the thread-specific event for all threads of the debuggee:

receiving, by the debugger from the operating system, an indication that the lock is available to the thread; and

resuming, by the debugger, execution of the thread.

Assignments (1)
ASSIGNMENT OF ASSIGNOR'S INTEREST Recorded Nov 12, 2012
From: BATES, CARY L.
To: INTERNATIONAL BUSINESS MACHINES CORPORATION
Reel/Frame 029279/0273 →
Continuity (2)
Continuation 13033925 · Feb 24, 2011
Related Publication 20130074041A1 · Mar 21, 2013