[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
Re: [cdt-dev] Created make targets not saved to .cproject
|
Hi,
I think it's time for an update on this issue. I gathered some more
information, but I'm still desperate for some real help, guys.
I must confess, I got totally lost in the CDT code now, and can't find
my way out :-(
So, what's the deal? I tried to reproduce the whole problem in the
debugger on my PC, but I couldn't. Everything ran fine.
So I switched the the Sun workstation with Solaris 10 OS, which is where
we saw the problems. But even there, running in the debugger showed no
problem. Most of the time. Some times I had the bug again, but it was
not reliably reproducible.
So I used the most basic debugging tools: System.out.println... That
helped! I could reproduce the bug almost all the time, but only on the
Solaris machine, never on the PC.
What's actually going on? My code calls MakeTargetManager.addTarget().
With some steps in between (see stack below), that calls
CConfigBasedDescriptor.saveProjectData() which should save the new make
target to the .cproject file. But it does not, because in
CProjectDescriptionManager.setProjectDescription() there is this piece
of code:
if(((CProjectDescription)des).isLoadding()){
//do nothing
// throw
ExceptionFactory.createCoreException("description is being loadded");
return;
}
and more often than not I hit that return statement. So the isLoadding()
returned true. Why that? I don't know.
Obviously the project description is still in a loading state (but I
sdaw that even after a 15 second pause in the startup job), and in this
state it can't be written. Even worse, it seems to stay in that state
forever then. Even if I create a make target by hand later, it does not
get written to the file and is lost after Eclipse restart.
So this is a call for the experts now: How can I prevent this? Who has a
deeper understanding of that code and can help?
Can I test in any way that the project description is no longer in the
'loadding' state?
Please, please help. Thanks
Achim
This is the complete call stack when the isLoadding() condition returned
true:
Thread [Worker-3] (Suspended (breakpoint at line 1243 in
CProjectDescriptionManager))
CProjectDescriptionManager.setProjectDescription(IProject,
ICProjectDescription, int, IProgressMonitor) line: 1243
CProjectDescriptionManager.setProjectDescription(IProject,
ICProjectDescription, boolean, IProgressMonitor) line: 1220
CProjectDescriptionManager.setProjectDescription(IProject,
ICProjectDescription) line: 1213
CConfigBasedDescriptor.apply(boolean) line: 135
CConfigBasedDescriptor.checkApply() line: 142
CConfigBasedDescriptor.saveProjectData() line: 381
ProjectTargets.translateDocumentToCDTProject(Document) line: 289
ProjectTargets.saveTargets() line: 247
MakeTargetManager.writeTargets(ProjectTargets) line: 270
MakeTargetManager.addTarget(IContainer, IMakeTarget) line: 77
Maketargetbuilder.createMakeTargets(IContainer) line: 152
(Maketargetbuilder is my own class)
Maketargetbuilder.updateMakeTargets(ArrayList<IContainer>,
IProgressMonitor) line: 228
Maketargetbuilder.updateMakeTargets(IProgressMonitor) line: 211
Maketargetbuilder.access$0(Maketargetbuilder, IProgressMonitor)
line: 202
Maketargetbuilder$1.run(IProgressMonitor) line: 39
Worker.run() line: 55
Achim Bursian wrote:
Some more tests: It seems to be a startup timing problem. The problem
only occurs if initiated by the IStartup way. If I run it manually
with the popup menu, it always succeeds.
But once it is run by IStartup, any further popup menu actions show
the same problem -> CDT maketarget manager seems to be in an
inconsistent state now.
Once it even succeeded with the IStartup, but I could not reproduce it
next time. That shows me that the code is basically ok, just the
timing is not.
My conclusion: the CDT maketarget manager is in an instable state
during startup. It accepts the createTarget calls and shows them in
the GUI, but it does not save the state to disk. Then, after some
time, its startup completes. When adding a new maketarget in this
state, everything is fine and the state is persisted on disk.
So the main question for me is, how can I determine when the
maketarget manager is ready to process requests without problems?
Simply waiting for 2 seconds..? Not reliable. Any ideas?
-Achim