Dr. Dobb's Journal - September 2008 - (Page 58)

d09kilch_p3db 7/11/08 1:31 PM Page 58 State of the Art SIGNALLING INTEGER OVERFLOWS IN JAVA (a) import org.objectweb.asm.*; import java.io.*; public class MyInstrumentation { public static void main(String[] args) throws IOException { String filename = args[0]; FileInputStream fis = new FileInputStream(filename); ClassReader cr = new ClassReader(fis); ClassWriter cw = new ClassWriter(cr, ClassWriter.COMPUTE_FRAMES); ClassAdapter ca = new MyClassAdapter(cw); cr.accept(ca, 0); byte[] newByteCode = cw.toByteArray(); fis.close(); FileOutputStream fos = new FileOutputStream(filename); fos.write(newByteCode); fos.close(); } } //————————————————————class MyMethodAdapter extends MethodAdapter implements Opcodes { public MyMethodAdapter(MethodVisitor mv) { super(mv); } //——————————————————————————— public void visitInsn(int opcode) { final String METHOD_NAME= “checkedIADD”; final String METHOD_LOCATION=”utils/SecuredArithmetics”; final String METHOD_SIGNATURE=”(II)I”; if (opcode == IADD) { mv.visitMethodInsn(INVOKESTATIC, METHOD_LOCATION, METHOD_NAME, METHOD_SIGNATURE); } else { mv.visitInsn(opcode); } } } //————————————————————class MyClassAdapter extends ClassAdapter { public MyClassAdapter(ClassVisitor cv) { super(cv); } //——————————————————————————— public MethodVisitor visitMethod(int access, String name, String desc, String signature, String[] exceptions) { MethodVisitor mv; mv = cv.visitMethod(access, name, desc, signature, exceptions); if (mv != null) { mv = new MyMethodAdapter(mv); } return mv; } } default logging will repeatedly report the same location every time it causes an overflow. It is straightforward to define a better logging callback that filters already-seen locations, as in Example 4. Our approach of bytecode instrumentation is not the only way of attacking the overflow problem. An idea to reduce the slowdown would be a probabilistic technique that decides at runtime whether an operation has to be checked or not. An alternative would be to write nonportable C code to consult the CPU overflow flag, and bind this code with JNI. Another interesting approach is static analysis: We could, for instance, extend JML tools (like ESCJava) to report at compile-time some of the potential overflows, as is already done for bad array indices. By the way, it can be argued that reporting overflows is a poor goal and that we should aim at completely suppressing the overflow risk, for example, automatically converting int/long to BigInteger objects; this is not trivial because it would cause deep transformations in the code (e.g. converting arrays to ArrayLists). Finally, a totally different approach would be to rely on virtualization: Is it difficult to adapt QEmu or Xen, for example, so that the virtual machine signals to the host OS any overflow occurring in any running process of the guest OS? (b) public class Hello { public static void main(String[] args) { int a=3, b=5, c=Integer.MAX_VALUE; System.out.println(a+c); System.out.println(a+b); } } (c) prompt> javac Hello.java prompt> java Hello -2147483646 8 prompt> java MyInstrumentation "Hello.class" prompt> java Hello Overflow! -2147483646 8 Conclusion Arithmetic overflow is an annoying feature of most programming languages: On rare occasions, it is exploited by the programmers as a computation property; but most of the time, it is simply a nasty source of bugs. Any attempt to help discovering bugs and deliver robust code is worth trying. That is why Java developers should keep an eye on recent developments. Just to arbitrarily name a few free new tools, look to Eclipse TPTP, JML verifiers (www.cs.ucf.edu/~leavens/JML), delta debugging support (www.st.cs.uni-sb.de/ eclipse), the ODB “omniscient debugger” (www.lambdacs.com/debugger)—or COJAC. DDJ Example 3: Simple instrumentation example: (a) instrumentation program, (b) instrumented test program, (c) commands and result. (a) import java.util.HashSet; package logging; } } (b) prompt> java -jar cojac.jar -call logging/BetterLog/log Java2Demo.jar Example 4: Using a reaction callback: (a) code, (b) command. 58 Dr. Dobb’s Journal l www.ddj.com l September 2008 http://www.cs.ucf.edu/~leavens/JML http://www.st.cs.uni-sb.de/eclipse http://www.st.cs.uni-sb.de/eclipse http://www.lambdacs.com/debugger http://www.ddj.com

Table of Contents Feed for the Digital Edition of Dr. Dobb's Journal - September 2008

Dr. Dobb's Journal - September 2008 Contents Friday Night Fish Fry Alia Vox Developer Diaries Developer’s Notebook A Conversation With Erik Demaine Application Lifecycle Management Meets Model-Driven Development Building a Robust Development Environment Real Users Really Matter Matching Wildcards: An Algorithm The Android Mobile Phone Platform Managing Application Thread Use Signalling Integer Overflows in Java .NET Development & the IBM WebSphere Portal Server The Agile Edge Effective Concurrency Swaine’s Flames

Dr. Dobb's Journal - September 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.