Community
Participate
Working Groups
Hello, I downloaded M4, but I can't start it. Eclipse throws the following exception: !SESSION ---------------------------------------------------------------------- !ENTRY org.eclipse.core.launcher 4 0 Oct 13, 2003 10:44:09.817 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Main.java:299) at org.eclipse.core.launcher.Main.run(Main.java:765) at org.eclipse.core.launcher.Main.main(Main.java:599) Caused by: java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.internal.boot.InternalBootLoader.startup(InternalBootLoader.java:1049) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:838) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) ... 7 more Caused by: org.eclipse.core.runtime.CoreException: Unable to create platform lock file: /home/mburger/temp/eclipse-workspace/.metadata/.lock. at org.eclipse.core.internal.runtime.InternalPlatform.createLockFile(InternalPlatform.java:225) at org.eclipse.core.internal.runtime.InternalPlatform.loaderStartup(InternalPlatform.java:677) ... 14 more The exception is contained in the .log file. Regards, Martin
Are you using a 1.4 JVM ? Use "java -version" to find out if not sure.
# java -version java version "1.4.2_01" Java(TM) 2 Runtime Environment, Standard Edition (build 1.4.2_01-b06) Java HotSpot(TM) Client VM (build 1.4.2_01-b06, mixed mode)
What OS are you running on? You can workaround this problem by preventing the lock file to be created (passing -Dorg.eclipse.core.runtime.ignoreLockFile as a VM arg): eclipse -vm \myvm\java -vmargs -Dorg.eclipse.core.runtime.ignoreLockFile
I mean, which Linux distro/version are you using?
# uname -a Linux XXXX 2.4.21-3-686 #1 Sun Jul 20 16:11:09 EST 2003 i686 GNU/Linux It's a Debian woody system.
It's possible you're trying to start eclipse with the workspace pointing to a location you don't have write access to? See the readme included with the build for instructions on running with a multi-user install. If running with "-data", it must point to a location that you have write access to.
#./eclipse -data /home/mburger/temp/eclipse-workspace Eclipse M4 failed to start, see exception. # ls -la /home/mburger/temp/ drwxr-xr-x 4 mburger users 4096 Oct 13 10:44 . drwx--x--x 59 mburger users 8192 Oct 14 14:11 .. drwxr-xr-x 3 mburger users 4096 Oct 13 10:44 eclipse-workspace The directory "eclipse-workspace" was created by Eclipse M4. # ls -la /home/mburger/temp/eclipse-workspace/ drwxr-xr-x 3 mburger users 4096 Oct 13 10:44 . drwxr-xr-x 4 mburger users 4096 Oct 13 10:44 .. drwxr-xr-x 2 mburger users 4096 Oct 13 10:44 .metadata ls -la /home/mburger/temp/eclipse-workspace/.metadata/ drwxr-xr-x 2 mburger users 4096 Oct 13 10:44 . drwxr-xr-x 3 mburger users 4096 Oct 13 10:44 .. -rw-r--r-- 1 mburger users 131 Oct 13 10:44 .cache.properties -rw-r--r-- 1 mburger users 0 Oct 13 10:44 .lock -rw-r--r-- 1 mburger users 1648 Oct 13 10:44 .log So, Eclipse M4 has created: /home/mburger/temp/eclipse-workspace/ /home/mburger/temp/eclipse-workspace/.metadata/ /home/mburger/temp/eclipse-workspace/.metadata/.lock I think the permissions are OK. Eclipse M4 was able to creat the lock, but then? Regards, Martin
*** Bug 44871 has been marked as a duplicate of this bug. ***
Upping severity. I suggest both of you try the workaround described in comment #3.
One problem here is that we are missing the IOException that is generated when we try to acquire the lock. Actually, we feed the exception to the Status object we create when throwing a CoreException. But in the launcher, we log the InvocationTargetException, what omits details about the original exception.
Created attachment 6431 [details] patched startup.jar This startup.jar contains a fix for the problem mentioned in comment 10 above. Could you guys replace the startup.jar that comes with M4 with this one and run Eclipse (*without* specyfing the property for ignoring the lock file)? It is located in the same directory as the eclipse executable. The problem will still happen, but at least we will have a better explanation for what can be causing it. Thanks.
Starting with the new startup.jar (https://bugs.eclipse.org/bugs/attachment.cgi?id=6431&action=view): !SESSION ---------------------------------------------------------------------- !ENTRY org.eclipse.core.launcher 4 0 Oct 16, 2003 09:48:45.807 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.internal.boot.InternalBootLoader.startup(InternalBootLoader.java:1049) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:838) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Unknown Source) at org.eclipse.core.launcher.Main.run(Unknown Source) at org.eclipse.core.launcher.Main.main(Unknown Source) Caused by: org.eclipse.core.runtime.CoreException: Unable to create platform lock file: /home/mburger/temp/eclipse-workspace/.metadata/.lock. at org.eclipse.core.internal.runtime.InternalPlatform.createLockFile(InternalPlatform.java:225) at org.eclipse.core.internal.runtime.InternalPlatform.loaderStartup(InternalPlatform.java:677) ... 14 more
This stack trace shows that in InternalBootLoader we also wrap the exception generated by the IPlatformRunnable's run method into a InvocationTargetException, thus the original IOException is still hidden.
Luckily, the boot loader prints the original stack trace to the console when that happens. Martin, you are launching Eclipse from KDE or Gnome, right? Could you run again but from a shell? That should allow you to see the original stack trace being dumped to the terminal window. ./eclipse -vm <JAVA_HOME>/jre/java -data ~/temp/eclipse-workspace Thanks again.
Sorry, but Eclipse does not print a stacktrace to the console, it writes to the .log: !SESSION ---------------------------------------------------------------------- !ENTRY org.eclipse.core.launcher 4 0 Oct 16, 2003 17:16:15.274 !MESSAGE Exception launching the Eclipse Platform: !STACK java.lang.reflect.InvocationTargetException at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.internal.boot.InternalBootLoader.startup(InternalBootLoader.java:1049) at org.eclipse.core.internal.boot.InternalBootLoader.run(InternalBootLoader.java:838) at org.eclipse.core.boot.BootLoader.run(BootLoader.java:461) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Unknown Source) at org.eclipse.core.launcher.Main.run(Unknown Source) at org.eclipse.core.launcher.Main.main(Unknown Source) Caused by: org.eclipse.core.runtime.CoreException: Unable to create platform lock file: /home/mburger/temp/eclipse-workspace/.metadata/.lock. at org.eclipse.core.internal.runtime.InternalPlatform.createLockFile(InternalPlatform.java:225) at org.eclipse.core.internal.runtime.InternalPlatform.loaderStartup(InternalPlatform.java:677) ... 14 more
Created attachment 6453 [details] patched boot.jar I fixed the BootLoader to always throw the nested exception instead of InvocationTargetExceptions. Martin, could you try to run with this version of org.eclipse.core.boot plugin JAR (just attached)? The location of the boot.jar is: <eclipse_install>/plugins/org.eclipse.core.boot_3.0.0/boot.jar This should cause the original IOException to be properly logged (inside a CoreException).
The are "No locks available". Perhaps because /home is mounted via nfs? I started Eclipse without a window manager, so I hope the exception is not affected by any side effects (I got "Error: Can't open display: someserver:0.0"). !SESSION ---------------------------------------------------------------------- !ENTRY org.eclipse.core.launcher 4 0 Oct 16, 2003 21:24:03.863 !MESSAGE Exception launching the Eclipse Platform: !STACK org.eclipse.core.runtime.CoreException[5]: java.io.IOException: No locks available at sun.nio.ch.FileChannelImpl.lock0(Native Method) at sun.nio.ch.FileChannelImpl.tryLock(FileChannelImpl.java:788) at java.nio.channels.FileChannel.tryLock(FileChannel.java:967) at org.eclipse.core.internal.runtime.PlatformMetaAreaLock.acquire(PlatformMetaAreaLock.java:27) at org.eclipse.core.internal.runtime.InternalPlatform.createLockFile(InternalPlatform.java:219) at org.eclipse.core.internal.runtime.InternalPlatform.loaderStartup(InternalPlatform.java:677) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.internal.boot.InternalBootLoader.startup(Unknown Source) at org.eclipse.core.internal.boot.InternalBootLoader.run(Unknown Source) at org.eclipse.core.boot.BootLoader.run(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at org.eclipse.core.launcher.Main.basicRun(Unknown Source) at org.eclipse.core.launcher.Main.run(Unknown Source) at org.eclipse.core.launcher.Main.main(Unknown Source)
Searching the web, I found this: http://www.uwsg.iu.edu/hypermail/linux/kernel/9906.3/0640.html It is likely a setup issue with NFS. If you cannot fix it, we suggest to specify the property mentioned above. The best we can do is to improve the error messages logged (see bug 45607). Thanks for helping tracking this down. Closing as invalid.
OK, starting from the machine (ssh -X nameOfMachine and so on) serving the nfs export, then it works fine, so it's a problem with nfs. Regards, Martin
Just to be clear: it works with NFS, provided your NFS configuration allows file locking (it works in my setup).
Actually, the bug mentioned in comment 18 is bug 45067.
*** Bug 44487 has been marked as a duplicate of this bug. ***
NOTE: This happens in SUSE Linux but not Red Hat. Another reason to use Red Hat!
Steve's Suse box surprisingly has lockd running. Asking for help from Infra to better understand the issue.
*** Bug 46603 has been marked as a duplicate of this bug. ***
Reopening to investigate cases where this happens even if the client seems to be properly configured. A test case in bug 44487 comment allows one to easily verify whether file locking on a NFS based location is working or not. As a reminder, there is an workaround described in comment 3.
The workaround described in comment #3 works. However I think it would be better to solve the problem rather than work around it. Here are some starting points: - SuSE 8.2 but running on standard (non-SuSE) kernel 2.4.22 - Java 1.4.2-b28 - NFS v3 asterix:/home/axel # cat /proc/mounts [...] gate:/home/axel /home/axel nfs rw,v3,rsize=8192,wsize=8192,soft,intr,udp,lock,addr=gate 0 0 I'm getting the same error logged as in comment #1. Opposite to the log entry the lock file is created. From this it should be obvious that this is not an issue of file permissions. The problem occurs, when Eclipse is started from KDE but also if you start it from a shell like this: axel@asterix:/apps/eclipse> ./eclipse -data /pub/tmp As soon as the workspace is located on a NFS drive, Eclipse won't start. I would be glad to help to sort out this problem :-)
As a note, I'm getting the same problem, but without using an NFS mount. I'm using kernel 2.4.22, with my mounted drive looking like: /dev/volume1/HomeDirectories on /home type ext3 (rw,nosuid,nodev,noatime) This is an ext3 partition mounted via LVM. Setting it to be rw,suid,dev,atime does not change the results.
*** Bug 46548 has been marked as a duplicate of this bug. ***
*** Bug 47777 has been marked as a duplicate of this bug. ***
Hi, I am new to Eclipse and had this problem when trying to run 3.0M5 with my workspace located on an exported NFS /home directory on SuSE 9.0. The problem is not exactly SuSE. It's more a combination of which NFS server you choose to run (userspace vs. kernel) and making sure lockd and statd are running on both the client and the server. With the SuSE distribution there are two different (conflicting) NFS rpms available to install: nfs-server-XXX.rpm (which contains the userspace NFS server), and the nfs-utils-XXX.rpm (which contains the kernel NFS server). Locking is not available in the userspace NFS server, so you need to uninstall nfs-server-XXX.rpm and install nfs-utils-XXX.rpm instead. That may not fix everything however. Statd may not be started on the NFS client automatically. Running the following line fixed it for me: # rcnfslock start Hope this helps with the NFS part of the bug anyway. --Peter
*** Bug 50612 has been marked as a duplicate of this bug. ***
*** Bug 50847 has been marked as a duplicate of this bug. ***
*** Bug 54526 has been marked as a duplicate of this bug. ***
*** Bug 55835 has been marked as a duplicate of this bug. ***
The interesting thing about bug 55835 (on a Netware-based remote file system) is that no I/O exception was thrown. FileChannel.tryLock just returned false, which we (correctly) interpret as a lock that has already been acquired by other process.
The option for lock support has changed (bug #55744) The org.eclipse.core.runtime.ignoreLockFile vmarg is now replaced by osgi.locking. This new property supports three values - none - java.io - java.nio If is picked but is not available it is defaulted to java.io.
When trying to start Eclipse 3.0 M8 i get Error in runtime; workspace cannot be set. Exiting. The workspace is set to a network drive on Novell Netware 6. Using Windows 2000 Advanced Server SP4 with Novell Client 4.90 SP1a, J2SDK build 1.4.2_01-b06, Eclipse 3.0 M8 Build id: 200403261517 -vmargs -Dorg.eclipse.core.runtime.ignoreLockFile fixes the problem.
Marking as wontfix since there isn't anything that we can do. Some file-systems and VMs just won't let us do locking properly. (for instance the HP-UX case) People who are having problems with a "non-standard" file-system and locking should ensure that no other users are currently running that workspace and then run with the System property to bypass the locking mechanism. Will add to README.
See bug 55744 comment 7 for the work-around. The default is to try java.nio locking if you are using a 1.4 VM.
*** Bug 58280 has been marked as a duplicate of this bug. ***
*** Bug 59517 has been marked as a duplicate of this bug. ***
>Marking as wontfix since there isn't anything that we can do. > >Some file-systems and VMs just won't let us do locking properly. (for instance >the HP-UX case) > >People who are having problems with a "non-standard" file-system and locking >should ensure that no other users are currently running that workspace and then >run with the System property to bypass the locking mechanism. > >Will add to README. Judging from the number of times people are running into this (and judging from the number of ways in particular a Linux-for-the-masses box may be configured) I wonder if the README and the command-line switch is the right approach. Furthermore, we can remind the user to read the README before calling the support hotline. Does something like the following work? 1. Catch the condition where lock is failing (Ideally separate that from the condition where the lock mechanism works but the workspace is actually locked. I have merged the two conditions below.) 2. Pop up a dialog: The specified workspace is in use or cannot be locked. [Choose another workspace (default)] [Unlock] [Disable Lock] 3. If the user clicks on "Unlock", try to manually remove the lockfile, then retry locking it. If this fails, return to #2. 4. If the user clicks on "Disable Lock", they get a confirmation dialog: "Are you sure? Locking the workspace is recommended in environments that support it, and you may be able to reconfigure your environment. Click Exit and review the README for advice on enabling locks in your environment." [OK] [Exit (the default)] 5. If the user clicks on "OK", Eclipse behaves as if the "ignoreLockFile" arg was specified.
Please open a feature request against Platform/UI with your comments above.
Bug 59780 raised to enhance recovery from this condition.
*** Bug 61200 has been marked as a duplicate of this bug. ***
These are related bugs from Sun's bug database (login required): http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4673298 http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4948095
*** Bug 69238 has been marked as a duplicate of this bug. ***
*** Bug 70458 has been marked as a duplicate of this bug. ***
I had the same problem with the home directory exported through nfs, and after some research I found that the bug was not on eclipse nor nfs (on my pc), but in the remote machine configuration. To solve this, I found the lockd was running but statd was not, and this statd is not automatically started by the kernel. So, I used the RPC portmapper's "rpc.statd" and "rpc.lockd" (both of them wont start if rpc.portmap is not started and the "rpc.lockd" wont start if lockd is already started), and after that the system is running fine. This solution was applied on a Intel P4 PC, everything is onboard and from intel (what is obvius, its a intel motherboard), using Slackware 10 as server and as client.
*** Bug 69212 has been marked as a duplicate of this bug. ***
I'm having the problems that the original poster had with regards to file locking. Setting the following option in my config.ini file fixes the problem: osgi.locking = java.io However, since I also do plug-in development I also launch another instance of Eclipse within Eclipse to test my plug-ins and this bug reoccurs! It's as if the config.ini settings are being ignored! Any ideas? Should I open a new bug? Thanks.
The second instance you run from inside Eclipse does not use the config.ini from your install. To avoid the problem here you have to set the property again using the VM arguments section in the corresponding launch configuration: -Dosgi.locking=none (or java.io, if you are on Windows)
*** Bug 82051 has been marked as a duplicate of this bug. ***
*** Bug 82201 has been marked as a duplicate of this bug. ***
*** Bug 84106 has been marked as a duplicate of this bug. ***
*** Bug 85522 has been marked as a duplicate of this bug. ***
related note: osgi.locking = java.io is also the remedy for the many many people experiencing hotspot crashes, especially on linux. maybe nio is not the best default for current sun JVMs...
*** Bug 87059 has been marked as a duplicate of this bug. ***
*** Bug 93312 has been marked as a duplicate of this bug. ***
*** Bug 94235 has been marked as a duplicate of this bug. ***
*** Bug 93919 has been marked as a duplicate of this bug. ***
Hello, I just want to add some comments. I just came from searching after the Eclipse error message. Unfortunately my documents are in a network drive which I do not control and I needed to put my eclipse workspace files there. One workaround that might be useful for some people (it is what I did) is: 1. create the workspace folder in the networked directory (say ~/workspace) 2. Create the metadata directory in the /tmp or any other writable dir on the current machine (say /tmp/metadataEclipse ) 3. Create a symbolic link called .metada to the metadata folder (say ln -s /tmp/metadataEclipse ~/workspace/.metadata ) Now you can use Eclipse saving your projects on your networking files (the reason I do that is that the networking storage is backed up automatically). Cheers, xtracto
*** Bug 133284 has been marked as a duplicate of this bug. ***
Let me try to bring some light into the problem of "workspace and configuration area locks". We (at Verigy) are facing similar problems as described in comment 17. At the end of this comment I would propose all-platform valid, working workaround solution for Eclipse 3.*, based on our findings. To understand this solution, here is "the full story" about Java and NFS file locks on Linux. According to our investigation, the problem seems to be specific for 2.4 32-bit Linux kernel on client and 64 bit NFS server (HPUX in our case). - We see the problem while running JDK 1.5.0_12 on RHEL3U7 32bit (2.4.21-52 kernel), I assume it will show on a lot of different Linux-versions with 2.4-kernel in 32bit. - The problem does NOT show on the 64bit version of RHEL3 client (2.4.21-40). - The problem does NOT show on the 32/64bit version of RHEL5 client (2.6.18-8) We have written demo programs to proof that the problem is the way how Java creates locks on Linux. ################ Java program to verify if the problem exists. It fails if lock could not be created ################ import java.io.File; import java.io.IOException; import java.io.RandomAccessFile; import java.nio.channels.FileLock; /** * Start with: java TestLock_nio %lock_path_to_test% */ public class TestLock_nio { public static void main(String[] args) throws Exception { File lockFile = new File(args[0]); if (!lockFile.exists()) { lockFile.createNewFile(); } boolean lock = lock(lockFile); if (!lock) { System.err.println("Could not create file lock: " + lockFile); } else { System.out.println("File lock created: " + lockFile + ", press any key to quit"); System.in.read(); } } /** * see org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio, * org.eclipse.update.internal.configurator.Locker_JavaNio */ public static boolean lock(File lockFile) throws IOException { RandomAccessFile raFile = new RandomAccessFile(lockFile, "rw"); try { FileLock fileLock = raFile.getChannel().tryLock(); if (fileLock != null) { return true; } } finally { raFile.close(); } return false; } } ################ "bad" C program which mimics the way how Java creates file locks ################ /**************** lockdemo.c *********************/ /* To compile:cc lockdemo.c -o lockdemo Try to establish a second lock, whilst the program is already holding a lock over the nfs share. If it hangs, then the lock has basically worked. Any other behavior would be abnormal. To fix the program, must compile with -D_LARGEFILE64_SOURCE option AND use right flock64 struct */ #include <stdio.h> #include <stdlib.h> #include <errno.h> #include <fcntl.h> #include <unistd.h> int main(int argc, char *argv[]) { /* l_type l_whence l_start l_len l_pid */ struct flock fl = { F_WRLCK, SEEK_SET, 0, 0, 0 }; // <---- problem!!! should be flock64 !!! int fd; fl.l_pid = getpid(); if (argc > 1) fl.l_type = F_WRLCK; if ((fd = open("lockdemo.c", O_RDWR)) == -1) { perror("open"); exit(1); } printf("Press <RETURN> to try to get lock: "); getchar(); printf("Trying to get lock..."); if (fcntl(fd, F_SETLKW64, &fl) == -1) { perror("fcntl"); exit(1); } printf("got lock\n"); printf("Press <RETURN> to release lock: "); getchar(); fl.l_type = F_UNLCK; /* set to unlock same region */ if (fcntl(fd, F_SETLK, &fl) == -1) { perror("fcntl"); exit(1); } printf("Unlocked.\n"); close(fd); } /****** END *************/ Now call strace -dffF -o /tmp/lockdemo.strace lockdemo and check this line: fcntl64(3, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=62663504129177486}, 0xbfff9330) = -1 ENOLCK (No locks available) This length is above the maximum size supported by HPUX !!! This would have been fixed by using the correct flock64 and correct flag on the compile of the program Changing the flock call to: struct flock64 fl = { F_WRLCK, SEEK_SET, 0, 0, 0 }; and compiling with D_LARGEFILE64_SOURCE flag fixes the problem: gcc -D_LARGEFILE64_SOURCE lockdemo.c -o lockdemo The program now executes correct: $ lockdemo Press <RETURN> to try to get lock: Trying to get lock...got lock Press <RETURN> to release lock: Unlocked. and we see this: fcntl64(3, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=0}, 0xbfffdbf0) = 0 Interestingly, the previous program didn't fail on 64 bit client/server because it is below maxfilesize: fcntl64(3, F_SETLKW64, {type=F_WRLCK, whence=SEEK_SET, start=0, len=12884931517}, 0xbf8839bc) = 0 but still the call is not correct: locking on the 64 bit client and server works, but the length should be "0". This again can be achieved by setting the correct flock structure and the correct compile options as shown above. Conclusion: For 32bit Linux OS client to lock at file using the 64bit calls the program needs to use the correct structure: struct flock64 and the program must be compiled with the option " -D_LARGEFILE64_SOURCE". All 64bit Linux OS will not need to be compiled with that option unless the program is using structure: struct flock64 the default: struct flock will lock just fine. This is not an HPUX nfs problem - it will always fail when flock for length is larger than the maximum supported file size in HPUX and we know is not initialized correctly on 32bit system when calling fcntl64 with the incorrect structure defined in the program and when compiling on 32bit we must use "-D_LARGEFILE64_SOURCE". There was many similar bugs, like http://bugs.sun.com/view_bug.do?bug_id=4673298 (open) http://bugs.sun.com/view_bug.do?bug_id=4762735 (open) http://bugs.sun.com/view_bug.do?bug_id=4948095 (closed, not fixed) http://bugs.sun.com/view_bug.do?bug_id=6174126 (closed, not fixed) According to the Sun engineers, which are currently looking closer on this problem: "FileChannel.lock() fails when the NFS server is a 64bit HPUX. The issue has been reported in #6628575". "Yes, we need to examine this issue for jdk7. As there is a potential compatibility issue it is unlikely that this can be fixed in a 5.0 or 6.0 update." It means, that this could take time to fix it in the JDK... But here is the simple program which demonstrates the current state and how easy we could fix it for Eclipse (this workaround is proposed by Sun engineer): all what we need is just replace fileLock = raf.getChannel().tryLock(); with FileChannel fc = raf.getChannel(); fileLock = channel.tryLock(0, fc.size(), false); in *two* places: org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio (for the workspace locking issue) and org.eclipse.update.internal.configurator.Locker_JavaNio (for the configuration area locking issue) ############## import java.io.File; import java.io.IOException; import java.io.RandomAccessFile; import java.nio.channels.FileChannel; import java.nio.channels.FileLock; /** * Start with: java TestLock2 %lock_path_to_test% * @see org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio * @see org.eclipse.update.internal.configurator.Locker_JavaNio * @author aloskuto */ public class TestLock2 { public static void main(String[] args) throws Exception { File lockFile = new File(args[0]); if (!lockFile.exists()) { lockFile.createNewFile(); } boolean lock = lock(lockFile); if (!lock) { System.err.println("Couldn't create file lock using NIO: " + lockFile); } else { System.out.println("Created file lock using using NIO: " + lockFile); } lock = lockFixed(lockFile); if (!lock) { System.err.println("Couldn't create file lock using fixed NIO: " + lockFile); } else { System.out.println("Created file lock using fixed NIO: " + lockFile); } } /** * <b>fixed</b> locking, basically the same as used by * 2 existing Locker_JavaNio implementations in Eclipse */ public static boolean lockFixed(File lockFile) throws IOException { RandomAccessFile raFile = new RandomAccessFile(lockFile, "rw"); FileLock fileLock = null; try { FileChannel channel = raFile.getChannel(); fileLock = channel.tryLock(0, channel.size(), false); } catch (IOException ioe) { ioe.printStackTrace(); return false; } finally { if(fileLock != null) { fileLock.release(); } raFile.close(); } if (fileLock != null) { return true; } return false; } /** * similar to 2 existing Locker_JavaNio implementations in Eclipse */ public static boolean lock(File lockFile) throws IOException { RandomAccessFile raFile = new RandomAccessFile(lockFile, "rw"); FileLock fileLock = null; try { fileLock = raFile.getChannel().tryLock(); } catch (IOException ioe) { ioe.printStackTrace(); return false; } finally { if(fileLock != null) { fileLock.release(); } raFile.close(); } if (fileLock != null) { return true; } return false; } } I've tested this small program with Sun JDK 1.5.0_12 on Windows, (good) Linux without NFS problem and (bad one) with described NFS problem. The "fixed" part of the program works in all 3 environments, the "old" one fails as expected on "bad" Linux client. Could you please now reopen & fix this bug, as the working solution exists? I hope we could see the proposed fix for both Locker_JavaNio's classes in the 3.3.2 and 3.4. Regards, Andrei Loskutov
Just for the record, here is the (now public) sun bug: http://bugs.sun.com/view_bug.do?bug_id=6628575
Created attachment 83850 [details] Patch for org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio adaptor.Locker_JavaNio patch against 1.6 version (3.3.1.1)
Created attachment 83851 [details] 2nd patch for org.eclipse.core.runtime.internal.adaptor.Locker_JavaNio adaptor.Locker_JavaNio patch against 1.6 version (3.3.1.1), *including* the change in 1.7 version
Created attachment 83852 [details] Patch for org.eclipse.update.internal.configurator.Locker_JavaNio configurator.Locker_JavaNio patch against 1.6 version (3.3.1.1)
Is there anybody from Platform-Resources team who may reopen this bug and apply the patches above to the 3.3.* and 3.4 streams??? At least a comment on this??? Currently we are patching Eclipse jar's in 3.2 and 3.3 versions, but our hope is that it would be fixed some days by Eclipse itself...
Reopening
Tom, see comment #66. Not sure if you're already aware of this...
(In reply to comment #73) > Tom, see comment #66. Not sure if you're already aware of this... > Sorry, I did not see this bug until it was reassigned to Equinox. Thanks for all the hard work and great explanation Andrei. I will review the fix and hopefully release it for 3.4 M4. I opened a separate bug 211060 to release the fix to update.
Any chance to get the fix into the 3.3.1+ (3.3.2) stream?
Created attachment 83862 [details] update patch against HEAD Updated patch for org.eclipse.osgi against HEAD. Andrei, I added your name to the copyright statement for the fix. Is this ok with you?
Yes, thank you. "head" means it would be in 3.4, but what is about 3.3.2?
Created attachment 83875 [details] patch to use non-zero length file for the lock (In reply to comment #77) > "head" means it would be in 3.4, but what is about 3.3.2? > Well, right now we are just evaluating the fix. That is done in HEAD (3.4). If it turns out to be a good fix and deemed critical for a point release then we will consider releasing for 3.3.2. Unfortunately I found issues with the fix. It causes the org.eclipse.osgi.tests to fail the LocationAreaSessionTests on Windows. It appears that the fix does not really lock the file if the file length == 0. The tryLock(0, 0, false) call will always succeed and return a FileLock object no matter what (at least on win32 XP). Also with the fix I am able to open two instances of Eclispe to the same workspace, which indicates that the locking did not really work. I modified the patch to ensure the lock file is at least 1 byte in length. This is just a hack to illustrate the problem and potential fix. We may need to find a better place to put the code to write a single byte to the lock file. Andrei, can you test this fix out in your environment?
Created attachment 84020 [details] patch to lock the first byte only According to the javadoc for tryLock(long, long, boolean) the region specified by the position and size parameters need not be contained within, or even overlap, the actual underlying file. This means we should be able to simply use the call: fileLock = fc.tryLock(0, 1, false); We never write to the lock file anyway so just locking the first byte should be ok, even though there are no bytes in the underlying lock file. Andrei, please give this latest patch a try. I tested it on Win32 XP.
Thomas, I've tested "fc.tryLock(0, 1, false)" with Sun 1.5 VM: java version "1.5.0_12" Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_12-b04) Java HotSpot(TM) Client VM (build 1.5.0_12-b04, mixed mode, sharing) and also with IBM 1.5 VM: Java(TM) 2 Runtime Environment, Standard Edition (build pxi32dev-20070201 (SR4)) IBM J9 VM (build 2.3, J2RE 1.5.0 IBM J9 2.3 Linux x86-32 j9vmxi3223-20070201 (JIT enabled) J9VM - 20070131_11312_lHdSMR JIT - 20070109_1805ifx1_r8 GC - 200701_09) JCL - 20070126 in both cases it works in my "bad" Linux environment (lock is created and the second Eclipse could not be opened on same workspace). I'm wondering why the fc.tryLock(0, 0, false) was not working on Windows or why it was working on Linux...
Created attachment 84086 [details] released 3.4 patch I have released this final patch into HEAD for 3.4 (M4). I will leave this defect open for 3.3.2 consideration. This patch is identical with the last one except it removes the local FileChannel vars since we don't need to get the size anymore. (In reply to comment #80) > I'm wondering why the fc.tryLock(0, 0, false) was not working on Windows or why > it was working on Linux... > Yeah, I wandered that also. My guess is that on windows it assumes that if position + size == 0 then there is really no physical region of the file that you are locking so there is no way to fail the lock. But I don't know if that is a valid assumption or if there is a possible bug in the Windows or Linux VMs. I tested the behavior on Sun 1.4.2, 1.5, 1.6 and IBM 1.4.2, 1.5 on Windows XP. All had the same behavior; tryLock(0, 0, false) always returned a FileLock even if another process held the lock.
Created attachment 84230 [details] 3.3.x patch Here is the 3.3.x patch.
Comment on attachment 83852 [details] Patch for org.eclipse.update.internal.configurator.Locker_JavaNio Will attach new update.configurator patch to bug 211060
Jeff, do you approve for 3.3.2? John, can you give the 3.3.2 patch a review?
Yes, fix looks good. Adding the "greatbug" keyword to acknowledge the excellent analysis and fix proposal from Andrei (comment #66). If only all bug reports came in with such detail...
Patch released to 3.3.2.
*** Bug 128967 has been marked as a duplicate of this bug. ***
*** Bug 167152 has been marked as a duplicate of this bug. ***
Note I have also applied the fix to the copy of Locker_JavaNio found in Equinox p2 (see bug 214567).
Maybe it's not resolved. It happens to me without NFS or anything strange. With java: java version "1.6.0_22" Java(TM) SE Runtime Environment (build 1.6.0_22-b04) Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode) and java version "1.6.0_20" OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1) OpenJDK Server VM (build 17.0-b16, mixed mode) Message in a popup is: Locking is not possible in the directory "/opt/eclipse-helios/configuration/org.eclipse.osgi". A common reason is that the file system or Runtime Environment does not support file locking for that location. Please choose a different location, or disable file locking passing "-Dosgi.locking=none" as a VM argument. /opt/eclipse-helios/configuration/org.eclipse.osgi/.manager/.fileTableLock (Permiso denegado) Introducing the -Dosgi.locking=none into config does nothing. Would be nice to introduce a command line parameter to eclipse to show version and release numbers. Thank you.
(In reply to comment #90) > Maybe it's not resolved. > > It happens to me without NFS or anything strange. > > With java: > java version "1.6.0_22" > Java(TM) SE Runtime Environment (build 1.6.0_22-b04) > Java HotSpot(TM) Server VM (build 17.1-b03, mixed mode) > > and > java version "1.6.0_20" > OpenJDK Runtime Environment (IcedTea6 1.9) (6b20-1.9-0ubuntu1) > OpenJDK Server VM (build 17.0-b16, mixed mode) > > Message in a popup is: > > Locking is not possible in the directory > "/opt/eclipse-helios/configuration/org.eclipse.osgi". A common reason is that > the file system or Runtime Environment does not support file locking for that > location. Please choose a different location, or disable file locking passing > "-Dosgi.locking=none" as a VM argument. > /opt/eclipse-helios/configuration/org.eclipse.osgi/.manager/.fileTableLock > (Permiso denegado) > > > Introducing the -Dosgi.locking=none into config does nothing. > > Would be nice to introduce a command line parameter to eclipse to show version > and release numbers. > > Thank you. See bug287339 and bug301226. This is because the configuration folder has a different set of permissions than your install folder. As a result we think the install is writable but the configuration folder has permissions such that the user cannot write to it.
