Bugzilla – Full Text Bug Listing
| Summary: | For input string: "FFFFFFFF" | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Mark Jeronimus <mark.jeronimus> | ||||
| Component: | Debug | Assignee: | Sarika Sinha <sarika.sinha> | ||||
| Status: | CLOSED WONTFIX | QA Contact: | |||||
| Severity: | normal | ||||||
| Priority: | P3 | CC: | Michael_Rennie, sarika.sinha, srikanth_sankaran | ||||
| Version: | 4.4 | Flags: | sarika.sinha:
review?
(Michael_Rennie) |
||||
| Target Milestone: | --- | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 7 | ||||||
| Whiteboard: | stalebug | ||||||
| Attachments: |
|
||||||
Pass to JDT/Debug for comment. Created attachment 248691 [details]
Patch to allow "FFFFFFFF"
Error is happening because of NumberFormatException thrown by Integer.valueOf.
Using Long.valueOf instead to support this.
(In reply to Sarika Sinha from comment #2) > Created attachment 248691 [details] > Patch to allow "FFFFFFFF" > > Error is happening because of NumberFormatException thrown by > Integer.valueOf. > > Using Long.valueOf instead to support this. Here is the trace for easier searching: java.lang.NumberFormatException: For input string: "FFFFFFFF" at java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) at java.lang.Integer.parseInt(Integer.java:583) at java.lang.Integer.valueOf(Integer.java:740) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.parseIntValue(ASTInstructionCompiler.java:3134) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.visit(ASTInstructionCompiler.java:3094) at org.eclipse.jdt.core.dom.NumberLiteral.accept0(NumberLiteral.java:136) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.visit(ASTInstructionCompiler.java:2736) at org.eclipse.jdt.core.dom.InfixExpression.accept0(InfixExpression.java:365) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.visit(ASTInstructionCompiler.java:4235) at org.eclipse.jdt.core.dom.VariableDeclarationFragment.accept0(VariableDeclarationFragment.java:256) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTInstructionCompiler.visit(ASTInstructionCompiler.java:4262) at org.eclipse.jdt.core.dom.VariableDeclarationStatement.accept0(VariableDeclarationStatement.java:260) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782) at org.eclipse.jdt.core.dom.Block.accept0(Block.java:137) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.core.dom.ASTNode.acceptChild(ASTNode.java:2759) at org.eclipse.jdt.core.dom.MethodDeclaration.accept0(MethodDeclaration.java:635) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782) at org.eclipse.jdt.core.dom.TypeDeclaration.accept0(TypeDeclaration.java:470) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.core.dom.ASTNode.acceptChildren(ASTNode.java:2782) at org.eclipse.jdt.core.dom.CompilationUnit.accept0(CompilationUnit.java:212) at org.eclipse.jdt.core.dom.ASTNode.accept(ASTNode.java:2711) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.createExpressionFromAST(ASTEvaluationEngine.java:545) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.getCompiledExpression(ASTEvaluationEngine.java:328) at org.eclipse.jdt.internal.debug.eval.ast.engine.ASTEvaluationEngine.evaluate(ASTEvaluationEngine.java:131) at org.eclipse.jdt.internal.debug.ui.actions.EvaluateAction$1.run(EvaluateAction.java:259) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:119) The patch does prevent the exception, but I don't think its the complete fix - in this case it will parse a long (ok) but then create a pushInt instruction (not ok). If we have to parse it as a long then we should make sure to add the corresponding pushLong instruction. Some unit test for this might help flesh out further issues. Also while debugging it, I found that the code to compute the 'subtoken' ends up stripping off the last 'F' which is not desired unless we need to remove 'f' or 'd' or 'l' from decls like 4.3f, 34l. 3.4d, so even if you let the code fall-through to parse a long it will try to parse 0xFFFFFFF instead of 0xFFFFFFFF. After I saw the attachment, I noticed the same happens with binary and octal.
0b11111111111111111111111111111111
037777777777
Sorry it took so long to respond. I tried to verify my findings using remote desktop to home, and apparently my PC BSOD'd and I couldn't get in from work.
@MichaelRennie: did you see the attachment?
(In reply to Mark Jeronimus from comment #4) > After I saw the attachment, I noticed the same happens with binary and octal. > > 0b11111111111111111111111111111111 > > 037777777777 > Thanks for the update, we will make sure to add these in the tests as well. > > @MichaelRennie: did you see the attachment? Yes: "The patch does prevent the exception, but I don't think its the complete fix - in this case it will parse a long (ok) but then create a pushInt instruction (not ok)." I think we need to create some unit tests for this and make sure that we are creating the correct instructions in the compiler (and that we don't break anything in the process). This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie. |
In the debugger, trying to evaluate the code value & 0xFFFFFFFF where value is an int or long, gives the unhelpful error dialog: For input string: "FFFFFFFF" Other negative hexadecimal int constants do the same. Evaluating it in the Expressions view, the error is a bit more verbose: 'JDI thread evaluations' has encountered a problem. Exception processing async thread queue Exception processing async thread queue For input string: "8FFFFFFF"