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.
Recently, I'm getting this exception a lot - I'd say 50% of the time when I'm trying to run my IDE project: "The application is already running with the test user directory. You must shut it down before trying to run it again." I've looked and there's still a lock file left in the user directory, even though I cleanly exited the IDE last time. I'm not sure where the bug is here - if during debugging it's not properly shutting down the IDE, or if there's a race condition in the code which is cleaning up the lock or what. I hope this is the right category for this.
$userdir/lock ought to be deleted whenever the platform is shut down (except by kill -9 or similar).
Jesse, it should, but it sometimes is not. For example if you kill debugee, it is not cleaned. I've run into this problem as well. Imho the "exception" is in fact a dialog shown somewhere from apisupport module. It is really annoying and it would benefit from few fixes: 1. it could have a button "Run Anyway" 2. it could detect that the lock file is "dead" and there is no server behind it by calling into CLIHandler Anyway I see this as a bug in apisupport not core.
Tor says the IDE was exited cleanly - if the lock is left in the userdir anyway, that is definitely a core bug. That said, both your suggestions #1 and #2 make sense. The former would be easy to implement, the latter a little more work (especially as we do not want to block the UI waiting for the target platform to respond).
Would suggest doing at least #1 for 6.5; should be simple.
Wouldn't be for #1 enough just not to check the lock in testuserdir and let NB application display usual warning (which already has an option to continue regardless of the lock)? The wording is not so clear, it doesn't specifically say that the lock is in testuserdir, but IMO suffices.
If the tested app already shows a dialog which lets you either continue (blowing away the lock) or cancel, then I guess that should suffice. I guess you mean to just delete if (project.getTestUserDirLockFile().isFile()) { notifyCannotReRun(); return; } and the associated method and bundle keys from ModuleActions.invokeAction?
Exactly. The warning reads: "An instance of the program seems to be already running with your user directory. Either a previous session of the program did not exit correctly, or another instance of the program is running on a different computer and using the same user directory. If another session of the program is running with the same user director, please click Cancel to prevent the corruption of the user directory. If you are sure that no other instances of the program are running with your user directory, click OK to continue. - OK / Cancel" which seems ok to me.
The proposed reversion of a89f924f468e would regress issue #63652 - if the platform is running _and responding to requests_ then trying to run it again will silently do nothing. The check for the lock file really needs to happen in apisupport, with the option of deleting a stale lock. As Yarda said, it would be best to check if the platform is live, but this gets more complicated. I really don't want apisupport duplicating the complex code in CLIHandler. Ideally there would be some CLI option --ping which would exit 0 if the platform was live and exit 1 if not, but this would not work on older platforms. The best I can come up with right now: if $userdir/lock exists, then run the app as you normally would, but append "--bogus" to the command line. If the app is not really running (or frozen and unable to respond), after a delay the lock will be overwritten and a new instance of the app will start up normally. If the app is responding, the command will quickly return with exit status 170 (invalid CLI option), which the harness (run.xml) can detect, and halt the build with an error message in the Output Window asking you to shut down the old platform instance before trying to start it anew.
Mhmmm, just observed similar behavior as you describe for #63652, but somehow more random - even when platform is not running, it sometimes rewrites the lock and continues and sometimes ends silently. Cannot find reproducible steps so far. I'll try your approach.
The approach with --bogus option works, thanks for the tip. There is last glitch on Windows, NB launchers silently swallow the exit code. Filing separate issue, once it is resolved, I can finish this one.
*** Issue 145397 has been marked as a duplicate of this issue. ***
In the current 6.5 dev builds (I am using 200809141401) the lock file is _never_ deleted when the session is terminated via the "Finish debugger session".
Right, "Finish Debugger Session" kills the VM immediately and does not give it a chance to clean up the lock. Issue #145324 is fixed so this could be resolved for NB 6.5, no?
fixed in core-main #f4b694e61658
Integrated into 'main-golden', will be available in build *200809170201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/f4b694e61658 User: Richard Michalsky <rmichalsky@netbeans.org> Log: #141069: Checks for running platform when userdir lock is present. When platform is running, run or debug targets fail instructing the user to shut the running instance down. Otherwise rewrites the lock silently.
Integrated into 'main-golden', will be available in build *200809200201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/875cdbd31cfb User: Richard Michalsky <rmichalsky@netbeans.org> Log: #141069: fixing mishandled merge (change os -> osfamily was lost)
Integrated into 'main-golden', will be available in build *200902220201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/86fdaf5bf991 User: Richard Michalsky <rmichalsky@netbeans.org> Log: #141069: fixed also for platform apps
The fix should append "--test-userdir-lock-with-invalid-arg" to run.args.extra rather than replacing the current value of run.args.extra. I have set several options in run.args.extra like increasing the maximum heap size. If my application terminates abnormally from a crash or by using the Finish Debugging Session, these settings aren't applied in the next run or debug session because of this fix. They get overwritten with "--test-userdir-lock-with-invalid-arg" and my program behaves badly because the heap size can't grow large enough.
westrick85: see bug #168126.
Just open task manager and look for runnning netbeans and hit end task