Menu
▾
▴
#586 Debugger Infinite Loop
Create two .java files. (TestA, TestB)
public class TestA{
public static void main(String[] args){
TestB.doSomething();
}
}
public class TestB{
public static void doSomething(){
System.out.println("Will have frozen by now.");
}
}
Now, after you have made these two classes, open TestA and close TestB in Dr Java. In Debug Mode with a breakpoint at TestB.doSomething(), run the program.
Once the breakpoint is hit, do "Step Into".
The program freezes in what I assume is an infinite loop when it should just open the TestB file and step into it.
Logged In: YES
user_id=1075744
Originator: NO
I can't reproduce this problem. Can you please give us additional information? Are you using the flat-file or project mode? What exactly do you mean by "open TestA and close TestB"? When a file is closed, i.e. removed from the project or file list, the breakpoints are removed, so closing TestB would remove the breakpoint in TestB.doSomething(). If I don't close TestB, then DrJava will successfully suspend the program at the breakpoint, and when I press "Step Into", DrJava will execute the println call, and then after a few more "Step Into" finish the program.
Would you also mind posting the version of DrJava you are using and the system information from the "System Properties" pane of the "About" dialog (in the "Help" menu)? If you have a more recent version, there is a "Copy System Properties" button that will put all your information into the clipboard (while protecting your privacy by removing user names, etc.).
Thank you for your help.
Logged In: YES
user_id=1683818
Originator: YES
We cannot attempt to fix this bug without more information. Please post another comment detailing what you were doing to cause this to happen. If you have it, please include the information from the DrJava error window.
Thanks,
The DrJava Team
Logged In: YES
user_id=1683818
Originator: YES
"so closing TestB would remove the breakpoint in TestB.doSomething()"
Sorry if I was unclear: the breakpoint is not IN the doSomething() method. It is in the main method which is CALLING the doSomething() method.
I couldn't find a Copy System Properties button, so I'll just do a regular copy/paste.
awt.toolkit sun.awt.windows.WToolkit
file.encoding Cp1252
file.encoding.pkg sun.io
file.separator \ java.awt.graphicsenv sun.awt.Win32GraphicsEnvironment
java.awt.printerjob sun.awt.windows.WPrinterJob
java.class.path C:\Documents and Settings\Jason\Desktop\Dr Java.exe;C:\Program Files\Java\jdk1.6.0\lib\tools.jar
java.class.version 50.0
java.endorsed.dirs C:\Program Files\Java\jre1.6.0\lib\endorsed
java.ext.dirs C:\Program Files\Java\jre1.6.0\lib\ext;C:\WINDOWS\Sun\Java\lib\ext
java.home C:\Program Files\Java\jre1.6.0
java.io.tmpdir C:\DOCUME~1\Jason\LOCALS~1\Temp\ java.library.path C:\Program Files\Java\jre1.6.0\bin;.;C:\WINDOWS\Sun\Java\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\PROGRA~1\GTK\bin;C:\WINDOWS\system32;C:\WINDOWS;C:\WINDOWS\System32\Wbem;C:\Program Files\Java\jdk1.6.0\bin;C:\Program Files\Java\jdk1.6.0\jre\lib\ext\;C:\Program Files\QuickTime\QTSystem\ java.rmi.server.hostname 127.0.0.1
java.runtime.name Java(TM) SE Runtime Environment
java.runtime.version 1.6.0-b105
java.specification.name Java Platform API Specification
java.specification.vendor Sun Microsystems Inc.
java.specification.version 1.6
java.vendor Sun Microsystems Inc.
java.vendor.url http://java.sun.com/
java.vendor.url.bug http://java.sun.com/cgi-bin/bugreport.cgi
java.version 1.6.0
java.vm.info mixed mode
java.vm.name Java HotSpot(TM) Client VM
java.vm.specification.name Java Virtual Machine Specification
java.vm.specification.vendor Sun Microsystems Inc.
java.vm.specification.version 1.0
java.vm.vendor Sun Microsystems Inc.
java.vm.version 1.6.0-b105
line.separator
os.arch x86
os.name Windows XP
os.version 5.1
path.separator ;
sun.arch.data.model 32
sun.boot.class.path C:\Program Files\Java\jre1.6.0\lib\resources.jar;C:\Program Files\Java\jre1.6.0\lib\rt.jar;C:\Program Files\Java\jre1.6.0\lib\sunrsasign.jar;C:\Program Files\Java\jre1.6.0\lib\jsse.jar;C:\Program Files\Java\jre1.6.0\lib\jce.jar;C:\Program Files\Java\jre1.6.0\lib\charsets.jar;C:\Program Files\Java\jre1.6.0\classes
sun.boot.library.path C:\Program Files\Java\jre1.6.0\bin
sun.cpu.endian little
sun.cpu.isalist
sun.desktop windows
sun.io.unicode.encoding UnicodeLittle
sun.java.launcher SUN_STANDARD
sun.jnu.encoding Cp1252
sun.management.compiler HotSpot Client Compiler
sun.os.patch.level Service Pack 2
user.country US
user.dir C:\Documents and Settings\Name
user.home C:\Documents and Settings\Name
user.language en
user.name Name
user.timezone America/New_York
user.variant
Logged In: YES
user_id=1683818
Originator: YES
Oh ya, its not in project mode.
Logged In: YES
user_id=666678
Originator: NO
Confirmed in r4223.
Logged In: YES
user_id=1075744
Originator: NO
After using YourKit, it looks like this is the place where DrJava deadlocks:
java.awt.EventQueue.invokeAndWait(Runnable)
edu.rice.cs.util.swing.Utilities.invokeAndWait(Runnable)
edu.rice.cs.drjava.model.AbstractGlobalModel.setActiveDocument(OpenDefinitionsDocument)
edu.rice.cs.drjava.model.AbstractGlobalModel.openFile(FileOpenSelector)
edu.rice.cs.drjava.model.AbstractGlobalModel.getDocumentForFile(File)
edu.rice.cs.drjava.model.debug.jpda.JPDADebugger.scrollToSource(Location, boolean)
edu.rice.cs.drjava.model.debug.jpda.JPDADebugger.scrollToSource(Location)
edu.rice.cs.drjava.model.debug.jpda.JPDADebugger._switchToSuspendedThread(boolean)
edu.rice.cs.drjava.model.debug.jpda.JPDADebugger._switchToSuspendedThread()
edu.rice.cs.drjava.model.debug.jpda.JPDADebugger.currThreadSuspended()
edu.rice.cs.drjava.model.debug.jpda.EventHandlerThread._handleStepEvent(StepEvent)
edu.rice.cs.drjava.model.debug.jpda.EventHandlerThread.handleEvent(Event)
edu.rice.cs.drjava.model.debug.jpda.EventHandlerThread.run()
Logged In: YES
user_id=1075744
Originator: NO
The interesting thing about the call to setActiveDocument is that here it is NOT happening in the event thread, so the invokeAndWait uses Java's original method, so the code gets put in the event queue. It looks like the event that is blocking the event queue is DebugPanel.updateData(). Somehow because it does not complete, the code from setActiveDocument never gets to run, and we have a deadlock.
Logged In: YES
user_id=1075744
Originator: NO
Fixed as of revision 4225.
The deadlock was a result of the debugger thread, already owning the lock of the debugger, asking the global model to open a file, so setActiveDocument put code on the event queue. When this code executed, the event thread tried to call a synchronized method of the debugger, but never managed to acquire it, because the debugger thread already owned it.
I changed the code to have the debugger thread "preload" a document every time a step is made, before claiming the debugger lock. This brings setActiveDocument into action and the document is opened if necessary. Then the debugger lock is claimed and the response to the step is made.
Logged In: YES
user_id=1683818
Originator: YES
I just downloaded the newest stable version and it was not fixed although it acted a little differently. Was your fix in version: 20070130-2255 or is it going to be in a later release?
Logged In: YES
user_id=1075744
Originator: NO
No, the fix is not in any released version yet. The most recent version was built January 30, 2007, as the name implies, the fix was made on March 13.
Logged In: YES
user_id=666678
Originator: NO
You can download r4225 at:
http://www.owlnet.rice.edu/~chrisw/drjava/