This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
Standalone j2se project, nothing to do with containers. from ant: clean: Deleting directory Y:\Property\Property_Client\dist Y:\Property\Property_Client\nbproject\build-impl.xml:626: Unable to delete file Y:\Property\Property_Client\dist\lib\activation.jar BUILD FAILED (total time: 1 second) nbproject\build-impl.xml: <!-- =============== CLEANUP SECTION =============== --> <target depends="init" name="deps-clean" unless="no.deps"> <ant antfile="${project.PropertyRegister_Client}/build.xml" inheritall="false" target="clean"/> </target> <target depends="init" name="-do-clean"> <delete dir="${build.dir}"/> 626 -> <delete dir="${dist.dir}"/> </target> $ handle.exe activation.jar Handle v3.2 Copyright (C) 1997-2006 Mark Russinovich Sysinternals - www.sysinternals.com java.exe pid: 3524 E30: C:\Soft\java\Netbeans-dev\java2\modules\ext\jaxws21\activation.jar java.exe pid: 3524 1C24: D:\_wc_codebase\FDT\KOT_Adapter\dist\lib\activation.jar java.exe pid: 3524 1D78: D:\_wc_codebase\Property\Property_Client\dist\lib\activation.jar Note that D:\_wc_codebase\ and Y: is same thing. There is only one instance of java.exe and that is nb (see screenshot). When doing clean project isnt currently running. But it was running and debugging before.
Created attachment 58540 [details] ant log
Created attachment 58541 [details] screenshot
Created attachment 58542 [details] ide log
ant issue?
Nothing to do with the Ant module, it is simply trying to delete a file as requested, and Windows claims there is an outstanding lock. While only a profiler could say for sure what in the JVM holds that file open, it looks to be the Java classpath scanner. It seems that dist/lib/activation.jar, a build product, is being indexed by the Java infrastructure as part of some larger classpath, but I am not sure what asked to include that in the classpath - normally dist/lib/*.jar other than your actual project JAR are simply copied to this dir as a convenience, but the IDE should not be referring to these JARs in any other way. You have just a single j2seproject? It looks like you maybe have two connected projects. You can get the NetBeans Project Metadata Inspector from the experimental update center, which would give a dump of interesting information about your project(s) incl. the classpaths they use. But I'm not sure that is the issue.
I have multiple projects open. There are libraries defined in nb for jar files in dist folders of some of these projects. Also some projects have dependencies on other projects. When doing ant clean&build ide doesnt do any visual scanning or compiling at the moment (it doesnt show usual progress at bottom right corner), cpu consumption is also zero. Also position in locked jar doesnt change (at least when you look it for minute).
Created attachment 59272 [details] ant log
Created attachment 59273 [details] ide log
Created attachment 59274 [details] metainformation
Created attachment 59275 [details] screenshot
Dtrace output: Process 1426 mapped file /Projects/JavaApplication1/dist/JavaApplication1.jar libc.so.1`mmap+0x15 libzip.so`0xd06c1b1c libzip.so`Java_java_util_zip_ZipFile_open+0x5d java/util/zip/ZipFile.open java/util/zip/ZipFile.<init> java/util/jar/JarFile.<init> java/util/jar/JarFile.<init> org/openide/filesystems/JarFileSystem.reOpenJarFile org/openide/filesystems/JarFileSystem.getEntry org/openide/filesystems/JarFileSystem.lastModified org/openide/filesystems/JarFileSystem$Impl.lastModified org/openide/filesystems/AbstractFileObject.initLastModified org/openide/filesystems/AbstractFileObject.lastModified org/openide/filesystems/AbstractFileObject.<init>
From Dtrace output: the dist.jar is mmaped by the NB ZipFileSystem and not unmapped.
I did more dtrace testing and it seems that jarfs closes the jar file but it is not unmapped by jdk.
"There are libraries defined in nb for jar files in dist folders of some of these projects." - that is likely your root problem. Or more specifically, that some of your projects include JARs from the dist/lib dir of other projects in their classpath (e.g. Y:\FDT\FDT_Client\src -> Y:\FDT\FDT_Common\dist\lib\commons-beanutils.jar). You should never create a library, or add a JAR classpath entry, from a build product; rather add the static original copy of the JAR. Besides problems with Windows locking, your current setup will cause much worse IDE performance during rebuilds.
This issue appeared after about 1000th hudson's build of netbeans. We started to use such scheme much much earlier and here were no problems. Netbeans doesnt (yet) provide confortable way to split large project into modules and inject 3rd party libraries into these modules (in contrast with IDEA for example) so that is only way by now.
To Jesse: The problem is reproduceable even for project to project dependency. Use case: 1) Create project A 2) Create project B 3) Set B depends on A 4) In the A create a bean Bean 5) Add the Bean into form in project B 6) A connot be cleaned
To unr303: Didn't you update a JDK while switching to build 1000?
*** Issue 131292 has been marked as a duplicate of this issue. ***
Increasing priority because of p2 duplicate.
Created attachment 59460 [details] dscript
Complete stack of mmap call: Process 1978 mapped file /Projects/JavaApplication1/dist/JavaApplication1.jar libc.so.1`mmap+0x15 libzip.so`0xd06c1b1c libzip.so`Java_java_util_zip_ZipFile_open+0x5d java/util/zip/ZipFile.open java/util/zip/ZipFile.<init> java/util/jar/JarFile.<init> java/util/jar/JarFile.<init> org/openide/filesystems/JarFileSystem.reOpenJarFile org/openide/filesystems/JarFileSystem.getEntry org/openide/filesystems/JarFileSystem.lastModified org/openide/filesystems/JarFileSystem$Impl.lastModified org/openide/filesystems/AbstractFileObject.initLastModified* org/openide/filesystems/AbstractFileObject.lastModified org/openide/filesystems/AbstractFileObject.<init> org/openide/filesystems/AbstractFileSystem.createFileObject org/openide/filesystems/AbstractFileObject.createFile org/openide/filesystems/AbstractFolder.getChild* org/openide/filesystems/AbstractFolder.getFileObject* org/netbeans/api/java/classpath/ClassPath.findPath org/netbeans/api/java/classpath/ClassPath.findResourceImpl org/netbeans/api/java/classpath/ClassPath.findResource org/netbeans/modules/form/project/ClassPathUtils.checkUserClass org/netbeans/modules/form/MetaComponentCreator.prepareClass0 org/netbeans/modules/form/MetaComponentCreator.access$800 org/netbeans/modules/form/MetaComponentCreator$4.run org/netbeans/modules/form/FormLAF$2.run org/openide/util/Mutex.doEventAccess org/openide/util/Mutex.readAccess org/netbeans/modules/form/FormLAF.executeWithLookAndFeel org/netbeans/modules/form/MetaComponentCreator.prepareClass Process 1978 closing non unmapped file /Projects/JavaApplication1/dist/JavaApplication1.jar The JarFS closes jar handler but there is still the mapped area (probably zip central table).
200803060007 -- Works. 200803071206 -- Fails. JDK 1.6.0_04-b12 WinXP
I cant swear but believe that jdk is same. 6u4 that we use now were installed like in start of year and problems started like few weeks ago.
Created attachment 59482 [details] Another d script
Here is the stack trace of open which is not closed: Process 3034 opened file: /Projects/JavaApplication1/dist/JavaApplication1.jar(227) libc.so.1`__open64+0x15 libc.so.1`open64+0x72 libhpi.so`sysOpen+0x3a libjvm.so`JVM_Open+0x3d libzip.so`Java_java_util_zip_ZipFile_open+0x95 java/util/zip/ZipFile.open(Ljava/lang/String;IJ)J java/util/zip/ZipFile.<init>(Ljava/io/File;I)V java/util/jar/JarFile.<init>(Ljava/io/File;ZI)V java/util/jar/JarFile.<init>(Ljava/io/File;)V org/openide/filesystems/JarFileSystem.reOpenJarFile()Ljava/util/jar/JarFile; org/openide/filesystems/JarFileSystem.getEntry(Ljava/lang/String;)Ljava/util/jar/JarEntry; org/openide/filesystems/JarFileSystem.lastModified(Ljava/lang/String;)Ljava/util/Date; org/openide/filesystems/JarFileSystem$Impl.lastModified(Ljava/lang/String;)Ljava/util/Date; org/openide/filesystems/AbstractFileObject.initLastModified(Z)Z org/openide/filesystems/AbstractFileObject.lastModified()Ljava/util/Date; org/openide/filesystems/AbstractFileObject.<init>(Lorg/openide/filesystems/AbstractFileSystem;Lorg/openide/filesystems/AbstractFileObject;Ljava/lang/String;)V org/openide/filesystems/AbstractFileSystem.createFileObject(Lorg/openide/filesystems/AbstractFileObject;Ljava/lang/String;)Lorg/openide/filesystems/AbstractFileObject; org/openide/filesystems/AbstractFileObject.createFile(Ljava/lang/String;)Lorg/openide/filesystems/AbstractFolder; org/openide/filesystems/AbstractFolder.getChild(Ljava/lang/String;Z)Lorg/openide/filesystems/AbstractFolder;* org/openide/filesystems/AbstractFolder.getFileObject(Ljava/lang/String;Ljava/lang/String;)Lorg/openide/filesystems/FileObject;* Seems as a problem of JarFS.
To tzezula: while there may well be some problem in JarFileSystem, if the test case you describe is reproducible, then there is a problem elsewhere anyway. If the bean's classpath is a/dist/a.jar, Retouche should be scanning a/src, never a/dist/a.jar itself. Or is the problem that the form editor loads classes from a.jar without closing it? If so, then the form editor should be fixed to not do so (e.g. by making a temporary delete-on-exit copy of a.jar).
To jglick: This issue has nothing in common with retouche, which doesn't touch the jar file at all. In this easy to reproduce case, form editor causes jar file to be opened, but it uses JarFs which should copy the content and close the jar file according to Radek, but starting from the build 07032008 the close is not done. The close of JarFS shouldn't be definitely handled by clients.
I see, I just missed that JarFS was already supposed to be doing the copy-for-read trick.
The dtrace native syscall trace is misleading, looking to JNI libzip, the Java_java_util_ZipFIle_ZIP_Open does caching of zip files, caches is controlled by reference counting. Adding pid provider to script for Java_java_util_ZipFIle_ZIP_Open and Zip_Close shows that the calls from JarFs are paired (the same number of zip open and close). In addition to this calls from JarFS there are calls (not logged by the syscall provider since they are served from cache, they increase the reference count) from form's ProjectClassLoader and NbClassLoader (used by ClassPath.getClassLoader). The problem is with NbClassLoader and is caused by the performance improvement, hg change set 69d433d564ba. The NbClassLoader extends URLClassLoader which uses sun.misc.URLClassPath which creates sun.misc.URLClassPath.Loader for each root. Before the change 9d433d564ba the URLCLassPath used directly the Loader which used URLConnection which correctly closes zip file, after the change the URLClassPath uses optimized JarLoader which doesn't do any closing. I suggest to change NbCLassLoader back to use jar file protocol => Loader rather than file protocol => JarLoader. I will add patch.
This should be fixed in 6.1, right?
Agreed, rising to P1. The bug fix tzezula mentioned was done by t_h - see issue 128978.
Fixed in: e247b9d03376
Can someone from qa test a build having the fix: http://deadlock.netbeans.org/hudson/job/trunk/1443/
Fixed in main e247b9d03376
verified according to issue 131292. dist directory is no more blocked tested on Product Version: NetBeans IDE Dev (Build 20080402105925) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Windows XP version 5.1 running on x86; Cp1252; en_GB (nb)
OK, I think
Integrated into NB 6.1: http://hg.netbeans.org/release61/rev/eea9f094eda5
verified on 6.1 rc1 Product Version: NetBeans IDE Dev (Build 200804040802) Java: 1.6.0_04; Java HotSpot(TM) Client VM 10.0-b19 System: Windows XP version 5.1 running on x86; Cp1252; en_GB (nb)
v.
This still happens!!!! Look at your mailing list subject 'Unable to rename old file to temporary file'!!!!!
To martinog: Nice, someone has changed (added) a code which doesn't close the zip file. For now you can use the build containing the fix only, it's http://bits.netbeans.org/6.1/nightly/2008-04-03_22-39-07/. I will spend another day finding the code non closing the zip file. In the unix there exists a simpe test using fuser for build 20080403 its' OK - fuser returns empty list for current build it returns IDE pid.
To martinog: Seems that the problem appears only on JDK 1.5 (at least on my setup), can you try to update to some newer version of JDK and try to reproduce this problem. Thanks
yes, I can confirm that testcase in desc17 is reproducible on WinXP, jdk 1.5.0, but when project is cleaned for the first time after step 5), any further clean&builds works
Update: The problem is not reproduceable on the JDK 6.0, only on the JDK 5.0. The situation with different builds I mentioned above is wrong, the older build was started on the JDK 6.0 and the newer on the JDK 5.0. Please update your JDK.