Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
RE: [cdt-dev] Created make targets not saved to .cproject

FWIW, we randomly experience problems with the CDT project description
handling as well. My gut feeling is telling me this is also due to the
fact that for each thread a separate instance of the data object is
available (which IMO is not the right way to go anyway - what about
synchronizing???). I can imagine, that merging this back and forth
between threads is a nightmare (unless the last one processed wins
anyway;-), and so could be rewriting this stuff...

IMO all this is very tricky to both understand and to extend without
breaking anything, and I doubt it can be fixed easily (I just found one
location in our code where we did workarounds for some deadlock problem
in CDT at least five times and everytime we update CDT we have to find
yet another - even better, sometimes old workarounds which were outdated
meanwhile suddenly became valid again).


> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Achim Bursian
> Sent: Montag, 28. Juli 2008 13:04
> To: CDT General developers list.
> Subject: 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$ line: 39   
> 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
> >
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx

Back to the top