Community
Participate
Working Groups
Created attachment 276782 [details] Quick Type Hierarchy Stacktrace I recently set up a new workspace and decided to give the new index a try. It works mostly great, but I consistently and reproducibly run into a deadlock when trying to show a type hierarchy, both through "Quick Type Hierarchy" and through "Open Type Hierarchy". I can recover by cancelling the action in the UI, through the progress view (for "Open Type Hierarchy") or through the progress indicator in the status area (for "Quick Type Hierarchy") - although that indicator vanishes after a bit, and then I'm stuck with an unrecoverable busy cursor. The stack traces in both cases look similar, see attachments. In both cases, a CreateTypeHierarchyOperation is performed, which ultimately hangs in Indexer.waitForIndex. I can't see any suspicious activity on other threads, or anything else holding a lock though. The same scenario works fine with the old index.
Created attachment 276783 [details] Show Type Hierarchy Stacktrace
Hm, I just tried connecting with a debugger to see who might be holding the log, and now I consistently get the following upon workbench start: java.lang.IllegalStateException: Generic signature starts with unknown character: ( ^ *)Lorg/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper; at org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter.countMethodArguments(ClassFileToIndexConverter.java:650) Not sure if that might leave the index in a deadlockable state. But I've had that deadlock for some time now, and prior to today, the workspace would start up without showing any index errors.
(In reply to Carsten Reckord from comment #2) > java.lang.IllegalStateException: Generic signature starts with unknown > character: ( ^ *)Lorg/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper; > at > org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter. > countMethodArguments(ClassFileToIndexConverter.java:650) How was that classfile created, ecj (version?) or javac? If ecj, please file a separate bug for this issue. TIA. (does the signature in the message really contain spaces, or is this an artifact of copy-paste to bz?)
The deadlock remotely reminds me of bug 513872. When you saw the IllegalStateException, was the indexer visible somewhere in that call stack?
(In reply to Stephan Herrmann from comment #3) > How was that classfile created, ecj (version?) or javac? It's a class from my target platform, so I would assume ecj. It's from the org.eclipse.fx.osgi_3.5.0.201811300600.jar bundle coming from http://download.eclipse.org/efxclipse/runtime-nightly/site. Looking at the bundle qualifier, that could also explain why I didn't see the IllegalStateException before today... > (does the signature in the message really contain spaces, or is this an > artifact of copy-paste to bz?) It really contains spaces. > When you saw the IllegalStateException, was the indexer visible somewhere in > that call stack? Yes, it's coming from the indexer. The full error log entry was: !ENTRY org.eclipse.core.jobs 4 0 2018-11-30 17:13:36.875 !MESSAGE Updating Java index !SUBENTRY 1 org.eclipse.core.jobs 4 2 2018-11-30 17:13:36.875 !MESSAGE An internal error occurred during: "Updating Java index". !STACK 0 java.lang.IllegalStateException: Generic signature starts with unknown character: ( ^ *)Lorg/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper; at org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter.countMethodArguments(ClassFileToIndexConverter.java:650) at org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter.addMethod(ClassFileToIndexConverter.java:350) at org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter.addType(ClassFileToIndexConverter.java:219) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.addClassToIndex(Indexer.java:853) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.addElement(Indexer.java:784) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.rescanArchive(Indexer.java:640) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.rescan(Indexer.java:287) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.lambda$0(Indexer.java:149) at org.eclipse.core.runtime.jobs.Job$2.run(Job.java:185) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63)
Thanks, I secured the class files, the closest I could come to the above is ModuleLayerWrapper.class, which contains: private static org.eclipse.fx.osgi.fxloader.jpms.ModuleWrapper lambda$1(?); descriptor: (Ljava/lang/Object;)Lorg/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper; flags: ACC_PRIVATE, ACC_STATIC, ACC_SYNTHETIC Code: stack=3, locals=1, args_size=1 0: new #90 // class org/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper 3: dup 4: aload_0 5: invokespecial #185 // Method org/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper."<init>":(Ljava/lang/Object;)V 8: areturn LineNumberTable: line 111: 0 LocalVariableTable: Start Length Slot Name Signature 0 9 0 o Ljava/lang/Object; Signature: #117 // (*)Lorg/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper; Clearly the signature does not contain the "( ^ *)" garbage. Next, I checked where the signature comes from, which is: org.eclipse.jdt.internal.core.nd.indexer.GenericSignatures.getGenericSignature(IBinaryMethod), which suggests that the bogus signature may be an artifact of the new index itself. I'm stopping my investigation at this point. To get you going again I suggest you try to re-build the index.
*** Bug 541771 has been marked as a duplicate of this bug. ***
FWIW I am getting this after eclipse -clean -refresh !ENTRY org.eclipse.core.jobs 4 0 2019-04-12 13:26:28.936 !MESSAGE Updating Java index !SUBENTRY 1 org.eclipse.core.jobs 4 2 2019-04-12 13:26:28.936 !MESSAGE An internal error occurred during: "Updating Java index". !STACK 0 java.lang.IllegalStateException: Generic signature starts with unknown character: ( ^ *)Lorg/eclipse/fx/osgi/fxloader/jpms/ModuleWrapper; at org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter.countMethodArguments(ClassFileToIndexConverter.java:650) at org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter.addMethod(ClassFileToIndexConverter.java:350) at org.eclipse.jdt.internal.core.nd.indexer.ClassFileToIndexConverter.addType(ClassFileToIndexConverter.java:219) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.addClassToIndex(Indexer.java:853) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.addElement(Indexer.java:784) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.rescanArchive(Indexer.java:640) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.rescan(Indexer.java:287) at org.eclipse.jdt.internal.core.nd.indexer.Indexer.lambda$0(Indexer.java:149) at org.eclipse.core.runtime.jobs.Job$2.run(Job.java:185) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:63) This is with 2019-03. Since it looks like it's the same class that the OP had, perhaps it's something related to efxclipse extension itself?
People observing this problem should be interested in bug 544898 (after which this current bug most likely will go the way of WONTFIX).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
See bug 515496 and bug 572978, the new index was removed.
