| Suggestions for debugging the indexer? [message #1744325] |
Sun, 25 September 2016 13:00 |
 Scott Miller
Messages: 1
Registered: September 2016 |
Junior Member |
|
|
I'm trying to diagnose (and, hopefully, suggest a patch to fix) a problem with the indexer. For a complex project, the indexer seems to "forget" declarations that were indexed while reading .cpp files early in the index rebuild.
I've turned on the standard debugging output stuff; attached is an output snippet showing the results of an "Index Rebuild" for a small project (I've done a little spacing and indenting to aid in interpretation). Note that "TimeStamp.cpp" includes <string> (since I use some std::string objects in that file, but then, when "EventImpl.cpp" is processed, the indexer seems to have forgotten that it knows what a "basic_string" is. As you can see from the bottom of the output, there were 251 unresolved symbols.
This is a makefile project that compiles without error. And there are no unresolved includes associated with the project.
I can't rule out some error on my part (though I've reduced the scope of the code from 8 interrelated projects with scores of source files to one project with four source files to try to isolate the issue).
That said, it looks like the indexer is somehow "forgetting" about the basic_string declaration between source files.
I've set up a debugging version of the CDT java code, so I can step through it and add tracing statements to help figure out what's going on. But, being no java expert, I'm having some trouble making progress identifying the issue.
Questions:
1) Has anyone seen this behavior--i.e., declarations from system header files being read and "forgotten?"
2) One stumbling block I've hit is that I can't log elements of an object where the type is know at runtime without doing a giant switch block with "case x instanceof SomeSpecificClass" to test all of the possible actual class types (rather than an interface or generic base class). Is there a better way to get this output?
3) What guidance can those who've debugged (or written) the indexer code provide on how best to monitor what's going on? I'm mostly interested in monitoring when references are added to the index file, when they're removed (if they are individually deleted) and what happens when new code is read and the indexer tries to resolve a name. (Unfortunately, when name.resolveBinding() is called (I forget where, but can look it up), the binding type has already been set to "ProblemBinding". Anyway, I can step through the code (though it's awfully complicated without a roadmap as to what's going on and relatively few comments in the implementation code) as I have been. Or, I was thinking that it would be helpful to be able to "dump" the .pdom index file into some human-readable form. Is there such a utility? Does it make sense to write one?
|
|
|
Powered by
FUDForum. Page generated in 0.02948 seconds
] 
Search
Help
Register
Login
Home
