Summary: | Exception during debugging when hover mouse over a field | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Lysathor <lysathor> | ||||
Component: | Core | Assignee: | Srikanth Sankaran <srikanth_sankaran> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | normal | ||||||
Priority: | P3 | CC: | amj87.iitr, bugs.eclipse.org, darin.eclipse, larza, mauromol, odrotbohm, srikanth_sankaran | ||||
Version: | 3.6 | ||||||
Target Milestone: | 3.7 M2 | ||||||
Hardware: | PC | ||||||
OS: | Windows XP | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Lysathor
2010-06-16 10:06:09 EDT
Remark: When pasing the variable name to "expressions", it is displayed without problems. Which version of Eclipse does this happen on? i.e. what is the "Build id" on the "Help > About Eclipse" diaog? It is the Helios RC4. What is the type of the field? Does the type of the field you are hovering over have a detail formatter associated with it? Yes, I use Detail Formatters. But not all variables seem to be influenced. I get an Error for a HashMap. The Formatter I use is: getClass().getSimpleName()+":"+toString() When the formatter is disabled, the exception does not occur. When pasting the expression abc.getClass().getSimpleName()+":"+abc.toString() with instance abc to the "expressions" view, the value is correctly displayed. I see the same behavior with today's version of 3.6.1 with a simple "toString()" formatter on java.lang.Object. I can reproduce the problem with the following steps. The CCE is happenning in JDT Core code, but I'm not sure if Debug is doing anything wrong. Moving to JCore for comment. * Create a Detail Formatter for java.util.HashMap with the following snippet: getClass().getSimpleName()+":"+toString() * Debug a Junit test like this, stopping at Breakppint public void testCapacity() { int size= fFullest.size(); HashMap map = new HashMap(); for (int i= 0; i < 100; i++) { // BREAKPOINT fFullest.addElement(new Integer(i)); map.put(new Integer(i), new Integer(i)); } assertTrue(fFullest.size() == 100+size); } * Select "map" in the variables view or hover over it: java.lang.ClassCastException: org.eclipse.jdt.internal.compiler.lookup.BinaryTypeBinding cannot be cast to org.eclipse.jdt.internal.compiler.lookup.SourceTypeBinding at org.eclipse.jdt.internal.compiler.lookup.TypeBinding.isProvablyDistinct(TypeBinding.java:633) at org.eclipse.jdt.internal.compiler.ast.Expression.checkUnsafeCast(Expression.java:526) at org.eclipse.jdt.internal.compiler.ast.Expression.checkCastTypesCompatibility(Expression.java:486) at org.eclipse.jdt.core.dom.TypeBinding.isCastCompatible(TypeBinding.java:1014) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.getEnclosingLevel(ASTInstructionCompiler.java:406) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.visit(ASTInstructionCompiler.java:2757) at org.eclipse.jdt.core.dom.MethodInvocation.accept0(MethodInvocation.java:237) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.visit(ASTInstructionCompiler.java:2616) at org.eclipse.jdt.core.dom.InfixExpression.accept0(InfixExpression.java:364) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) at org.eclipse.jdt.core.dom.ReturnStatement.accept0(ReturnStatement.java:136) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) at org.eclipse.jdt.core.dom.Block.accept0(Block.java:136) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2528) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:504) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:484) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2551) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:219) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2480) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.createExpressionFromAST(ASTEvaluationEngine.java:448) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.getCompiledExpression(ASTEvaluationEngine.java:395) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.getCompiledExpression(ASTEvaluationEngine.java:365) at org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager.getCompiledExpression(JavaDetailFormattersManager.java:395) at org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager.resolveFormatter(JavaDetailFormattersManager.java:158) at org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager.access$1(JavaDetailFormattersManager.java:143) at org.eclipse.jdt.internal.debug.ui.JavaDetailFormattersManager$2.run(JavaDetailFormattersManager.java:138) at org.eclipse.jdt.internal.debug.core.model.JDIThread$ThreadJob.run(JDIThread.java:2756) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) Created attachment 175634 [details]
avoiding the cast
I haven't tried your scenario but the offending cast is definitely
unnecessary as my patch shows.
Thanks for the patch, Stephen, I'll follow up for M2. Comment on attachment 175634 [details]
avoiding the cast
Patch looks good. I'll release the patch with
minor cleanup shortly.
Released in HEAD for 3.7 M2. Note to verifier: Please verify by code inspection and checking that the scenario in comment# 7 is addressed by this patch. I didn't have much luck reducing it to a junit with reasonable effort. Verified for 3.7M2 using build I20100909-1700. *** Bug 338629 has been marked as a duplicate of this bug. *** *** Bug 341930 has been marked as a duplicate of this bug. *** |