| Hi 
Andy,   The deadlock 
below is being worked on as we speak.  Please see:   As for using 
the timeout in query, I'm personally not aware of any reason 
why we shouldn't 
use it.  Choosing the right timeout should be done carefully 
though. That 
approach wasn't used when we started and that kind of became 
the 
pattern. We can start 
introducing such timeouts in different parts as needed. If you feel 
that would be helpful, you can file a bug.   Thanks   Marc 
 
  
  
  Some users report the debug session hangs the IDE. The stack trace is 
  copied below. At that stage, "gdb" hangs for some unknown reason (that will be 
  looked at separately), but the stack trace shows DSF GDB is waiting for gdb 
  infinitely and that hangs the main UI thread. 
 The 
  org.eclipse.cdt.dsf.gdb.internal.ui.actions.GdbConnectCommand.canConnect() 
  method sends the connect query using the 
  org.eclipse.cdt.dsf.concurrent.Query.get() method. The "get()" method is 
  blocked with no timeout. There is another "get(timeout, timeoutUnit)" method 
  but it is not used. 
 In fact, I see almost all DSF-GDB classes use the "get()" method, e.g. 
  GdbLaunchDelegate. In the case when gdb hangs, those methods will block. Is 
  there any reason we don't use the "get(timeout, timoutUnit)" method? 
 Thanks, Andy 
 |