| [cdt-dev] Hang (?) while "Generating Markers" |
|
I hoping someone can help with a nasty bug I’m dealing
with... We have a customer that’s reporting an Eclipse/CDT
hang. Trying to debug the situation remotely has been frustrating. I’ve
scratched my head long enough (and bugged the customer enough with questions, fruitless
suggestions, etc.) that I thought I’d ask for help. I already
searched Bugzilla, but to no avail. Our customer has CDT 3.1.2. The customer has a project that is very large, e.g. there
are about 650 sub-directories under the project’s root directory, and
heaven knows how many files all totalled. After a “make” run, invoked via a target in the
Make Targets view, the Progress view hangs with “Building Targets.”
as the title and “Generating markers...” as the subtask
label. We asked the customer to send a QUIT signal to the JVM, and that got
us a stack trace during this (apparent) hang state: the most suspicious thread is: "Worker-3" prio=1 tid=0x082dcc30 nid=0x3afa
runnable [0xeefd5000..0xeefd5e30] at
java.io.FileInputStream.readBytes(Native Method) at
java.io.FileInputStream.read(Unknown Source) at
org.eclipse.cdt.internal.core.model.CModelManager.createBinaryFile(CModelManager.java:583) at
org.eclipse.cdt.internal.core.model.CModelManager.create(CModelManager.java:305) at
org.eclipse.cdt.internal.core.model.CModelManager.create(CModelManager.java:227) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.createElement(DeltaProcessor.java:92) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:458) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:477) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:477) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:477) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:477) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:477) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:477) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.traverseDelta(DeltaProcessor.java:477) at
org.eclipse.cdt.internal.core.model.DeltaProcessor.processResourceDelta(DeltaProcessor.java:439) at
org.eclipse.cdt.internal.core.model.CModelManager.resourceChanged(CModelManager.java:747) at
org.eclipse.core.internal.events.NotificationManager$2.run(NotificationManager.java:280) at
org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:37) at
org.eclipse.core.internal.events.NotificationManager.notify(NotificationManager.java:274) at
org.eclipse.core.internal.events.NotificationManager.broadcastChanges(NotificationManager.java:148) at
org.eclipse.core.internal.resources.Workspace.broadcastPostChange(Workspace.java:256) at
org.eclipse.core.internal.resources.Workspace.aboutToBuild(Workspace.java:187) at
org.eclipse.core.internal.resources.Project.build(Project.java:118) at
org.eclipse.cdt.make.internal.core.MakeTarget$1.run(MakeTarget.java:315) at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737) at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719) at
org.eclipse.cdt.make.internal.core.MakeTarget.build(MakeTarget.java:326) at
org.eclipse.cdt.make.ui.TargetBuild$2.run(TargetBuild.java:95) at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1737) at
org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1719) at
org.eclipse.cdt.make.ui.TargetBuild$1.run(TargetBuild.java:98) at
org.eclipse.core.internal.jobs.Worker.run(Worker.java:58) The other threads don’t look problematic; in
particular, the “main” thread looks like it’s waiting for the
above “Worker-3” to complete: "main" prio=1 tid=0x0805d598 nid=0x3ae5 in
Object.wait() [0xffff9000..0xffffab98] at
java.lang.Object.wait(Native Method) - waiting on
<0x5edf9640> (a org.eclipse.core.internal.jobs.ThreadJob) at
org.eclipse.core.internal.jobs.ThreadJob.joinRun(ThreadJob.java:182) - locked
<0x5edf9640> (a org.eclipse.core.internal.jobs.ThreadJob) at
org.eclipse.core.internal.jobs.ImplicitJobs.begin(ImplicitJobs.java:87) at
org.eclipse.core.internal.jobs.JobManager.beginRule(JobManager.java:219)
: The deep “traverseDelta” recursion seems to
indicate it’s deep in the project tree, and “createBinaryFile”
makes it look like the project’s Binary Parser (ELF) is reading a
particular file. I’m assuming the “read[Bytes]” calls
wouldn’t block indefinitely (?). So this makes me think it’s not a “hang”,
but an in-progress, deep traversal of the project directories. I’ve
already asked the customer to let it run for a while, but he reported that it
was still hung after 20 minutes. Is there some bug with these symptoms that I’m not
aware of ? P.S. We found some archived
email with similar symptoms. Our customer does include *.d files in
the project. But why would that matter? Do those files add to the
list that are opened and read by the Elf Parser? That might add to the traversal’s
work, but shouldn’t cause a hang, right? Thanks in advance, Rich Rich
Wagner, Senior Software Development Engineer Tilera
Corporation |