Bug 284022 – NPE in ConditionalBreakpointHandler...determineVote during evaluation

Bug 284022 - NPE in ConditionalBreakpointHandler...determineVote during evaluation


Summary:	NPE in ConditionalBreakpointHandler...determineVote during evaluation

Status:	VERIFIED FIXED

Product:	JDT
Classification:	Eclipse
Component:	Debug
Version:	3.5
Hardware:	PC Windows XP

Importance:	P3 normal (vote)
Target Milestone:	3.6 M7
Assigned To:	Darin Wright
QA Contact:

URL:
Whiteboard:
Keywords:

Duplicates:	307380 (view as bug list)
Depends on:
Blocks:
	Show dependency tree

Reported:	2009-07-20 11:30 EDT by Chris West (Faux)
Modified:	2010-04-05 10:07 EDT (History)
CC List:	3 users (show)

See Also:

Flags:	Michael_Rennie: review+

Attachments
patch (1.48 KB, patch) 2010-03-26 14:08 EDT, Darin Wright	no flags	Details \| Diff
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Chris West (Faux)

2009-07-20 11:30:27 EDT

Build ID: I20090611-1540

Steps To Reproduce:
1. Set a conditional breakpoint in a method.
2. Evaluate any call to said method.

e.g.
class Neep {
    public static void main(String[] args) {
        foo(); // line 3
    }

    static void foo() {
        int i = 7;
        ++i; // line 8
    }
}

a) Breakpoint line 3.
b) Breakpoint line 8: Conditional: i == 4
c) Debug.
Execution will stop on line 3.
d) Highlight the call to foo().
e) Evaluate (Ctrl+u / ctrl+shift+d / ctrl+shift+i).
f) Error will be displayed.

Happens, as far as I can see, on any conditional, type, method, depth of tree, etc.

More information:
eclipse.buildId=I20090611-1540
java.version=1.6.0_13
java.vendor=Sun Microsystems Inc.
BootLoader constants: OS=win32, ARCH=x86, WS=win32, NL=en_GB
Command-line arguments:  -os win32 -ws win32 -arch x86


Error
Mon Jul 20 15:58:32 BST 2009
An internal error occurred during: "JDI Event Dispatch".

java.lang.NullPointerException
	at org.eclipse.jdt.internal.debug.core.breakpoints.ConditionalBreakpointHandler$EvaluationListener.determineVote(ConditionalBreakpointHandler.java:101)
	at org.eclipse.jdt.internal.debug.core.breakpoints.ConditionalBreakpointHandler$EvaluationListener.evaluationComplete(ConditionalBreakpointHandler.java:81)
	at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.doEvaluation(ASTEvaluationEngine.java:172)
	at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.evaluateExpression(ASTEvaluationEngine.java:147)
	at org.eclipse.jdt.internal.debug.core.breakpoints.ConditionalBreakpointHandler.breakpointHit(ConditionalBreakpointHandler.java:207)
	at org.eclipse.jdt.internal.debug.core.model.JDIThread.handleSuspendForBreakpoint(JDIThread.java:1104)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.suspend(JavaBreakpoint.java:363)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleBreakpointEvent(JavaBreakpoint.java:351)
	at org.eclipse.jdt.internal.debug.core.breakpoints.JavaBreakpoint.handleEvent(JavaBreakpoint.java:288)
	at org.eclipse.jdt.internal.debug.core.EventDispatcher.dispatch(EventDispatcher.java:189)
	at org.eclipse.jdt.internal.debug.core.EventDispatcher.access$0(EventDispatcher.java:104)
	at org.eclipse.jdt.internal.debug.core.EventDispatcher$1.run(EventDispatcher.java:250)
	at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55)

Comment 1 Chris West (Faux)

2009-07-20 17:31:19 EDT

As could have easily been guessed, the problem is the nested evaluation of the breakpoint condition; the processor of said result assumes that an exception caused the evaluation failure; this is not the case.

Quickly fixing that in org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.doEvaluation(ICompiledExpression, IRuntimeContext, IJavaThread, IEvaluationListener, int, boolean):
result.setException(new DebugException(new Status(IStatus.ERROR, JDIDebugPlugin.getUniqueIdentifier(), IStatus.OK, EvaluationEngineMessages.ASTEvaluationEngine_Cannot_perform_nested_evaluations, null)));

...still results in an un-resumable JVM, so there's something deeper wrong here.

To be reeeally clear, with the fix:
First evaluate -> Conditional breakpoint encountered a runtime exception. Reason: Cannot perform nested evaluations.
Cancelling this dialog leaves you attempting to evaluate, so any further attempts to evaluate result in a messagebox with just "Cannot perform nested evaluations.", and resume / step / etc. commands are disabled.

Comment 2 Darin Wright

2010-03-26 14:08:09 EDT

Created attachment 163109 [details]
patch

JDI does not support nested evaluations. When a breakpoint is hit during an evaluation (and the preference to suspend at breakpoints during evaluations is on), we have to ignore any conditions - the VM simply won't be able to evaluate them.

Comment 3 Darin Wright

2010-03-26 14:08:39 EDT

Applied/Fixed. Please verify, Mike.

Comment 4 Michael Rennie

2010-03-29 12:49:06 EDT

looks reasonable.

Comment 5 Darin Wright

2010-04-05 10:07:59 EDT

*** Bug 307380 has been marked as a duplicate of this bug. ***