Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[cdt-dev] DSF executor thread consumes 100% cpu on terminate

    Hi list,

  I've got a lightly-customised DSF-GDB (based on Helios and CDT 7.0.0) and
I'm seeing very strange behaviour when I click on the terminate button: for
anywhere between 10 and 30 seconds, the DSF executor thread goes bananas,
spinning wildly and hogging 100% cpu.

  None of the other threads are doing anything during this period (according
to the JVM monitor), and the executor thread doesn't seem to be running
through any of Eclipse's own code: stack traces appear to all be contained
within java.util.concurrent, and show like:

(example #1)
java.util.concurrent.TimeUnit$1.convert(Unknown Source)
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.getDelay(Unknown
Source)
java.util.concurrent.DelayQueue.poll(Unknown Source)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(Unknown
Source)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(Unknown
Source)
java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

(example #2)
java.util.concurrent.locks.AbstractQueuedSynchronizer.release(Unknown Source)
java.util.concurrent.locks.ReentrantLock.unlock(Unknown Source)
java.util.concurrent.DelayQueue.poll(Unknown Source)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(Unknown
Source)
java.util.concurrent.ScheduledThreadPoolExecutor$DelayedWorkQueue.poll(Unknown
Source)
java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)

(example #3)
java.util.concurrent.locks.ReentrantLock.lock(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.workerCanExit(Unknown Source)
java.util.concurrent.ThreadPoolExecutor.getTask(Unknown Source)
java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
java.lang.Thread.run(Unknown Source)


  Turning on all the debugging I can find suggests that most of the
termination has taken place, and the thread is shutting down; immediately
after clicking terminate, I see:

984,312 DSF execution #639. Executor is (org.eclipse.cdt.dsf.gdb - 3)
	Executable detail:
		type = org.eclipse.cdt.dsf.debug.ui.actions.DsfCommandRunnable
		instance =
org.eclipse.cdt.dsf.gdb.internal.ui.actions.DsfTerminateCommand$2@196f58d
		submitted at:
org.eclipse.cdt.dsf.gdb.internal.ui.actions.DsfTerminateCommand.execute(DsfTerminateCommand.java:97)
org.eclipse.debug.internal.ui.commands.actions.DebugCommandService.executeCommand(DebugCommandService.java:221)
org.eclipse.debug.ui.actions.DebugCommandAction.execute(DebugCommandAction.java:118)

984,312 DSF execution #640. Executor is (org.eclipse.cdt.dsf.gdb - 3)
	Executable detail:
		type = org.eclipse.cdt.dsf.concurrent.DsfRunnable
		instance = org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$1@1d3156a
		submitted by #639 at:
org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl.queueCommand(AbstractMIControl.java:288)
org.eclipse.cdt.dsf.gdb.service.command.GDBControl.terminate(GDBControl.java:228)
org.eclipse.cdt.dsf.gdb.internal.ui.actions.DsfTerminateCommand$2.doExecute(DsfTerminateCommand.java:101)

984,328 DSF execution #641. Executor is (org.eclipse.cdt.dsf.gdb - 3)
	Executable detail:
		type = org.eclipse.cdt.dsf.concurrent.DsfRunnable
		instance =
org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread$1@98f1ef [MI
command output received for: -gdb-exit]
		submitted at:
org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.processMIOutput(AbstractMIControl.java:832)
org.eclipse.cdt.dsf.mi.service.command.AbstractMIControl$RxThread.run(AbstractMIControl.java:662)

984,328 Dispatching event MIProcesses$ContainerExitedDMEvent@134bfd3 to
session DsfSession@15933f8 from thread "org.eclipse.cdt.dsf.gdb - 3" (107)

   [ ... some executions snipped ... ]

984,328 DSF execution #648. Executor is (org.eclipse.cdt.dsf.gdb - 3)
	Executable detail:
		type = org.eclipse.cdt.dsf.concurrent.DsfRunnable
		instance = org.eclipse.cdt.dsf.service.DsfSession$3@14cab76 [Event:
org.eclipse.cdt.dsf.mi.service.MIProcesses$ContainerExitedDMEvent@134bfd3,
from service {objectClass=[Ljava.lang.String;@1ef37bb,
org.eclipse.cdt.dsf.service.IService.session_id=3}]
		submitted by #641 at:
org.eclipse.cdt.dsf.service.DsfSession.dispatchEvent(DsfSession.java:388)
org.eclipse.cdt.dsf.mi.service.command.MIInferiorProcess.setState(MIInferiorProcess.java:411)
org.eclipse.cdt.dsf.mi.service.command.MIInferiorProcess.commandDone(MIInferiorProcess.java:523)

984,328 Listener GDBControl@13e951f invoked with event
MIProcesses$ContainerExitedDMEvent@134bfd3
984,328 Listener GDBProcesses@1eb20cc invoked with event
MIProcesses$ContainerExitedDMEvent@134bfd3
984,328 Listener MIBreakpoints@bf209c invoked with event
MIProcesses$ContainerExitedDMEvent@134bfd3
984,328 Listener DsfSourceDisplayAdapter@2674e5 invoked with event
MIProcesses$ContainerExitedDMEvent@134bfd3
984,328 Listener GdbViewModelAdapter@89e919 invoked with event
MIProcesses$ContainerExitedDMEvent@134bfd3
984,328 Listener DisassemblyBackendDsf@6cb65f invoked with event
MIProcesses$ContainerExitedDMEvent@134bfd3

   [ ... some executions snipped ... ]

984,343 DSF execution #710. Executor is (org.eclipse.cdt.dsf.gdb - 3)
	Executable detail:
		type = org.eclipse.cdt.dsf.concurrent.DsfRunnable
		instance = org.eclipse.cdt.dsf.concurrent.RequestMonitor$2@1340071
[Completed: RequestMonitor
(org.eclipse.cdt.dsf.gdb.launching.GdbLaunch$5@1090ed2): Status OK: unknown
code=0 OK null]
		submitted by #709 at:
org.eclipse.cdt.dsf.concurrent.RequestMonitor.done(RequestMonitor.java:289)
org.eclipse.cdt.dsf.concurrent.Sequence.finish(Sequence.java:594)
org.eclipse.cdt.dsf.concurrent.Sequence.executeStep(Sequence.java:392)

984,343 GDBSimDSFLaunch@1065f47 removed as a service listener to
DsfSession@15933f8 (id=3)
984,343 Executor (org.eclipse.cdt.dsf.gdb - 3) is being shut down. Already
submitted tasks will be executed, new ones will not.

984,343 DSF execution #711. Executor is (org.eclipse.cdt.dsf.gdb - 3)
	Executable detail:
		type = org.eclipse.cdt.dsf.concurrent.DsfRunnable
		instance = org.eclipse.cdt.dsf.service.DsfSession$2@14e7f82
		submitted by #710 at:
org.eclipse.cdt.dsf.service.DsfSession.endSession(DsfSession.java:237)
org.eclipse.cdt.dsf.gdb.launching.GdbLaunch$5.handleCompleted(GdbLaunch.java:280)
org.eclipse.cdt.dsf.concurrent.RequestMonitor$2.run(RequestMonitor.java:291)



   At this point the thread starts hogging CPU, and doesn't stop until ....


000,953 DSF execution #712. Executor is (org.eclipse.cdt.dsf.gdb - 3)
	Executable detail:
		type = java.lang.Object
		instance = org.eclipse.cdt.dsf.gdb.service.GDBBackend$GDBProcessStep$3@a4b7e5
		submitted by #24 at:
org.eclipse.cdt.dsf.gdb.service.GDBBackend$GDBProcessStep.initialize(GDBBackend.java:552)
org.eclipse.cdt.dsf.gdb.service.command.GDBControl$InitializationShutdownStep.execute(GDBControl.java:491)
org.eclipse.cdt.dsf.concurrent.Sequence.executeStep(Sequence.java:443)


... after this execution runs.

  This behaviour happens with various versions of Java 1.6 up to and including
release 32.  Has anyone seen anything like this before, or has any ideas what
might be going wrong in java.util.concurrent?

    cheers,
      DaveK



Back to the top