Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 186359 - IAE when opening a project
IAE when opening a project
Status: VERIFIED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
6.x
PC Linux
: P3 (vote)
: 7.0
Assigned To: Jaroslav Tulach
issues@platform
69patch1
:
: 186362 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-05-19 08:36 UTC by David Kaspar
Modified: 2010-06-21 13:33 UTC (History)
7 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description David Kaspar 2010-05-19 08:36:01 UTC
java.lang.IllegalArgumentException: Parameter file was not normalized. Was /.. instead of /
	at org.openide.filesystems.FileUtil.toFileObject(FileUtil.java:991)
	at org.openide.filesystems.FileUtil$Holder.locateCurrent(FileUtil.java:403)
	at org.openide.filesystems.FileUtil$Holder.<init>(FileUtil.java:396)
	at org.openide.filesystems.FileUtil.addFileChangeListener(FileUtil.java:274)
	at org.netbeans.api.java.classpath.ClassPath$RootsListener.addRoots(ClassPath.java:1111)
	at org.netbeans.api.java.classpath.ClassPath.createRoots(ClassPath.java:288)
	at org.netbeans.api.java.classpath.ClassPath.getRoots(ClassPath.java:263)
	at org.netbeans.api.javafx.source.ClassIndex.applyClassPaths(ClassIndex.java:216)
	at org.netbeans.api.javafx.source.ClasspathInfo.recalculateClassPaths(ClasspathInfo.java:286)
	at org.netbeans.api.javafx.source.ClasspathInfo.getFileManager(ClasspathInfo.java:175)
	at org.netbeans.api.javafx.source.JavaFXParserResult$Accessor.getFileManager(JavaFXParserResult.java:169)
	at org.netbeans.modules.javafx.source.indexing.JavaFXIndexer.createJavafxcTaskImpl(JavaFXIndexer.java:790)
	at org.netbeans.modules.javafx.source.indexing.JavaFXIndexer.index(JavaFXIndexer.java:701)
	at org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor$2.run(Indexable.java:172)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater.runIndexer(RepositoryUpdater.java:237)
	at org.netbeans.modules.parsing.spi.indexing.Indexable$MyAccessor.index(Indexable.java:170)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doIndex(RepositoryUpdater.java:1677)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.access$1200(RepositoryUpdater.java:1434)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$2.run(RepositoryUpdater.java:1603)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work$2.run(RepositoryUpdater.java:1601)
	at org.netbeans.modules.parsing.impl.indexing.errors.TaskCache.refreshTransaction(TaskCache.java:451)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.index(RepositoryUpdater.java:1601)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork.scanSource(RepositoryUpdater.java:3223)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$AbstractRootsWork.scanSources(RepositoryUpdater.java:3123)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$RootsWork.getDone(RepositoryUpdater.java:2872)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Work.doTheWork(RepositoryUpdater.java:2012)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task._run(RepositoryUpdater.java:3611)
	at org.netbeans.modules.parsing.impl.indexing.RepositoryUpdater$Task.run(RepositoryUpdater.java:3551)
	at org.netbeans.modules.parsing.impl.TaskProcessor$CompilationJob.run(TaskProcessor.java:584)
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
	at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:303)
	at java.util.concurrent.FutureTask.run(FutureTask.java:138)
	at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
[catch] at java.lang.Thread.run(Thread.java:619)
Comment 1 David Kaspar 2010-05-19 08:39:23 UTC
The same happens when expanding myProject/Libraries node in Projects window.

