Community
Participate
Working Groups
After about the 2nd or 3rd time doing a save after starting Eclipse, I notice that automatic builds only happen every other time that I do a save. So, if I make a change to a CU, and save, an automatic build occurs. If I then make a change to the same or another CU (regardless of whether in the same project), a build does not occur. Making a third change to a CU (again, regardless of which one), causes a build to occur for both the second and third CU. I'm running RC1.
John, Could this be related to scheduling of builds? I don't see what we could have changed to break something like this.
I have no idea, but the "every other time" behavior seems to point at some type of flag that being analyzed whenever a change event occurs.
I cannot reproduce this in RC1, with either a trivial example or my own large workspace. Can you reproduce in a simple workspace? Any details in the error log? Are you running on a dual-processor or hyper-threaded machine?
Created attachment 11601 [details] Messages when automatic build fails after every other save
It'll take me a bit to get a chance to create a scaled-down workspace, but I can tell you I'm running on a single hyper-threading processor. And, yes, it turns out there are errors being logged when the build fails. I wish Eclipse would point out errors when they occur, at least by making the Error Log view active. Anyway, I've attached the log. Sorry I didn't notice it earlier.
Created attachment 11602 [details] Same log with new message after save & build works
If you come up with a fix for this, could you please send me a patch or make one available in this bug report. I think the errors in the log might also be the reason behind another defect I logged, bug 65728, that is much more serious. Thanks.
Check the "Activate on new events" option in the Error log view,
*** Bug 65752 has been marked as a duplicate of this bug. ***
Moving back to JDT. The logs shows that the build is failing due to an NPE inside the Java builder.
Kent, Could you please investigate how the binaryFolder can be null?
The field binaryFolder is only set in one place in the constructor. There are a couple of senders but each looks valid. We can add a check in ClasspathDirectory.equals() but I think we should first find out how this is happening. Please provide a testcase if you can.
So any chance that you can provide a testcase? Can you narrow it down to 1 project?
It happens on all projects. Are you asking me to create a separate workspace with some bogus projects and see if I can reproduce?
Sure... but I suspect it has something to do with your current workspace/projects. Can you build a new workspace with 1-2 of your smaller projects & reproduce it? If so, can you send us that workspace? If not, how big is your current workspace?
John: We have 2 days to fix this bug if its going into 3.0. We need a testcase so we can reproduce it. Do you have the time today to get us a reproduceable testcase?
We just finished testing of a release, so I should have time today to work on this. I'll make sure to update the report later today.
Unfortunately, I have thus far been unsuccessful scaling down my environment to a useful testcase. I'll keep working on it today...
Removing milestone. We cannot commit to fixing it since we still cannot reproduce it.
So let's start over... 1. How many projects do you have in your workspace? Do they used linked folders? Or sit outside of the 'normal' workspace directory structure? 2. How many team members are also experiencing the same problems as you? 3. Do you have any red X's attached to the projects? If so, what are the errors?
Sorry it's taken so long to reply to this, but we're at the end of a release, so my time has been constrained. 1) We have 290 projects in our workspace. None use linked folders or sit outside the normal folder structure. 2) Everyone in the office. However, it does now appear that may only be modifications to certain projects that cause the problem. We're currently trying to track down whether it's specific to changing code in projects that export other non-binary projects. 3) Before the modifications, no projects have red X's, but afterwards, about a third of them get marked with red X's with corresponding error messages indicating the projects can't be built because a prerequisite needs to be rebuilt. Chasing the prerequisite chain of errors down eventually leads to a project needing to be rebuilt for no apparent reason - In other words, it has no red X's next to it.
Do you have any cycles in your projects? Can you please change the filter settings in the Problems view to 'Any resource in the same project', then select the problem project to double check that it doesn't have any build errors.
As far as I can tell, we have no cycles in any of the projects, and definitely not in what we're guessing is the "problem" project. I've already checked for errors within each individual project, and other than the prerequisite problems that show up for this project and many others after making a change to this project, no other errors exist.
First of all, let me clarify my earlier "Everyone in the office" comment: We have about 30 people at my location. My latest findings are after the problem starts occuring, if I start eliminating projects and code from my workspace, I can eventually get down to only two projects left, one depending on the other, that have a minimal state (See attachment) and I still see the problem. If I remove either the source folder from the com.metamatrix.core project or remove the manifest dependency on that project from the com.metamatrix.modeler.core project, the problem disappears. Adding either back will cause the problem to reappear. However, once down to this level, if I exit Eclipse and restart, I can no longer reproduce the problem. I mentioned this is bug 65728 that I referred to before, but just to clarify our environment: Although we're running the 3.0 RC1 - RC3 versions of Eclipse currently, we have all of the Eclipse plug-ins from 2.1.1 in our workspace as projects since our product currently only runs on that version, and consequently have the Preferences->Target Platform->Location field pointing at an Eclipse 2.1.1 installation.
Created attachment 12830 [details] Minimal workspace Oops! Forgot to add the attachment.
Accidentally set severity to "Enhancement". Changed back to "Critical".
Moving to PDE based on comment #24. Wassim: Can you please double check his setup...
Not sure why this was moved to PDE, as it is clearly not a PDE issue. But I tried to reproduce the problem anyways, given the attachment in comment #25. However, said attachment does not contain source code, so I am not sure how the scenario is supposed to be reproduced. Moving back to JDT/Core to continue the discussion or resolve.
It was moved to PDE so you could verify that his setup as described in comment #24 works. If he has not supplied enough info for you, then ask him for more. Maybe if you had a testsuite which showed that this works, we wouldn't need to verify that it does. ;)
Just because comment #24 contains the words 'Target' and 'Platform' does not necessarily make it a PDE defect. In any event, targetting a 2.1.x platform is a pretty mainstream scenario which we do quite often (WSADIE team do it daily) and works just fine. So that is not the problem. Also the classpath of the two projects attached in comment #25, even though they have no source code, updates correctly. So no PDE issue here either. So the reporter's setup is fine. I am not sure why you suspect that said NPE in the Java builder above is caused by a PDE-related issue or the target platform. Let me assure that it is not.
John P. A., do you still have the problem ? If you do, do you have details on how to reproduce it ?
Yes, we still have the problem, but no, we have not been able to reproduce it in a smaller environement that doesn't contain our intellectual property. We've spent a couple of weeks trying to come up with something for you guys to work with, but with no success. While I can get down to only 2 projects in my workspace and still see the problem, these projects are not ones I can send. Plus, it appears that if I create a new workspace containing only these 2 projects, the problem goes away, even though creating a new workspace from scratch containing all of our projects still has the problem. The really strange part of this is that the problem only occurs when modifying a few particular projects (of the 300 in our workspaces). Don't suppose someone there would be willing to sign an NDA and come down for a visit?
This was just code inspection, but it looks like JavaSearchNameEnvironment.computeClasspathLocations can create a ClasspathDirectory instance with a null binaryFolder field (which caused the NPE). Here is the code: Object target = JavaModel.getTarget(workspaceRoot, path, false); if (root.getKind() == IPackageFragmentRoot.K_SOURCE) { cpLocations[index++] = new ClasspathSourceDirectory((IContainer)target); } else { cpLocations[index++] = ClasspathLocation.forBinaryFolder((IContainer) target, false, ((ClasspathEntry) root.getRawClasspathEntry()).getImportRestriction()); } The "target" object can be null since JavaModel.getTarget specifies that it can return null (and sometimes clearly does). This object is passed to ClasspathLocation.forBinaryFolder, which in turn constructs a ClasspathDirectory object. I'm not really familiar with this code, but it looks like the null case should be handled there. I also suggest adding an assertion to the ClasspathDirectory constructor to catch the null binaryFolder at creation time rather than at access time - that might help narrow down the cause.
The theory is that by iterating on package fragment roots, these should only correspond to existing entries, for which #getTarget should behave ok (return non null). This being said, some concurrency scenario could maybe cause a null to be returned until the roots got refreshed. Jerome - pls make the change, and also check other senders of #getTarget.
Added protection against null target in JavaSearchNameEnvironment.computeClasspathLocations. All other references to getTarget are fine. However JavaSearchNameEnvironment is used only during Java seach, not during Java building, so this cannot be what caused the NPE.
Looking at the code of 3.1 M4, no other instance of ClasspathDirectory with a null binaryFolder field can be created. So if this still happens with 3.1 M4, this must be a VM and/or JIT bug. Closing as we cannot do more.
