Community
Participate
Working Groups
Get few of "Cannot serialize @<some_number> (org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.FunctionSetType)" messages in the error log during indexing.
Is it SignatureBuilder (rather than TypeMarshalBuffer) that's trying to serialize the FunctionSetType? If so, this is probably a regression from the patch that introduced TypeInstantiationRequest (which calls SignatureBuilder.marshalType() in its hashCode()), similar to bug 510706.
(In reply to Nathan Ridge from comment #1) Not sure since I haven't tried to debug it.
(In reply to Sergey Prigogin from comment #2) > Not sure since I haven't tried to debug it. It should be clear from the second line of the exception's stack trace.
It is being logged without a stack trace.
It is logged from TypeMarshalBuffer. SignatureBuilder contains an assert but no logging. On a separate note the following code fragment in SignatureBuilder looks suspicious: } else if (type instanceof UniqueType) { // UniqueType is not an ISerializableType because there should never be // a need to write it to the index, but it can appear in a signature // during partial ordering of function templates. appendSeparator(); fBuffer.append("<UniqueType>"); //$NON-NLS-1$ Shouldn't the contribution of an unique type to a signature be unique?
(In reply to Sergey Prigogin from comment #5) > Shouldn't the contribution of an unique type to a signature be unique? Technically, yes. I just figured it would be very unlikely to ever get a nested type instantiation request with a *different* unique type. What could we write if we wanted it to be unique - an object address?
(In reply to Nathan Ridge from comment #6) > What could we write if we wanted it to be unique - an object address? I would do something like '@" + Integer.toHexString(System.identityHashCode(type))
(In reply to Sergey Prigogin from comment #7) > (In reply to Nathan Ridge from comment #6) > > What could we write if we wanted it to be unique - an object address? > > I would do something like '@" + > Integer.toHexString(System.identityHashCode(type)) Thanks, I posted a follow-up (bug 510706 comment 9) to do this.
Here is an example stack: Thread [Worker-8] (Suspended (breakpoint at line 138 in TypeMarshalBuffer)) TypeMarshalBuffer.marshalType(IType) line: 138 CPPPointerType.marshal(ITypeMarshalBuffer) line: 117 TypeMarshalBuffer.marshalType(IType) line: 132 TypeMarshalBuffer.marshalTemplateArgument(ICPPTemplateArgument) line: 226 PDOMCPPLinkage(PDOMLinkage).storeArgument(Database, long, ICPPTemplateArgument) line: 619 PDOMCPPLinkage(PDOMLinkage).storeTemplateArgument(long, ICPPTemplateArgument) line: 613 PDOMCPPTemplateParameterMap.storeArgument(Database, PDOMLinkage, long, ICPPTemplateArgument) line: 76 PDOMCPPTemplateParameterMap.putMap(PDOMNode, ICPPTemplateParameterMap) line: 61 PDOMCPPClassInstance(PDOMCPPSpecialization).storeTemplateParameterMap() line: 112 PDOMCPPLinkage$ConfigureInstance.run() line: 497 PDOMCPPLinkage.handlePostProcesses() line: 1207 PDOMCPPLinkage.addBinding(IASTName) line: 565 PDOMFile.createPDOMName(PDOMLinkage, IASTName, PDOMName) line: 515 PDOMFile.addNames(IASTName[][], YieldableIndexLock) line: 482 WritablePDOM.addFileContent(IIndexFragmentFile, IWritableIndex$IncludeInformation[], IASTPreprocessorStatement[], IASTName[][], ASTFilePathResolver, YieldableIndexLock) line: 154 WritableCIndex.setFileContent(IIndexFragmentFile, int, IWritableIndex$IncludeInformation[], IASTPreprocessorStatement[], IASTName[][], ASTFilePathResolver, YieldableIndexLock) line: 86 PDOMFastIndexerTask(PDOMWriter).storeFileInIndex(PDOMWriter$Data, PDOMWriter$FileInAST, int, YieldableIndexLock, IProgressMonitor) line: 637 PDOMFastIndexerTask(PDOMWriter).storeSymbolsInIndex(PDOMWriter$Data, int, PDOMWriter$FileContext, IProgressMonitor) line: 320 PDOMFastIndexerTask(PDOMWriter).addSymbols(PDOMWriter$Data, int, PDOMWriter$FileContext, IProgressMonitor) line: 279 PDOMFastIndexerTask(AbstractIndexerTask).writeToIndex(int, IASTTranslationUnit, FileContent, PDOMWriter$FileContext, IProgressMonitor) line: 1288 PDOMFastIndexerTask(AbstractIndexerTask).parseFile(Object, AbstractLanguage, IIndexFileLocation, IScannerInfo, PDOMWriter$FileContext, IProgressMonitor) line: 1098 PDOMFastIndexerTask(AbstractIndexerTask).parseLinkage(int, List<IIndexFileLocation>, IProgressMonitor) line: 897 PDOMFastIndexerTask(AbstractIndexerTask).runTask(IProgressMonitor) line: 558 PDOMFastIndexerTask(PDOMIndexerTask).run(IProgressMonitor) line: 161 PDOMRebuildTask.run(IProgressMonitor) line: 90 PDOMIndexerJob.run(IProgressMonitor) line: 155 Worker.run() line: 55
I am seeing this too. I don't have a reduced example right now, unfortunately.
I still don't have a reduced testcase, but I've been continuing to see this error pretty regularly. Thinking about it some more, I think that perhaps trying to serialize a FunctionSetType may be reasonable (since a FunctionSet can appear in an EvalFunctionSet inside an EvalFunctionCall, and we need to store dependent evaluations in the index as a matter of course), and we should just implement serialization for it.
(In reply to Nathan Ridge from comment #11) > Thinking about it some more, I think that perhaps trying to serialize a > FunctionSetType may be reasonable (since a FunctionSet can appear in an > EvalFunctionSet inside an EvalFunctionCall, and we need to store dependent > evaluations in the index as a matter of course), and we should just > implement serialization for it. I tried to use this theory to construct a testcase that triggers the problem, but wasn't able to. Even though EvalFunctionSet.getType() returns a FunctionSetType, serializing the EvalFunctionSet does not involve serializing its type. The only obvious ways I can think of an evaluation's type "escaping" to a context where it gets stored in the index, is if the evaluation is for a top-level expression that's inside a decltype, or gets passed to a function that captures its type, or something like that. However, we seem to take care not to allow the type of a top-level expression to be a FunctionSetType. So, without a testcase to help me understand why, I don't think FunctionSetType should be stored in the index, and making it serializable would just paper over an underlying problem that results in us trying, incorrectly, to store it in the index. So we're back to the drawing board, i.e. we need a reproducing testcase.
I have a similar entry in my error log during indexing: Cannot serialize @752786004 (org.eclipse.cdt.internal.core.dom.parser.cpp.semantics.FunctionSetType) exception stack trace is not available. Is there some logging I can activate to isolate the cause of the problem? Currently it happens when I rebuild the index for a project with several thousand source code files...