Probably related to the fact that the project is having library references by "../mylib.jar". Note the the jar is not located there.
Comment 2 David Kaspar 2010-05-19 09:46:40 UTC
Increasing to P2 since it is reproducible on various machines and affects the exchanging of JavaFX projects with relatively located libraries between users.
Comment 3 J Bachorik 2010-05-19 11:07:59 UTC
This seems as an issue inside org.netbeans.api.java.classpath.ClassPath.getRoots() method. Firstly I obtain the compile classpath by "ClassPath.getClassPath(fo, ClassPath.COMPILE);" and then I call "getRoots()" method on the obtained classpath.
I am not sure if I am supposed to normalize the paths inside the obtained classpath or if it should be the responsibility of org.netbeans.api.java.classpath.ClassPath class.
Please, evaluate and dispatch accordingly.
Comment 4 Tomas Zezula 2010-05-19 11:27:32 UTC
The ClassPath just takes the URL it got from the SPI (PathResourceImpl) and converts them into FileObjects + Files to use by FU.addFileChangeListener(). It does not do normalization as it will be expensive (all instances of CP will do it, the SPI is responsible to do it - it does it just once).
Who provides the ClassPathImplementation? JavaFX project?
Comment 5 J Bachorik 2010-05-19 11:45:16 UTC
*** Bug 186362 has been marked as a duplicate of this bug. ***
Comment 6 David Kaspar 2010-05-19 13:07:12 UTC
After debugging, we have discovered that the issue is in FileUtil.normalizeFile method.

When being on Linux machine, calling:
FileUtil.normalizeFile (new File ("/home/dave/NetBeansProject/ABCD/", "../../../../../XYZ"))
will return File with path:
"/../XYZ"

This is actually called from:
FileUtil.resolveFile(new File ("/home/dave/NetBeansProject/ABCD/"), "../../../../../XYZ");

May be related to:
FileUtil.normalizeFileOnUnixAlike method.
Comment 7 Jaroslav Tulach 2010-05-24 14:01:22 UTC
What do you think shall be the return value of 

FileUtil.normalizeFile (new File ("/home/dave/NetBeansProject/ABCD/",
"../../../../../XYZ"))

? I have a feeling returning "/../XYZ" is the best what the method can do. Are not you, by a chance, calling the method with wrong arguments?

I am closing as invalid, as (from platform/filesystems perspective), it is not at all clear what is wrong or what shall be done.
Comment 8 Tomas Zezula 2010-05-24 14:16:33 UTC
If the FileUtil.normalizeFile() is OK then FileUtil.addFileChangeListener () should not throw the IllegalArgumentException when such a normalized file is passed to it.
Comment 9 Jaroslav Tulach 2010-05-24 14:53:16 UTC
But the "../../../../../XYZ" is invalid! How can you go five times up when the you are in four directory deep directory?
Comment 10 Jesse Glick 2010-05-24 17:53:57 UTC
Based on comment #6, sounds like a bug in javafx code - creating a nonsensical file path.
Comment 11 Adam Sotona 2010-05-25 06:23:34 UTC
Could you, please, provide a reproducible case how to create a project referencing a library to located out of the file system (5 levels up in a 4 level deep project path)?
If the project has been moved, don't you experience a broken reference?
Is this a P2 priority issue if you operate with a project with broken references and receive some exceptions?
Comment 12 David Kaspar 2010-05-25 07:58:17 UTC
Here are reproducible steps:
1) Have a JavaFX project created on a Windows machine in a directory:
c:\documents and setttings\myuser\my documents\netbeans\mysampleproject
2) On the same machine, you have some libraries that you want to include in your project. They are located at:
c:\program files\sun\javadb\lib\derby.jar
3) Use your library into your project
4) Pack (using .zip) the project and send it to a friend.
5) The friend has a Linux and he extract the project into:
/tmp
folder.
6) When the project is opened from that location. It is opened with a broken-reference to the library. That's correct.
7) ERROR - but meanwhile there is an exception dialog shown the stack trace listed above.

Reopening the issue again.
Comment 13 Adam Sotona 2010-05-25 08:23:14 UTC
So the file path is invalid but it represents valid project state when moved to a new location.
None expects listen to such file and none expects that such file path can be normalized, but the exception should not be thrown.

