Bug 167896 - Error with Expressions and multiple debug sessions
Summary: Error with Expressions and multiple debug sessions
Status: RESOLVED DUPLICATE of bug 167895
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Debug (show other bugs)
Version: 3.3   Edit
Hardware: PC Windows XP
: P3 normal (vote)
Target Milestone: ---   Edit
Assignee: Platform-Debug-Inbox CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-12-13 13:44 EST by B. Drost CLA
Modified: 2006-12-13 13:55 EST (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description B. Drost CLA 2006-12-13 13:44:03 EST
Build ID: M20060629-1905

Steps To Reproduce:
Enter the debug view. Open two debug sessions, a JAVA-Session J and some other session (non-java) D (for example C/C++). write some expressions that can be evaluated in D but not in J (eg. using C/C++ only constructs). The problem: Eclipse reports errors when both are suspended and one changes the focus (==klicking to a stackframe) from D (where the expressions are evaluated correctly) to J (where they cannot be evaluated, when it should just silently mark them "invalid" (red).




More information:
I traced that down to the class org.eclipse.debug.internal.core.WatchExpression:

Eclipse calls the "setExpressionContext()" method, since the context was changed from D to J. This in turn calls "evaluate" for reciving the result of the expression from J. However, the old value of the expression, obtained by D, is still stored in fResult.

Now when "evaluate()" calls "setPending()", a watchExpressionChanged is fired, and since J already registered for that, it calls "getValue()" (The call comes from "JDIModelPresentation.getExpressionText()"). getValue() however will return the _old_ value stored in fResult (This might be a race condition), and since that old value is some class from my own debugger D, J gets confused and throws an error.

IMHO, WatchExpression.setPending(true) should set fResult to null to invalidate the old result.
Comment 1 Darin Wright CLA 2006-12-13 13:55:16 EST

*** This bug has been marked as a duplicate of bug 167895 ***