Community
Participate
Working Groups
after termination of an application launch (debug and run) no shutdown hook is invoked. Executing the same application from the command line without eclipse on the same jvm as configured in eclipse executes all shutdown hooks as expected. I tracked the problem down to the class java.lang.UnixProcess but I suppose this is just a symptom. The curious thing is that stepping through the method public void destroy() { destroyProcess(pid); try { stdin_stream.close(); stdout_stream.close(); stderr_stream.close(); } catch (IOException e) { // ignore } } of UnixProcess changes the runtime behaviour: The shutdown hooks are invoked if one waits for a short time (let it be 1s) after the invocation of destroyProcess(pid). I surmise the problem is somewhere else as the same jvm works correctly without eclipse on the same class. Maybe eclipse uses other methods for thread termination than the jvm itself? I got the erroneous result with different applications. Here's an example for testing: public class Test { static { Thread hook = new Thread() { public void run() { System.out.println("shutdown hook invoked"); } }; hook.setPriority(Thread.MIN_PRIORITY); Runtime.getRuntime().addShutdownHook(hook); } public static void main(String [] args) throws Exception { System.out.println("Read text: " + System.in.read()); } }
NOTE: the shutdown hooks do work if you terminate the VM via the DOS console. This can be acheived by launching Eclipse with "javaw" (i.e. no console), and then launching your java apps with console (i.e. with "java", that can be specified in the JRE tab). I found when using CTRL-C from the DOS console, and using the close button from the DOS console, does invoke the shutdown hooks. Since the termiante button in Eclipse kills the associated process with a call to Process.destroy(), and since we do not own/control the implementation of java.lang.Process.destory(), I'm not sure that there is much we can do.
Another NOTE: the "Runtime workbench" launch config type does not support the specification of "java vs. javaw" when lanuching a VM, so this function is not available with Runtime workbench launch configs (i.e. a DOS console).
No action planned currently. Deferred.
*** Bug 51351 has been marked as a duplicate of this bug. ***
*** Bug 55208 has been marked as a duplicate of this bug. ***
*** Bug 70418 has been marked as a duplicate of this bug. ***
*** Bug 75791 has been marked as a duplicate of this bug. ***
Is there any plan to fix this, its proving to be a nuisance for me :-)
Not planned for 3.2, can re-consider in future release
I'm keen to be able to trigger a shutdown hook in a process that was started by Eclipse, but am having trouble getting the instructions at Comment #1 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=38016#c1) to work. However, this could be because I don't quite understand Comment #2 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=38016#c2). What I do is: 1 Start Eclipse 3.1.2 with javaw.exe as the vm. 2 In the Java perspective, right click on the class I want to run and select "Run->Run as...". 3 Select the "Java Application" node and then click "New". 4 Select the "JRE" tab, then the "Alternate JRE" radio button, then the "Alternate Java Executable" radio button. I then enter "java" in the text field. 5 Click "Run". However, the application still directs its output to the Eclipse Console View instead of a new DOS window. Consequently, it can't detect Control-C and my shutdown hook doesn't get triggered. To be perfectly honest, I don't really understand comment #2, so appreciate I might be missing something here. Is anybody able to help me with this?
The workarounds mentioned in comment #1 and comment #2 are no longer available as a shell is never allocated when launching any more (regardless of which executable you use). Have you tried killing the launched process via the task manager? Can't say for sure that your shut down hooks will be be called...
I tried killing the process via the task manager but experienced the same problem. I'm using Spring with a connection pool so it's desirable for me to do a clean shutdown. This bug gets a vote from me :) As a workaround, when I'm running inside Eclipse I use a main() method that sets up the application (including the shutdown hook) and then calls System.in.read() - which blocks whilst waiting for input. I can then interact with my application (via other threads I setup) until I push 'enter' in my console view. This unblocks System.in.read(). main() then calls System.exit(), which triggers my shutdown hook.
*** Bug 179179 has been marked as a duplicate of this bug. ***
What is the current status of this bug? I have similar problems but I cannot use the suggested workaround reading from System.in because I don't own the code. It would be very nice with a button or something that would send the ctrl-c to the debugged process.
And why is it marked deprecated? last I checked, Runtime.addShutdownHook() was not deprecated.
The RESOLVE LATER status is deprecated, not this bug report. We are moving to a new way of deferring bugs, but we have no plans to change the status of our entire later box.
This should likely be a won't fix - same problem as bug 64230. We don't have a way from Java to send signals to another process.
Marking as won't fix.
Eclipse contains native code for other purposes. Why not this one?
Another idea is perhaps to supply an option to start a remote command window instead of using the console.
this bug presents a serious problem in some cases. for example, when developing bluetooth applications, not releasing resources on exit may bring the drivers to an unstable state which requires reboot. maybe its worth checking how Sun terminates the JVM at NetBeans.
*** Bug 248673 has been marked as a duplicate of this bug. ***
I'm another victim of this. I'm using a session pool for connections to a commercial service and need to close those sessions on exit. If I don't, I quickly hit a session count limit for my IP address and cannot continue testing. What I don't understand is why is Eclipse insisting on using Process.destroy() instead of Runtime.exit()? Why not make this an option in the runtime configuration?
(In reply to comment #23) > What I don't understand is why is Eclipse insisting on using Process.destroy() > instead of Runtime.exit()? Why not make this an option in the runtime > configuration? Note, the issue is different. This bug is about the red square "Terminate" button in the Eclipse Console/Debug view. It terminates ('kills') an external process launched through an Eclipse Run/Debug launch configuration. "Runtime.exit" is for closing the *current* VM instance but you don't want to shut down the Eclipse IDE if you terminate an external process you are debugging. The only way to fix the issue would be to implement some communication between the external VM and the IDE to force a proper shutdown. But the proper way is to always shutdown/close the external process using its preferred way. It's the same with Tomcat or any other server launched for debugging your application. You don't end Tomcat by killing the process but by invoking a shutdown command. The red square button really kills a process. It does not properly shutdown any process.
There is a similar situation with any windows or even java application. In windows task manager it depends on the tab -- Ending Task at Application tab respects java shutdown hooks and tries to end gracefully. End Process ends java process quickly and without any shutdown hooks called. It is expected that we should have similar feature in Eclipse -- have a decision whether to kill quick or gracefully.
(In reply to comment #25) > It is expected that we should have similar feature in Eclipse -- have a > decision whether to kill quick or gracefully. Yes I agree. But have a look at comment #17. Until there isn't such thing (either in the JRE or in some EPL contributed code using JNI and maintained by any volunteer) I don't think it will ever get implemented.
I understand comment 17 but couldnt there be some hook somewhere to call things before Process.terminate?
I just verified the following on Linux with Java 1.6.0_12 : when a Java process receives a SIGTERM (the default signal for kill) the shutdown hooks executes. when it receives SIGKILL (aka kill -9), the shutdown signal does not gets called.
Hi guys! Do you have some plans to fix that? Is it possible simply to add one more button beside the termination one to send SIGTERM instead of termination like it is for the only current button? Or even add some combobox to send chosen signal to the running application?
I'm affected by this as well. Users assume that the red box button is the way an application should be shutdown, and think it's my bug when shutdown doesn't occur properly. I would be able to pass a signal to my application to shutdown properly if I could get notified when the big red button is pressed. Perhaps I would register for notification when that button is pressed and then could do my application-specific handling (sending a string over a socket, or maybe writing to the IOConsole in my case)?
The platform ends up delegating to implementations of ITerminate.terminate() when the button is pressed. When pressed in the console, the IDebugTarget implementations are called before the IProcess (if there is a target associated with the process). Perhaps you could provide your own implementation of ITerminate in your target or your own subclass of RuntimeProcess.
(In reply to comment #29) > Hi guys! > > Do you have some plans to fix that? Is it possible simply to add one more > button beside the termination one to send SIGTERM instead of termination like > it is for the only current button? Or even add some combobox to send chosen > signal to the running application? Second this motion, I think you need both "Terminate" and "Shutdown" buttons. Otherwise the only way to debug the graceful shutdown of the application is to pollute your code with guarded "exit" calls. Just imagine what happens when one of these calls is not removed before going into production. BTW, I think the current action of the big red button ( SIGKILL ) is still valuable, so it should be preserved.
I may be off base here, but thought I'd chime in (even though an issue marked WONTFIX 3 yrs ago probably won't get fixed). I'm going to speak specifically to the case of **debugging** code. If Eclipse has fired off a separate process, and we have the ability to debug it, then doesn't that suggest that JPDA is being used so that Eclipse can communicate with that process? If JPDA is being used, then why is this whole java.lang.Process.destroy(...) discussion even germaine? Why isn't the debugger simply using the wire protocol to send an Exit (http://download.oracle.com/javase/1.4.2/docs/guide/jpda/jdwp/jdwp-protocol.html#JDWP_VirtualMachine_Exit) ? Then, as others have suggested, we could have exactly the scenario that we have with managing Tomcat servers; one button for the soft terminate, the other for the hard kill. I'll admit I don't live in JPDA/JDWP, so maybe there is something I'm missing.
*** Bug 368104 has been marked as a duplicate of this bug. ***
I have a work-around for this bug. It really is just a work around but if you need a clean way to shutdown your process under IDE control, this might help. The link below is to the write up on the workaround and a download utility. http://jnetpcap.com/node/1106 This is something not recommended for production environments, obviously, but works well in development. Probably won't be application in all circumstances.
It would still be good to have a "shutdown" and a "terminate" button native in eclipse ;-)
Could this bug please be reconsidered in light of comment 33 ?...
I definately would vote for this, the hard exit causes several issues (lost setting, temp files not deleted) etc.
I would vote for this too. We have command-line entry point for our RCP application, and users often run things from command line and then hit 'Ctrl-C' in the middle, which causes app to just collapse. I'd like something better than having to run some separate processes that monitor the main process.
(In reply to Reid M. Pinchback from comment #33) > I may be off base here, but thought I'd chime in (even though an issue > marked WONTFIX 3 yrs ago probably won't get fixed). Over 6 years ago now :-) > I'm going to speak specifically to the case of **debugging** code. > > If Eclipse has fired off a separate process, and we have the ability to > debug it, then doesn't that suggest that JPDA is being used so that Eclipse > can communicate with that process? > > If JPDA is being used, then why is this whole java.lang.Process.destroy(...) > discussion even germaine? Why isn't the debugger simply using the wire > protocol to send an Exit > (http://download.oracle.com/javase/1.4.2/docs/guide/jpda/jdwp/jdwp-protocol. > html#JDWP_VirtualMachine_Exit) ? Then, as others have suggested, we could > have exactly the scenario that we have with managing Tomcat servers; one > button for the soft terminate, the other for the hard kill. As far as I can tell, the JDWP Exit command causes the VM process to exit immediately without running shutdown hooks (i.e. not a 'graceful' shutdown by any means). Eclipse sends the Exit command when you terminate a "Debug" application, hence why shutdown hooks don't run. When you "Run" an application, Eclipse terminates it with Process.destroy, which sends SIGTERM to that process, so shutdown hooks *do* run. So in a way, sending the Exit command via JDWP is *worse* than using Process.destroy, as the latter would allow shutdown hooks to run. Perhaps a solution would be to provide an option (or an alternative button) to allow "Debug" applications to be terminated with Process.destroy instead of the JDWP Exit command.
A possible implementation inside Eclipse can be that Eclipse add a small launcher class to the application. This starter can launch on a socket and then start the target application. On a press of the stop button Eclipse contact this socket and the launcher call System.exit() directly inside the VM.
*** Bug 11088 has been marked as a duplicate of this bug. ***
This just bit me. I'm working on a distributed app, and I kept wondering why my remote nodes were not being cleaned up properly when trying to debug from eclipse. Sending a SIGTERM externally makes everything work as expected
Bit me too, see comments #33 and #40. Why is this WONTFIX although this clearly is a bug in Eclipse?
yeah strange why this is not (being) fixed despite the fact that it's a bug...
I have an RCP application. I need some preferences to be set just before eclipse is shut. It happens when shut down normally, but when killed or terminated, the preferences for my RCP are not updated, due to this bug. Can any one suggest a workaround or get this bug fixed?
Hi, In launch of MyLaunchDelegate extends JavaLaunchDelegate I add decorator just after process is launched: super.launch(configuration, mode, launch, monitor); if(!debug) { IProcess p = launch.getProcesses()[0]; launch.addProcess(new ProcessDecorator(p)); launch.removeProcess(p); } In this decorator I am doing public class ProcessDecorator implements IProcess { private IProcess p; public ProcessDecorator(IProcess p) { this.p = p; } @SuppressWarnings("rawtypes") @Override public Object getAdapter(Class arg) { return p.getAdapter(arg); } @Override public boolean canTerminate() { return p.canTerminate(); } @Override public boolean isTerminated() { return p.isTerminated(); } @Override public String getAttribute(String s) { return p.getAttribute(s); } @Override public int getExitValue() throws DebugException { return p.getExitValue(); } @Override public String getLabel() { return p.getLabel(); } @Override public ILaunch getLaunch() { return p.getLaunch(); } @Override public IStreamsProxy getStreamsProxy() { return p.getStreamsProxy(); } @Override public void setAttribute(String s1, String s2) { p.setAttribute(s1, s2); } @Override public void terminate() throws DebugException { // TODO: custom termination p.terminate(); } } It is my workaround.
Could you please suggest a method to set preferences just before eclipse is terminated or killed?
Megha Shah, I am not sure what do you mean by 'set preferences'. If you are talking about inter-process communication I use dirmi: https://github.com/cojen/Dirmi. I provided an example how to use it in eclipse rcp: https://github.com/marekjagielski/eclipse-launcher-with-dirmi-server In my project I am doing as I described before. To be precise: I am "asking" process to terminate gently on red button click: private boolean sigkill = false; @Override public void terminate() throws DebugException { if(!sigkill) { try { IDebugIService cs = DirmiServer.INSTANCE.getRemote("main", IDebugIService.class); if(cs != null) cs.modelEvent(new TerminateRequest()); } catch (RemoteException e) { } this.sigkill = true; } else p.terminate(); } sigkill flag is a "lifeline" in case when something went wrong in process termination. If after first click the process didn't stop, second click on red button shuts down as default. If you want know more how to integrate dirmi in your project, I invite you to post for example in this topic: http://www.eclipse.org/forums/index.php/t/550201/
Anything new? Is there any ugly fix i can install to make this SOMEHOW work? I need my embedded server to shutdown gracefully! This is a really basic thing that really should work, and even if fairies must die for it and magic be applied, please go for it.
I agree, this is probably the most annoying "feature" of the Eclipse at the moment. PLEASE reconsider addressing this! If other IDEs can do this, why can't Eclipse?
This bug is 13 years old. Is it possible to sponsor the fix for this bug?
I found a workaround for this problem on linux. start your java application from eclipse if you debug only one application at time you can use in console ps auwx | grep jdwp | grep -v grep | cut -d' ' -f2 | xargs kill if you use more than one application, chose your id to kill from ps auwx | grep jdwp
> When you "Run" an application, Eclipse terminates it with Process.destroy, > which sends SIGTERM to that process, so shutdown hooks *do* run. This is not accurate. Shutdown hooks are not run regardless of whether or not the process was launched via "Run" vs. "Debug".
Dear Eclipse, I can't believe you have given up providing a workaround for this. The Process instance is typically a UNIXProcess which contains a pid How difficult is it to add a button that will call: kill -15 <pid>? If it doesn't work then the user can still click on the existing red button. That's the way it works in IntelliJ. What am I missing?
Reopening this to analyze if something can be done to solve this issue.
Perhaps https://github.com/zeroturnaround/zt-process-killer could be of use here? (I was just looking at using it in my https://github.com/vorburger/ch.vorburger.exec when I saw this being re-opened, and thought it may be of interest in this context.)
(In reply to Michael Vorburger from comment #58) > Perhaps https://github.com/zeroturnaround/zt-process-killer could be of use > here? (I was just looking at using it in my > https://github.com/vorburger/ch.vorburger.exec when I saw this being > re-opened, and thought it may be of interest in this context.) Thanks Michael, is the source code under EPL ? Or if you could provide a gerrit ?
> Thanks Michael, is the source code under EPL ? zeroturnaround/zt-process-killer is ASL not EPL <https://github.com/zeroturnaround/zt-process-killer/blob/master/License.txt> BUT if you looked at this and really do have a serious interest in using this in Eclipse, then I'd imagine that the zeroturnaround could be open to re-license it under dual ASL & EPL.. and then you could use it (copy/paste or actually pull the JAR; whatever you prefer). As far as I know, such a re-license under dual ASL & EPL of zt-process-killer would need the agreement of all their past contributors - but there are only 4 <https://github.com/zeroturnaround/zt-process-killer/graphs/contributors> and they are all at zeroturnaround so IMHO this may be feasible - at least worth a try. Perhaps you would like to open an issue with them on https://github.com/zeroturnaround/zt-process-killer/issues to ask? > Or if you could provide a gerrit ? From what little I understand of FLOSS, for me to copy/paste the zeroturnaround/zt-process-killer code into an eclipse.org Gerrit wouldn't be right... ;-) And I unfortunately don't have the time to actively contribute code to this as well - just coincidentally saw the update on this bug and thought contributing this as an idea could interest you.
(In reply to Michael Vorburger from comment #60) I will look into the code, Thanks.
Another option is to look into ProcessHandle APIs available as part of Java 9.
Plan to look at it after JDT moves to Java 9 and can utilize the support.
Not yet moved beyond 8.
This bug has been biting me and my users. My library can create a lot of temporary files, and if you stop a Java program while those files are around (before the shutdown hook runs), the temporary files stay around. If you are debugging over an extended period of time, the buildup of temporary files can be significant. Wouldn't a simple solution be to use the JDWP command `VirtualMachine/RedefineClasses` to add a method that calls `System.exit(1)` to an existing class (or define a new class with that method, if that is supported), and then simply call that method inside the debugger?
Out of curiosity, I stopped a running program at a breakpoint, then typed and selected "System.exit(1)" and hit Ctrl+Shift+D to display the (void) value of this, hoping it would kill the running program. Instead, the running program just hung. Anyone know why? If this could be made to work properly (i.e. running System.exit(1) in the context of the running program, the same way that "Display expression" works, without causing the program to hang, but rather exiting it), then this would be a way the debugger could cause shutdown hooks to run when the red "Exit" icon is clicked in the debugger.
(In reply to Luke Hutchison from comment #66) > Out of curiosity, I stopped a running program at a breakpoint, then typed > and selected "System.exit(1)" and hit Ctrl+Shift+D to display the (void) > value of this, hoping it would kill the running program. Instead, the > running program just hung. Anyone know why? If this could be made to work > properly (i.e. running System.exit(1) in the context of the running program, > the same way that "Display expression" works, without causing the program to > hang, but rather exiting it), then this would be a way the debugger could > cause shutdown hooks to run when the red "Exit" icon is clicked in the > debugger. Will investigate.
Sarika -- did you find why this hangs? Calling System.exit() in the debug process would be a straightforward fix, if it could be made to work.
(In reply to Luke Hutchison from comment #68) > Sarika -- did you find why this hangs? Calling System.exit() in the debug > process would be a straightforward fix, if it could be made to work. I will be looking at it next week.
What do you mean by hang over here? My observation - Using System.exit(1) in Debug Shell removed the thread so you can continue to debug the current program anymore. But the Eclipse launch process is not killed so you can still see the terminate button and using it stops the Java Application completely.
Sarika: yes, this matches my observation. I interpreted the thread being removed from the debug UI as a hang, since the process was still alive, but you're right that the launch process can still be manually killed with the stop button.
Moving to 4.11. Hopefully will not have to move to 4.12.
Due to Java 12 work,could not focus on this.
16 years and counting - SMH BTW: Thank you Sarika for taking this on.
Unless we move the project to java 9 or above, it will be difficult to work on this.
Sarika: I don't think this is specific to JDK 9+? Just call System.exit(1) in the debug process, watch until it exits, then kill the launch process.
(In reply to Alex Pogrebnyak from comment #32) > Second this motion, I think you need both "Terminate" and "Shutdown" buttons. > Otherwise the only way to debug the graceful shutdown of the application is > to pollute your code with guarded "exit" calls. +1 come on guys
(In reply to Luke Hutchison from comment #76) > Sarika: I don't think this is specific to JDK 9+? Just call System.exit(1) > in the debug process, watch until it exits, then kill the launch process. ProcessHandle APIs available as part of Java 9. System.exit(1) does not solve the issue, Read Comment 24 c#24, It will terminate the running Eclipse IDE itself which we don't want.
I tried moving the Debug project to Java 9 to get the pid from process and executing "taskkill /F /PID <pid>" on windows instead of destroying process but still did not see shutdown hooks getting invoked. if (process != null) { long pid = process.pid(); String s = "taskkill /F /PID " + pid; //$NON-NLS-1$ try { Runtime.getRuntime().exec(s); } catch (IOException e) { e.printStackTrace(); } // process.destroy(); }
What about invoking Signal.of("SIGTERM").raise() within the debugged process? SIGTERM handling is marked as "Optional", and I don't know what the equivalent would be for Windows, but it would hopefully work on Linux and Mac OS X at least: https://docs.oracle.com/en/java/javase/11/troubleshoot/handle-signals-and-exceptions.html#GUID-57C048F6-0D4B-43BD-B27C-06A613435360 http://cr.openjdk.java.net/~rriggs/signal-doc/java/util/Signal.html
PS the benefit of sending SIGINT / SIGTERM is that it would work with CDT too, for native code projects that need to cleanly shut down (which is something I need right now for a C/C++ project I'm working on).
There is a some difference between kill -SIGINT <pid> getting called from the terminal and the Java process. I see shut down hook getting called when invoked from terminal but when I try invoking through Eclipse program or any other Java program using Runtime.getRuntime().exec() it doesn't call shutdown hooks. Signal.raise() will kill the whole Eclipse process. Is anyone aware of another way to execute command other than exec() which does no processing and will be equivalent to terminal execution?
Moving it out as I don't see a solution path right now.
Is it possible to determine who worked on the signal handling code in the Sun/Oracle JDK, and loop them into the conversation?
Created attachment 279610 [details] working solution Hi, have you tried the enclosed? Works perfectly on Mac Jvm 1.8_045
(In reply to Eric Vergnaud from comment #85) > Created attachment 279610 [details] > working solution > > Hi, have you tried the enclosed? > Works perfectly on Mac Jvm 1.8_045 Yes, and it works perfectly. Inspired by this I did try something in Eclipse and it looks like some timing issue. I was able to get the shutdown Hook invoked when Stepped in the process.destroy() and executed the steps one by one. Will investigate more.
Just wanted to check: when this issue is fixed, will files marked for deletion using `File#deleteOnExit()` be deleted when an application running in Eclipse is stopped? I think these files are deleted using a system-wide shutdown hook? If not, is there some other mechanism that needs to be run by Eclipse to enable deletion of these files when an application is stopped?
(In reply to Luke Hutchison from comment #87) > Just wanted to check: when this issue is fixed, will files marked for > deletion using `File#deleteOnExit()` be deleted when an application running > in Eclipse is stopped? I think these files are deleted using a system-wide > shutdown hook? If not, is there some other mechanism that needs to be run by > Eclipse to enable deletion of these files when an application is stopped? https://docs.oracle.com/javase/7/docs/api/java/io/File.html#deleteOnExit() According to this it works on normal termination only, I will test and confirm.
Thanks. I never noticed this happening before, but at least as of JDK 11, in some circumstances, the JDK seems to extract jar resources into /tmp (such as when loading a .so file form a jar, but also for some classes for some reason), and these are not cleaned up if you terminate the run with Eclipse. So it's not just 3rd party libraries that create temporary files that are affected by Eclipse not running shutdown hooks, it's actually the JDK itself that can create cruft in /tmp over time when shutdown hooks are not run (and the cruft is typically only cleaned up on reboot): $ ls /tmp/*.class /tmp/*.so 'BagFile$MessageIndex.class15328745468622781125.class' BagFile.class14372700760425535676.class BagFile.class6688204983276068213.class BagFile.class7527465372038899640.class Chunk.class5086705476083434450.class FileDispatcherImpl.class4246663762972315670.class FileDispatcherImpl.class509969819450880797.class 'IndexData$Index.class7254221828638128573.class' IndexData.class13012851764270154079.class IndexData.class839630762527656721.class liblz4-java10174631597647070177.so liblz4-java10220888173034950392.so liblz4-java11153630086711902447.so liblz4-java11975810591064495636.so liblz4-java12909386847462085663.so liblz4-java13832921501226947582.so liblz4-java15960297755835753610.so liblz4-java17209291726134741387.so liblz4-java17292657481681505452.so liblz4-java17860039254756526506.so liblz4-java17887412594984322724.so liblz4-java18240137399109853801.so liblz4-java2268670474833639564.so liblz4-java2513165952475610025.so liblz4-java2520157033574570033.so liblz4-java2915323548087197479.so liblz4-java2936384338880836884.so liblz4-java3643123653797186379.so liblz4-java452048025336389114.so liblz4-java499915305622433734.so liblz4-java5448292840432510840.so liblz4-java6790279636182739893.so liblz4-java7789706867666662535.so liblz4-java7883839137749976385.so liblz4-java9327835572204160199.so MessageData.class10384715811912315155.class MessageType.class6204546359432683903.class Preconditions.class9244002468333935679.class Record.class408030003202979610.class Record.class6686755743457051257.class Vector3D.class2042233245425318216.class
Related to running shutdown hooks on exit: would it be possible to add an additional type of "even cleaner" stop button that stops all threads, then walks up the stack frames in all threads and runs any `finally` blocks before running shutdown hooks and exiting? I assume that if this is possible, it would only work while running code in the debugger?
(In reply to Luke Hutchison from comment #90) > Related to running shutdown hooks on exit: would it be possible to add an > additional type of "even cleaner" stop button that stops all threads, then > walks up the stack frames in all threads and runs any `finally` blocks > before running shutdown hooks and exiting? I assume that if this is > possible, it would only work while running code in the debugger? Without being in a suspended state of execution, cleaner will be difficult. You can create a separate bug for that.
Unfortunately I am not able to make it work, I see it working fine and executing shutdown hooks If I step through destroyProcess. java.lang.ProcessImpl.destroy(boolean) synchronized (this) { if (!hasExited) processHandle.destroyProcess(force); } Executing "Kill" command has not worked either. So unless someone has some other idea to implement this, I can't proceed on this.
New Gerrit change created: https://git.eclipse.org/r/152852
(In reply to Eclipse Genie from comment #93) > New Gerrit change created: https://git.eclipse.org/r/152852 Even with Step in, this change sis required to make shutdown works in Debug mode.
*** Bug 449433 has been marked as a duplicate of this bug. ***
Created attachment 288283 [details] Patch from gerrit
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant. -- The automated Eclipse Genie.
Tested today on iMac/Intel 2014/MacOS 11/JAVA 21/Eclipse 4.31 Mac Studio/Silicon 2022/MacOS 14/JAVA 21/Eclipse 4.31 Shutdown hook works and produces messages and logging to file. So, it seems to work. ;JOOP!
