#924 Debugger steps through code incorrectly

4: Serious
Debugger (52)

Summary: if an object's toString method returns null, when you step through code in the debugger, the object will be treated as null. So code behavior in the debugger is not the same as without the debugger. drjava-20100913-r5387 on MacOSX


Put the following code into DrJava:

public class Exp {
public int x = 17;
public String toString () { return null;}
public static void main (String [] args) {
Exp e = new Exp();

Run it in the debugger. Output: 17, as expected.

Now put a breakpoint on the System.out.println(e.x) line. Run it in the debugger again. Hit the breakpoint. Hit "resume." Program crashes with a null pointer exception. Why? Because e.toString is null and somehow the debugger cares about this fact.

Not only does the debugger think your code should crash, but it also traces the code incorrectly: if you replace System.out.println(e.x); with

if (e==null) <some code>

then <some code> will get executed if you step through it in the debugger, but NOT otherwise. Again, the debugger thinks e is null because e.toString() is null.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks