Community
Participate
Working Groups
I am using the latest build and inside a self-hosting workspace I checked out org.eclipse.jdt.ui. Sometimes (looks like a timing issue), I end up with empty external class file folders for the jdt.ui dependent plugins that we loaded in the workspace I used to start the self-hosting workspace. The end result of this is that API tooling is completely broken as it cannot initialize properly the api profiles used for the comparison and it ends up reporting lot of problems that don't really exist.
Sometimes when I close and reopen the project, the PDE container is then properly initialized. This doesn't work all the times. If I know where the external class file folders are populated, I might be able to debug the problem since I do get it regularly.
To debug it, see org.eclipse.jdt.internal.core.PackageFragmentRoot.computeFolderChildren(IContainer, boolean, String[], ArrayList, char[][], char[][]) The pkg fragment root should be an instance of ExternalPackageFragmentRoot.
Something is wrong since I never enter this method. I'll continue to investigate.
Created attachment 97345 [details] Logs These are two logs. classpath_init.txt is a log when the PDE container could not be properly initialized. classpath_init2.txt is the same log + all the logged event after the project was closed and reopened. After this, the PDE container was properly initialized. Hopefully this will help to track this down.
These 2 logs show that the container intialization was successful. The problem seems to be in the root's chidren calculation. I was expecting that you would hit computeFolderChildren(). But it looks like something went wrong before. So let's start at an earlier point. Can you please put a breakpoint in org.eclipse.jdt.internal.core.JavaElement.openWhenClosed(Object, IProgressMonitor) ? And activate this brekpoint for the external root only.
Is this still critical for 3.4 ?
This is critical when it happens. It would be nice to be able to reproduce this.
According to bugzilla's help, "critical" corresponds to "crashes, loss of data, severe memory leak". This bug doesn't correspond to this description of "critical". "major" seems more appropriate as it corresponds to "major loss of function". Lowering severity then. Also note that there is no other report of this bug, so it is going to be hard to debug as it looks like it is very specific to your setup. Maybe you can start Eclipse with the following VM argument: "-agentlib:jdwp=transport=dt_socket,suspend=n,server=y,address=51001" and contact me when it happens. I'll try to connect to your machine and debug it.
Olivier, does this still happen?
I am not using this setting right now.
Closing for now. Please reopen if you see it again.
Verified for 3.5M2 using I20080914-2000
