BreakpointHandler is not always correctly resetting the single stepping flag
when a breakpoint is hit
The Problem
This problem was found by Gordon Hirsch after applying all of the massive
debugger fixes to 1.1.4G. Robert Field has indicated that the fix must wait
until 1.1.5. I'm entering this bug as a way to track the problem so that it
can be fixed for 1.1.5:
BreakpointHandler is not always correctly resetting the single stepping flag
when a breakpoint is hit. This causes the debugger to do a single instruction
step when it should be doing something else (like a go or a step over). Under
some circumstances, the user will see very strange behavior.
Our proposed fix
The diff for the fix is below. It involves simply moving a call to
setSingleStep from inside an if block to the outside so that both conditions
are covered.
*** c:\temp\BreakpointHandler.java Wed Jul 30 19:15:35 1997
--- BreakpointHandler.java Wed Aug 06 13:28:14 1997
***************
*** 287,307 ****
}
if (ignoreSingleStep(the_bkptQ.thread,
the_bkptQ.pc)) {
continue;
}
- agent.setSingleStep(the_bkptQ.thread, false);
} else {
if (bkpt.thread != null && bkpt.thread !=
the_bkptQ.thread) {
// Not our thread
continue;
}
if (debug) {
Agent.message("Received a breakpoint event:
pc=" +
the_bkptQ.pc);
}
}
agent.suspendAllThreads();
if (bkpt != null) {
if (bkpt.type == BKPT_ONESHOT) {
deleteBreakpoint(bkpt.clazz, bkpt.pc);
--- 287,307 ----
}
if (ignoreSingleStep(the_bkptQ.thread,
the_bkptQ.pc)) {
continue;
}
} else {
if (bkpt.thread != null && bkpt.thread !=
the_bkptQ.thread) {
// Not our thread
continue;
}
if (debug) {
Agent.message("Received a breakpoint event:
pc=" +
the_bkptQ.pc);
}
}
+ agent.setSingleStep(the_bkptQ.thread, false);
agent.suspendAllThreads();
if (bkpt != null) {
if (bkpt.type == BKPT_ONESHOT) {
deleteBreakpoint(bkpt.clazz, bkpt.pc);
john.bui@eng 1997-10-17
No specific test case available. Implicity tested, closed with exposure.
when a breakpoint is hit
The Problem
This problem was found by Gordon Hirsch after applying all of the massive
debugger fixes to 1.1.4G. Robert Field has indicated that the fix must wait
until 1.1.5. I'm entering this bug as a way to track the problem so that it
can be fixed for 1.1.5:
BreakpointHandler is not always correctly resetting the single stepping flag
when a breakpoint is hit. This causes the debugger to do a single instruction
step when it should be doing something else (like a go or a step over). Under
some circumstances, the user will see very strange behavior.
Our proposed fix
The diff for the fix is below. It involves simply moving a call to
setSingleStep from inside an if block to the outside so that both conditions
are covered.
*** c:\temp\BreakpointHandler.java Wed Jul 30 19:15:35 1997
--- BreakpointHandler.java Wed Aug 06 13:28:14 1997
***************
*** 287,307 ****
}
if (ignoreSingleStep(the_bkptQ.thread,
the_bkptQ.pc)) {
continue;
}
- agent.setSingleStep(the_bkptQ.thread, false);
} else {
if (bkpt.thread != null && bkpt.thread !=
the_bkptQ.thread) {
// Not our thread
continue;
}
if (debug) {
Agent.message("Received a breakpoint event:
pc=" +
the_bkptQ.pc);
}
}
agent.suspendAllThreads();
if (bkpt != null) {
if (bkpt.type == BKPT_ONESHOT) {
deleteBreakpoint(bkpt.clazz, bkpt.pc);
--- 287,307 ----
}
if (ignoreSingleStep(the_bkptQ.thread,
the_bkptQ.pc)) {
continue;
}
} else {
if (bkpt.thread != null && bkpt.thread !=
the_bkptQ.thread) {
// Not our thread
continue;
}
if (debug) {
Agent.message("Received a breakpoint event:
pc=" +
the_bkptQ.pc);
}
}
+ agent.setSingleStep(the_bkptQ.thread, false);
agent.suspendAllThreads();
if (bkpt != null) {
if (bkpt.type == BKPT_ONESHOT) {
deleteBreakpoint(bkpt.clazz, bkpt.pc);
john.bui@eng 1997-10-17
No specific test case available. Implicity tested, closed with exposure.