I see five options:
- make the file path normalized anyway and do not produce /.. 
- throw an exception during the normalization (and catch it on all places where it can happen)
- ignore such case during the FileChangeListener registration (as the file is normalized - even it is wrong)
- detect such file before the FileChangeListener registration
- catch these IAEs around any call of the FileChangeListener registration 
 
But I see no way how can I help from the project classpath provider. The invalid file reference seems to be a valid use case.
Comment 14 Tomas Zezula 2010-05-25 10:07:03 UTC
I think the problem is in AntProjectHelper.resolveFile().
The user code does something like:

File root = theAntProjectHelper.resolveFile(thePropertyEvaluator.getProperty("path_property"))

When the property is relative and the path has more prents ("..") as there is in path to root of fs. The file like "/../XYZ" is created.
Comment 15 Jaroslav Tulach 2010-05-25 12:15:47 UTC
Guys, if you have a unit test not involving ClassPath API or project.ant API, feel free to assign to openide.filesystems. Until then, I don't want to disturb your argument with my defense. Assigning to ide meanwhile. Dispatch it as you want. I'll just have to add that without some isolated way to simulate the issue in openide.filesystems, I would close this as invalid from openide.filesystems point of view.
Comment 16 Marian Mirilovic 2010-05-25 12:30:53 UTC
reassign back to filesystems, just because this issue came from that place.

ide/Code is used just as temp for "don't know where to report issue" and not as a trash for all not yet decided or all issues we haven't found conclusion where/how to solve yet.
Comment 17 Tomas Zezula 2010-05-25 12:45:29 UTC
I will create a test later today.
I don't persist on filesystems.
If File ("/a/../../b") is invalid => bug in project.ant which creates such a file. If it's valid it's in filesystem. It depends on your decision. On Unix it's a valid path as "/.." == '"/".
Comment 18 Jaroslav Tulach 2010-05-25 13:31:00 UTC
filesystems are not trash either.
Comment 19 Jesse Glick 2010-05-25 14:20:36 UTC
Still undetermined where the fault lies. project.ant does call normalizeFile before returning any result from resolveFile, so even if the path is something useless like /../foo it should not trigger errors. ClassPath.RootsListener.addRoots is the immediate source of the unnormalized File; perhaps an assert could be added here.
Comment 20 Tomas Zezula 2010-05-25 14:59:27 UTC
The test is quite simple (has to be performed on Unix not Mac).

public void testWrongNormalization() throws Exception {
        final File file = new File ("/../../tmp/");
        final File normalizedFile = FileUtil.normalizeFile(file);
        FileUtil.addFileChangeListener(new FileChangeAdapter(){}, normalizedFile);
}
Comment 21 Tomas Zezula 2010-05-25 15:25:25 UTC
The problem is in in FileUtil.Holder.locateCurrent() which iterates over path = path.getParentFile() and asserts that path == FU.normalizeFile(path).
But normalizeFileOnUnixAlike() does
   
    if (file.getAbsolutePath().equals("/..")) { // NOI18N
            // Special treatment.
            file = new File("/"); // NOI18N
     }
   
so
FU.normalizeFile("/..") returns "/" which != "/.."
Comment 22 Jaroslav Tulach 2010-06-15 21:36:30 UTC
core-main#b41e6ddd0c01
Comment 23 Antonin Nebuzelsky 2010-06-16 11:57:00 UTC
A candidate for 6.9.1? Marking as such for now.

Is the fix safe and can it be verified working?
Comment 24 Quality Engineering 2010-06-17 03:17:34 UTC
Integrated into 'main-golden', will be available in build *201006170001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main/rev/b41e6ddd0c01
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #186359: /../tmp is /tmp
Comment 25 Petr Blaha 2010-06-17 11:51:42 UTC
verified
Comment 26 rbalada 2010-06-21 13:33:16 UTC
main #b41e6ddd0c01 transplanted to release691 #402488c699b8


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo