This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
When running sunstudio I get the attached stack trace. Here is what I think happens: Look at OpenProject.actionPerformed, line 120. It's calling setMainProject(). Just above it the project is actually getting opened with "open asynchronously". So it's not surprising that when debuggercore comes back through jpda and cnd's actions providers that the asynchronously loaded project information might not be ready yet, causing an NPE. The NPE in CND happens because the following lookup returns a null: MakeConfiguration conf = (MakeConfiguration)getProjectDescriptor().getConfs ().getActive();
Created attachment 33348 [details] stacktrace
Created attachment 33349 [details] ascii stacktrace
So, this should be fixed in projects. We should not get ProjectActionPerformer.enable(Project) called with a project that is not fully set up.
The "open asynchronously" in fact means that the project will be opened in a different thread, but the "open" method should block until the project is opened - so it should not finish before the project is opened. Would it be possible to evaluate in CND why getProjectDescriptor().getConfs().getActive() returned null?
if you say so Jan about asynchronously, although it strikes me as rather strange than an action on the eventq would delegate to another thread and then do a wait. What would be the point? I'll pursue the null 'conf' a bit more. One reason I believed that it's a race is that eventually the data is not null.
Come on guys ... OpenProjectList.open() uses RP.post(new Runnable()() {
Sorry, the Return key submitted an incomplte comment. OpenProjectList.open() uses RP.post (... doOpen()) ... it is truly asynch. I put a bpt in the CND code and at the time it hit there was a thread servicing the project open: org/openide/util/RequestProcessor$Task.run(<Not compiled -g>) org/netbeans/modules/project/ui/OpenProjectList$1.run(<Not compiled -g>) org/netbeans/modules/project/ui/OpenProjectList.access$000(<Not compiled -g>) org/netbeans/modules/project/ui/OpenProjectList.doOpen(<Not compiled -g>) org/openide/util/Mutex.readAccess(<Not compiled -g>) org/openide/util/Mutex.doEventAccess(<Not compiled -g>) java/awt/EventQueue.invokeAndWait(<Not compiled -g>) java/lang/Object.wait(<Not compiled -g>) java/lang/Object.wait(<Not compiled -g>) ----------------------------------------------------------------- But there's more to it than that. Scenario: Existing open project 'Welcome'; Open new project 'X'. A bpt in org.netbeans.modules.cnd.makeproject.MakeActionProvider.isActionEnabled() gets hit multiple times. The first few times it accesses a MakeConfiguration from the project being switched away from: 'Welcome'. When it gets COMMAND_DEBUG_STEP_INTO the MakeConfiguration belongs to 'X', the newly created project. And the configuration set for this new project is empty. The reason for this discrepancy is that some calls to isActionEnabled() originate from this stack (before the project has truly switched: [1] org.netbeans.modules.cnd.makeproject.MakeActionProvider.isActionEnabled(this = <OBJECT>, command = "run", context = <OBJECT>) "MakeActionProvider.java":504 [2] org.netbeans.modules.project.ui.actions.ActionsUtil.commandSupported(--- Not compiled -g ---) "ActionsUtil.java":117 [3] org.netbeans.modules.project.ui.actions.MainProjectAction.refreshView(--- Not compiled -g ---) "MainProjectAction.java":138 [4] org.netbeans.modules.project.ui.actions.MainProjectAction.access$000(--- Not compiled -g ---) "MainProjectAction.java":51 [5] org.netbeans.modules.project.ui.actions.MainProjectAction.1.run(--- Not compiled -g ---) "MainProjectAction.java":120 [6] org.openide.util.Mutex.doEvent(--- Not compiled -g ---) "Mutex.java":1182 [7] org.openide.util.Mutex.readAccess(--- Not compiled -g ---) "Mutex.java":284 [8] org.netbeans.modules.project.ui.actions.MainProjectAction.propertyChange(--- Not compiled -g ---) "MainProjectAction.java":118 [9] org.openide.util.WeakListenerImpl.PropertyChange.propertyChange(--- Not compiled -g ---) "WeakListenerImpl.java":161 [10] java.beans.PropertyChangeSupport.firePropertyChange(--- Not compiled -g ---) "PropertyChangeSupport.java":333 [11] java.beans.PropertyChangeSupport.firePropertyChange(--- Not compiled -g ---) "PropertyChangeSupport.java":270 [12] org.netbeans.modules.project.ui.OpenProjectList.2.run(--- Not compiled -g ---) "OpenProjectList.java":317 [13] org.netbeans.modules.project.ui.OpenProjectList.2.run(--- Not compiled -g ---) "OpenProjectList.java":317 [14] org.openide.util.Mutex.1.run(--- Not compiled -g ---) "Mutex.java":1218 [15] java.awt.event.InvocationEvent.dispatch(--- Not compiled -g ---) "InvocationEvent.java":199 [16] java.awt.EventQueue.dispatchEvent(--- Not compiled -g ---) "EventQueue.java":461 [17] java.awt.EventDispatchThread.pumpOneEventForHierarchy(--- Not compiled -g ---) "EventDispatchThread.java":242 [18] java.awt.EventDispatchThread.pumpEventsForHierarchy(--- Not compiled -g ---) "EventDispatchThread.java":163 [19] java.awt.EventDispatchThread.pumpEventsForHierarchy(--- Not compiled -g ---) "EventDispatchThread.java":153 [20] java.awt.Dialog.1.run(--- Not compiled -g ---) "Dialog.java":515 [21] java.awt.Dialog.show(--- Not compiled -g ---) "Dialog.java":536 [22] java.awt.Component.show(--- Not compiled -g ---) "Component.java":1300 [23] java.awt.Component.setVisible(--- Not compiled -g ---) "Component.java":1253 =>[24] org.netbeans.modules.project.ui.OpenProjectList.open(--- Not compiled -g ---) "OpenProjectList.java":215 [25] org.netbeans.modules.project.ui.actions.OpenProject.actionPerformed(--- Not compiled -g ---) "OpenProject.java":114
Re What would be the point? (of asynchronous opening): the point is that the AWT is free to do repaints. Before this "asynchronous" opening, the opening was done in the AWT, meaning that the IDE did not repaint while the projects were being open (which may take several minutes in some cases). Now a dialog with progress is displayed and the IDE is repainted during opening projects. This progress is blocking to prevent problems (like race conditions). Actualy, this dialog itself serves as a lock that blocks the open method until the projects are opened. Re the last stack trace: although your line number do not exactly match those in my sources, it seems that at this time the project is fully opened - meaning: -its constructor has been called (means nothing in this particular case) -its OpenProjectHook has been called -it has been added into the list of opened projects The thing that (seemingly) happens here is that the OpenProjectList fires events that say that the list of opened projects and the list of recent projects have been changed (which is the very last step in the open sequence). I think that the CND project should be able to handle this situation.
On what would be the point? What I meant was what would be the point of waiting in the AWTQ, not what would be the point of farming off tasks to RP's. If it's a "soft" block in a progress dialog that makes sense. On the last stack trace. Of course it's a fully loaded project ... it's the original main project, not the one being opened and switched to. That stack trace perhaps more of interest to Martin to look at with the question: Why is action code being called at this time. Is it OK?
Problem resolved. There's no race condition. The configurations were indeed empty and the reason for that was that they had been clobbered with an experimental IDE with a buggy XMLCodec and I never double-checked the XML files on disk.