Community
Participate
Working Groups
Build: I20030813 I am getting an assertion failure during search. I am searching for references to a private field. Searching in hierarchy or in workspace causes the same assertion failure. Log file attached. Olivier: The assertion is in the constructor for jdt.internal.core.SourceType. If the assertion failure message included the name of the type, it would make debugging this case easier.
Created attachment 5765 [details] Log file showing stack trace
I changed the assertion call to report the name in the error message. Now it will look like this: The source type has an invalid name: {0} where {0} will be replaced by the argument name.
Would you have any steps to reproduce?
I can reproduce in my workspace every time, but not in a new workspace. I instrumented jdtcore.jar and ran it again in my workspace. The string passed to SourceType was ".##Workbench". The filename was ".#Workbench.java.1.85" These are the files that are created by CVS when you perform an update on a file with conflicts that can't be resolved automatically. The interesting thing to me is that I did "search in hierarchy", and this took almost a minute to complete. In this case the hierarchy involved three class (Object included), so clearly the search scope is broken. The .#Workbench file was in the same package, but definitely not in the hierarchy of the type I was searching.
It sounds like the .#Workbench.java file was indexed when it should not be. John do you still have your workspace? If you do, can you please zip it and give it to me?
I can still reproduce with build I20030820, but now I get a different error on the same search: java.lang.reflect.InvocationTargetException: java.lang.NullPointerException at java.lang.Throwable.<init>(Throwable.java) at java.lang.Throwable.<init>(Throwable.java) at java.lang.NullPointerException.<init>(NullPointerException.java:63) at org.eclipse.jdt.internal.compiler.parser.Scanner.setSource(Scanner.java) at org.eclipse.jdt.internal.compiler.parser.Parser.parse(Parser.java) at org.eclipse.jdt.internal.compiler.parser.Parser.dietParse(Parser.java) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.buildBindings(MatchLocator.java) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:594) at org.eclipse.jdt.internal.core.search.matching.MatchLocator.locateMatches(MatchLocator.java:681) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:499) at org.eclipse.jdt.core.search.SearchEngine.search(SearchEngine.java:426) at org.eclipse.jdt.internal.ui.search.JavaSearchOperation.execute(JavaSearchOperation.java:90) at org.eclipse.ui.actions.WorkspaceModifyOperation$1.run(WorkspaceModifyOperation.java:71) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1574) at org.eclipse.core.internal.resources.Workspace.run(Workspace.java:1591) at org.eclipse.ui.actions.WorkspaceModifyOperation.run(WorkspaceModifyOperation.java:85) at org.eclipse.jface.operation.ModalContext$ModalContextThread.run(ModalContext.java:101)
To reproduce in my workspace: 1) Open file UILockListener.java 2) Select the field "ui". 3) Search for references in hierarchy Again, I think it is interesting that this search takes over a minute even though there are only two types in the hierarchy.
Sorry John, but I cannot reproduce the problem. After starting your workspace, I refreshed all projects, and did the search to the field 'ui' in the hierarchy. I got 4 matches and no error/stack trace. As for the time it takes, search in hierarchy doesn't first compute the hierarchy (we found it was too costly in most cases). It finds potential matches in the workspace (actually in current project and its dependent projects only), resolve these potential matches and eliminate the ones that are not in the hierarchy. In your case, there are 4700 potential matches. These are because of the references to packages containing 'ui' (e.g. 'org.eclipse.ui'). We might want to optimize out those. I entered bug 41954.
Strange... it still happens for me every time (the NPE, not the original assertion failure). Could there be something that invalidates the indexes on moving from OTT->SNZ? Change of time zone could make the indexes appear to be out of sync, and thus get recomputed?? Would it help for Olivier to look at it locally?
To reproduce it, it might be good to remove the code that recomputes the indexes.
Even without recomputing the indexes, I don't get the NPE that John got. John, which VM are you using?
I'm using J9SC, build 20030714 (with -Xj9 VM arg).
Still no luck reproducing it with J9SC, build 20030714 . Could you please try to turn the search trace on? Add these lines to the .options file: org.eclipse.jdt.core/debug=true org.eclipse.jdt.core/debug/search=true
After upgrading to the M3 build I am no longer able to reproduce the failure...
Thanks. Please reopen if you see the problem again.
