Community
Participate
Working Groups
Build Identifier: 3.6.1.r361_v20100909 There are two problems. The first one is causing this NPE: java.lang.NullPointerException at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.ScannerInfoConsoleParserUtility.findFile(Unknown Source) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.GCCScannerInfoConsoleParser.processCommand(Unknown Source) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.AbstractGCCBOPConsoleParser.processSingleLine(Unknown Source) at org.eclipse.cdt.make.internal.core.scannerconfig.gnu.AbstractGCCBOPConsoleParser.processLine(Unknown Source) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.processLine(Unknown Source) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer.access$0(Unknown Source) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.checkLine(Unknown Source) at org.eclipse.cdt.internal.core.ConsoleOutputSniffer$ConsoleOutputStream.close(Unknown Source) at org.eclipse.ptp.internal.rdt.core.remotemake.RemoteProcessClosure$ReaderThread.close(Unknown Source) at org.eclipse.ptp.internal.rdt.core.remotemake.RemoteProcessClosure.isAlive(Unknown Source) at org.eclipse.ptp.rdt.core.remotemake.RemoteCommandLauncher.waitAndRead(Unknown Source) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.invokeMake(Unknown Source) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.invokeBuilder(Unknown Source) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(Unknown Source) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(Unknown Source) at org.eclipse.cdt.managedbuilder.internal.core.CommonBuilder.build(Unknown Source) at org.eclipse.core.internal.events.BuildManager$2.run(Unknown Source) at org.eclipse.core.runtime.SafeRunner.run(Unknown Source) at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown Source) at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown Source) at org.eclipse.core.internal.events.BuildManager$1.run(Unknown Source) at org.eclipse.core.runtime.SafeRunner.run(Unknown Source) at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown Source) at org.eclipse.core.internal.events.BuildManager.basicBuild(Unknown Source) at org.eclipse.core.internal.events.BuildManager.build(Unknown Source) at org.eclipse.core.internal.resources.Project$1.run(Unknown Source) at org.eclipse.core.internal.resources.Workspace.run(Unknown Source) at org.eclipse.core.internal.resources.Project.internalBuild(Unknown Source) at org.eclipse.core.internal.resources.Project.build(Unknown Source) at org.eclipse.ui.actions.BuildAction.invokeOperation(Unknown Source) at org.eclipse.ui.actions.WorkspaceAction.execute(Unknown Source) at org.eclipse.ui.actions.WorkspaceAction$2.runInWorkspace(Unknown Source) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(Unknown Source) at org.eclipse.core.internal.jobs.Worker.run(Unknown Source) This line in ScannerInfoConsoleParserUtility is causing it: String foundLocation = file.getLocation().toString(); I switched getLocation getLocationURI and that seems to have solved the NPE since this will now work with remote paths. The second problem is when you have relative paths such as ../includethisfolder It never passes the foundLocation.endsWith(..) statement. Removing the "../" from the path seems to work, but is this going to break something else? Reproducible: Always
Created attachment 201006 [details] Fixes NPE and relative path problem
Hi Andrew. Would you be able to review this patch? Thanks
(In reply to comment #2) > Hi Andrew. Would you be able to review this patch? Thanks Can you attach a patch which can actually be applied in eclipse? There are unrelated changes in .gitignore but even if I exclude those I still cannot apply the patch.
(In reply to comment #3) > (In reply to comment #2) > > Hi Andrew. Would you be able to review this patch? Thanks > Can you attach a patch which can actually be applied in eclipse? There are > unrelated changes in .gitignore but even if I exclude those I still cannot > apply the patch. Hi Andrew, that patch should be for the 7.0 branch I believe. If that doesn't work I'll try to get a new one up here ASAP.
Supposedly there is a problem with "build/" prefix in build/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make. Where did it come from?
Created attachment 201184 [details] Fixes NPE and relative path problem (2nd upload)
I uploaded a new patch. I'm not sure where that build prefix comes from. Just set ignore leading path segments to 2 when you apply the patch. (In reply to comment #5) > Supposedly there is a problem with "build/" prefix in > build/org.eclipse.cdt.make.core/src/org/eclipse/cdt/make. Where did it come > from?
(In reply to comment #7) > I uploaded a new patch. I'm not sure where that build prefix comes from. Just > set ignore leading path segments to 2 when you apply the patch. That did not work on the first patch, the wizard gives only choice of 0 and 1 for leading segments. Probably related to having .gitignore in the patch. I can apply the new patch just fine, thanks. (In reply to comment #0) > I switched getLocation getLocationURI and that seems to have solved the NPE since this will now work with remote paths. That should be OK. > The second problem is when you have relative paths such as ../includethisfolder It never passes the foundLocation.endsWith(..) statement. Removing the "../" from the path seems to work, but is this going to break something else? Well, in your patch you remove *all* leading segments, not only "..". That is not OK because you want paths like "Folder1/Folder2/file.c" match with the whole folders chain and not to match Folder6/file.c. Additionally it is possible that output would contain something like "xxx/../Folder1/Folder2/file.c" so you want to collapse the path. You can do it creating IPath with "new Path(fileName)". But you'll still need to remove leading segments like ".." or ".", Path does not do that.
Can you also put your real name in Bugzilla? I can see it from the patch but it would be nice of you to reveal it in Bugzilla as well.
(In reply to comment #9) > Can you also put your real name in Bugzilla? I can see it from the patch but it > would be nice of you to reveal it in Bugzilla as well. If I collapse the path "somefolder/.././Folder1/Folder2/file.c" it will become "somefolder/Folder1/Folder2/file.c" Won't this get stuck returning null, since fileName may no longer be a suffix of foundLocation? "if (!foundLocation.endsWith(fileName)) {" Regarding name change, please let me know where I can update that and my email address as well. Thanks Michael
(In reply to comment #10) > (In reply to comment #9) > If I collapse the path > "somefolder/.././Folder1/Folder2/file.c" > it will become > "somefolder/Folder1/Folder2/file.c" > Won't this get stuck returning null, since fileName may no longer be a suffix of > foundLocation? > "if (!foundLocation.endsWith(fileName)) {" If you collapse the path using 'new Path("somefolder/.././Folder1/Folder2/file.c") it will become "Folder1/Folder2/file.c". Path will collapse using path rules and accounting for "..". Except it cannot handle of course if your path starts with ".." to begin with. > Regarding name change, please let me know where I can update that and my email > address as well. In bugzilla. Go to https://bugs.eclipse.org/bugs/userprefs.cgi?tab=account , login and you can change your name and email address in "Name and Password" tab.
Created attachment 201322 [details] Fixes NPE and relative path problem (3rd upload, 2nd revision)
Hi Andrew, please see the latest patch. It will deal with the special case when the path starts with "..". Let me know if it can be committed. Thanks. (In reply to comment #11) > (In reply to comment #10) > > (In reply to comment #9) > > If I collapse the path > > "somefolder/.././Folder1/Folder2/file.c" > > it will become > > "somefolder/Folder1/Folder2/file.c" > > Won't this get stuck returning null, since fileName may no longer be a suffix of > > foundLocation? > > "if (!foundLocation.endsWith(fileName)) {" > If you collapse the path using 'new > Path("somefolder/.././Folder1/Folder2/file.c") it will become > "Folder1/Folder2/file.c". Path will collapse using path rules and accounting > for "..". Except it cannot handle of course if your path starts with ".." to > begin with. > > > Regarding name change, please let me know where I can update that and my email > > address as well. > In bugzilla. Go to https://bugs.eclipse.org/bugs/userprefs.cgi?tab=account , > login and you can change your name and email address in "Name and Password" > tab.
(In reply to comment #13) > Hi Andrew, please see the latest patch. It will deal with the special case when > the path starts with "..". Let me know if it can be committed. Thanks. Thanks for the patch. Pushed to cdt_7_0, cdt_8_0 and master. Please, doublecheck that it is working as expected on all branches.
*** cdt git genie on behalf of Michael Lindo *** bug 354042: Problem with include paths that are relative paths starting with ../ or./ and NPE [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=6dd117ec5e0dc130d2f78dc5c285834ca33ae39c
*** cdt git genie on behalf of Michael Lindo *** bug 354042: Problem with include paths that are relative paths starting with ../ or./ and NPE [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=ac8574515bf178709504b87d8b4fc500da0dcb47
*** cdt git genie on behalf of Michael Lindo *** bug 354042: Problem with include paths that are relative paths starting with ../ or./ and NPE [*] http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/commit/?id=c1da6bdd847755b917acb933bb3e5ce9874198f0
