RE: [cdt-dev] Created make targets not saved to .cproject

["Schaefer, Doug" <Doug.Schaefer@xxxxxxxxxxxxx>]

Yes, I'm very afraid to touch this stuff. We may end up creating more
problems than we're solving.

BTW, I'll be starting my e4 work on the platform resource model in a
week or so. One of the things I'd like to lump in with this is build and
solve both at the same time. I think we'll find a lot of the flexible
resource requirements we have are really flexible build requirements. We
should also store build information to avoid these kind of deadlocks.

Cheers,
Doug. 

> -----Original Message-----
> From: cdt-dev-bounces@xxxxxxxxxxx 
> [mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of Brunauer, Walter
> Sent: Monday, July 28, 2008 8:17 AM
> To: CDT General developers list.
> Subject: 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).
> 
> Walter
> 
> > -----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$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
> > >
> > _______________________________________________
> > cdt-dev mailing list
> > cdt-dev@xxxxxxxxxxx
> > https://dev.eclipse.org/mailman/listinfo/cdt-dev
> > 
> _______________________________________________
> cdt-dev mailing list
> cdt-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/cdt-dev
>