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.
The lock file in testuserdir/lock is quite often not removed during Platform development. I use the debugger, check some variables and kill the launched application with the "StopDebugger" button. Quite often the lock file is not removed and NB denies to build / launch again due to this issue. Error message then is /usr/local/java/netbeans-6.9.1/harness/suite.xml:463: Will not delete /home/sc1/NetBeansProjects/oo/TestNBPlatform/JGESiC/build/testuserdir because /home/sc1/NetBeansProjects/oo/TestNBPlatform/JGESiC/build/testuserdir/lock still exists; kill any running process and delete lock file if necessary
(In reply to comment #0) > kill the launched application with the "StopDebugger" button. When you kill it, you deny the process the ability to run its cleanup hooks, including removing the lock file. Rather use File > Exit or similar.
I kill it only, if I cannot do something else any more (and that happens often currently). Even in this case the user should be able to start without problems and base knowledge how to remove that lock file. Just ask the user that potentially another instance is running or was incorrectly stopped instead of denying to launch at all
If you think it is an enhancement when the user can work with NB after a NB crash again, feel free to close the bug. I think this is a bug and not an enhancement.
It is working as currently designed. The lock file ensures only one copy of the app is running and is cleaned up during normal shutdown. In the exceptional circumstances of a hard crash, you need to do this yourself; you might also need to kill a zombie process of some kind. The RFE is for the IDE to assist you by prompting to remove the lock file.
Yarda suggested using a java.nio.FileLock to check whether the lock was still valid. This however can give false negatives in case the target platform is technically running but somehow hung. The actual CLI connection code deals with this case by trying to communicate with the target platform and assuming after a certain timeout that it is dead. The --test-userdir-lock-with-invalid-arg hack is a way to reuse this implementation when determining whether it can restart the app, but it has undesirable side effects too (see blocked issue), and this logic is also unavailable in the clean target. Ideally the development IDE would have some way of checking whether the target platform were still running and responsive; when a run target was ended (because the target platform were shut down normally, crashed incl. Finish Debugger invoked, or Build > Stop Build/Run called) and yet $userdir/lock remained, this check would be run, and if the lock proved stale it would be deleted. This would allow other code to use the presence of the lock file as a reliable way of determining whether the app was running or not.
*** Bug 195885 has been marked as a duplicate of this bug. ***
If the platform is running, but hung, you can either kill the process, or you can stop debugging. These are easy to do actions (xkill is easy to use, Shift-F5 as well). However right now, if the stalled lock is left on behind, there is nothing easy to do with it. You have to locate the userdir and manually remove it (run a shell, do proper 'cd', rm -rf - painful). --test-userdir-lock-with-invalid-arg - breaks any application using the CLI for mandatory commands - e.g. just prevent passing it to sendsopts Handler (e.g. bug 193649 is not 100% duplicate). "some way of checking whether the target platform were still running" - I can think of few options (different -Dnetbeans.mainclass, or some change to core.startup Handler to react to additional option). I guess I give it a try tomorrow.
Created attachment 106641 [details] Patch that allows clean build of project with left-behind lock file I admit I don't understand the "false negatives" arguments at all. Here is clear usecase which is broken right now and fixed after applying my patch: 1. create NetBeans Platform Application 2. debug the project 2a. try clean & build on the project - properly refused 3. without closing the main window, finish the debugger session 4. try to do clean & build Currently the clean in step 4 is refused for arbitrary reasons. With my patch, the clean properly succeeds.
Integrated into 'main-golden', will be available in build *201104060400* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/dbfe874ced11 User: Jaroslav Tulach <jtulach@netbeans.org> Log: #193681: Allow clean build when a userdir/lock is left (for example after terminating debugging session)
*** Bug 200040 has been marked as a duplicate of this bug. ***
Good enough for now. After the fix of bug #207530, the remaining bug is that if the target platform holds a lock on the lock file but is not responsive (e.g. deadlocked), <islocked> will return true and so the IDE will refuse to permit various actions (Run/Debug/Profile, Copy/Move/Rename/Delete). To solve this situation you have to manually kill the process, whereas --test-userdir-lock-with-invalid-arg would figure out that the process was hung and allow you to proceed with a fresh process. Shift-F5 is easy enough if the process is running in the debugger; otherwise you need to find a platform-specific tool (xkill, Task Manager, etc.), or hope that Build > Stop Running successfully transmits the kill instruction to the target JVM.