Community
Participate
Working Groups
If I click show MPI artifacts for an MPI application in a remote project which contains MPI function calls, I get a popup telling me no MPI artifacts were found. The application includes mpi.h and mpi.h is not flagged as missing in the source code editor window. MPI flyover help and MPI function auto completion are working. If I look in the .metadata/.log file, I see the following error message related to MPI artifacts !ENTRY org.eclipse.ptp.pldt.common 4 4 2011-06-10 12:33:58.546 !MESSAGE RunAnalyseHandlerBase.getAST(): Error getting AST (from index) for project rmt3
Confirmed on Windows 7 as well If you turn on PLDT tracing as described in http://help.eclipse.org/helios/index.jsp?topic=/org.eclipse.ptp.pldt.help/html/tracing.html it also gives similar info
I get same error (Eek!) on Linux too.
upping priority
Happening on Mac (now?) too, doesn't seem OS-specific RunAnalyseMPIcommandHandler.doArtifactAnalysis(ITranslationUnit, List<String>) line: 65 the call to getAST(translationUnit) is throwing an IllegalArgumentException? running on remote shallow project, main.c file (probably not related to specific file)
I have confirmed this doesn't work NOW in my RC1 build. Strange. It *does* work in an old 4.0.6 build.
It works in M6 but not M7, in all the scenarios i am testing today.
Did this work for remote projects in the past and then stop working? Or is only being seen now when trying MPI with a remote project? The way RDT works every feature that uses the parser or index needs to be remote enabled which is not a simple process.
Yes it worked before - in fact try it in PTP 4.0 if you want an example of it working. The PTP code hasn't changed. Yes Chris had told me that it won't be very efficient this way - because every file is pulled to the local system before being analyzed... but i was willing to live with that for the initial implementation. But even that seems to have stopped working now. Something changed in Eclipse3.7/CDT8.0/PTP5.0 between M6 and M7.
Well I have tracked it down to: org.eclipse.cdt.internal.core.parser.scanner.FileCharArray public static AbstractCharArray create(String fileName, String charSet, InputStream in) throws IOException { // no support for non-local files if (!(in instanceof FileInputStream)) { return null; } Sure enough, the InputStream arg is a ByteArrayInputStream, not a FileInputStream. Note the comment on the first line of the method. :) Then when it returns it tries to create a public InternalFileContent(String filePath, AbstractCharArray content) throws IllegalArgumentException { if (content == null) { throw new IllegalArgumentException(); } and the 'content' arg is indeed null. Stack at this point is: Daemon Thread [ModalContext] (Suspended) FileCharArray.create(String, String, InputStream) line: 37 InternalParserUtil.createFileContent(String, String, InputStream) line: 227 InternalParserUtil.createWorkspaceFileContent(IFile) line: 161 FileContent.create(IFile) line: 83 FileContent.create(ITranslationUnit) line: 67 TranslationUnit.getAST(IIndex, int, IProgressMonitor) line: 779 TranslationUnit.getAST(IIndex, int) line: 768 RunAnalyseMPIcommandHandler(RunAnalyseHandlerBase).getAST(ITranslationUnit) line: 528 RunAnalyseMPIcommandHandler.doArtifactAnalysis(ITranslationUnit, List<String>) line: 65 RunAnalyseMPIcommandHandler(RunAnalyseHandlerBase).analyse(IProgressMonitor, ITranslationUnit, List<String>) line: 151 RunAnalyseMPIcommandHandler(RunAnalyseHandlerBase).runResource(IProgressMonitor, ICElement, int, List<String>) line: 417 RunAnalyseMPIcommandHandler(RunAnalyseHandlerBase).runResources(IProgressMonitor, int, List<String>) line: 635 RunAnalyseHandlerBase$1.execute(IProgressMonitor) line: 310 WorkspaceModifyOperation$1.run(IProgressMonitor) line: 106 Workspace.run(IWorkspaceRunnable, ISchedulingRule, int, IProgressMonitor) line: 2344 RunAnalyseHandlerBase$1(WorkspaceModifyOperation).run(IProgressMonitor) line: 118 ModalContext$ModalContextThread.run() line: 121 Any ideas? The file with the "// no support for non-local files" comment hasn't changed since 8/25/10, and this worked at 3.7-M6 in mid-March but not in M7. Any ideas of a work-around for now?
The place in the CDT code where the old and new code diverges is in TranslationUnit.getLocation() (commit comment on 4/28/11 for TranslationUnit.java: Bug 343437: Support for UNC include directories, by Greg Watson (commit by mschorn) in the old getLocation(), it returned a null location for a remote file, so the caller (FileContent.create()) used a different method to create the FileContent object public static FileContent create(ITranslationUnit tu) { IPath location= tu.getLocation(); // CDT before the 4/28 changes returned a null location here if (location == null) return create(tu.getElementName(), tu.getContents()); // ... so this gets returned instead in previous CDT, and it worked for remote files if (tu.isWorkingCopy()) { return create(location.toOSString(), tu.getContents()); } IResource res= tu.getResource(); if (res instanceof IFile) { return create((IFile) res); } return createForExternalFileLocation(location.toOSString()); } in the new code, InternalParserUtil.createFileContent() line 225 calls FileCharArray.create(path,charset,inputstream) But this method ONLY handles a FileInputStream and the inputstream is a ByteArrayInputStream. so it returns null when we have a remote file. I wonder if there's another way to effectively call getAST() so that another type of object gets passed down to CDT, something it will still munch on properly... (if I force 'location' in the above method to be null, the rest finishes and I find my remote artifacts)
The way I'm calling getAST is in RunAnalyseHandlerBase.getAST() as follows protected IASTTranslationUnit getAST(ITranslationUnit tu) { IIndex index = CCorePlugin.getIndexManager().getIndex(tu.getCProject()); IASTTranslationUnit ast = tu.getAST(index, ITranslationUnit.AST_SKIP_ALL_HEADERS); // throw err on remote code now return ast;
Change for UNC support is here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=343437
Fix in https://bugs.eclipse.org/bugs/show_bug.cgi?id=349730 makes remote artifacts work correctly. (Local artifacts still work too)
What's the status of getting the fix from https://bugs.eclipse.org/bugs/show_bug.cgi?id=343437 from a build so I can bundle and test it with our plugins? Where are the new CDT builds since transition to git/hudson, is perhaps what I'm asking.
(In reply to comment #15) > What's the status of getting the fix from > https://bugs.eclipse.org/bugs/show_bug.cgi?id=343437 > from a build so I can bundle and test it with our plugins? > Where are the new CDT builds since transition to git/hudson, is perhaps what > I'm asking. Even if they fix the problem, I don't think the solution is correct for this bug. This means that you would be copying every file to the local machine so that it can be accessed by the local parser. Is that really what you want to be doing?
>copying every file to the local machine so that it can be accessed by the local parser. Well while not very desirable, this is effectively how it worked before. I will investigate whether doing the remote cdt jar thing should be invested in, or if larger projects doing static analysis will tend to do synchronized projects. I just wanted the function to work like it did before, albeit not very scalable for large projects.
Correction: the blocker for this is https://bugs.eclipse.org/bugs/show_bug.cgi?id=349730 (Non-local files cause InvalidArgumentException) instead of the original UNC fix which introduced the problem for local files (343437)
This is fixed using a recent CDT build; I tested with 8/25 build which should be in SR1 RC2.
