Menu
▾
▴
#3347 Unable to close jEdit
closed-fixed
6
2010-03-16
2009-11-28
No
I got it managed two times up to now with 4.3pre18 on Ubuntu 8.10, Sun Java 1.6, with background mode enabled, to get an unclosable jEdit. It was usable fine, but there was no option to close it, not even the View. Clicking on the upper right X didn't help, choosing File->Exit didn't help, keyboard shortcut didn't help, commandline "jedit -quit" didn't help. There were no exceptions in the activity log. There was output that the perspective is saved, but no error message or whatever, so jEdit did something, but wasn't able to complete the shutdown. I finally had to kill the process both times. Unfortunately I don't have a reliable way to reproduce this yet. It happend after some occasional usage during the day. Nothing fancy.
This is usually some exception that is not added to the activity log. Can you run it from a console where you can see the standard output & standard error of jEdit?
stdout and stderr are redirected to the activity log, or did someone change this? Of course I can run jedit from console, but as I don't have a reliable way to reproduce the problem, I don't know when it happens again.
I didn't know that. From what I saw, many places in the code that catch exceptions also add them (explicitly) to the log. I didn't see any automatic redirection, so it's very likely for some exception handler to "forget" to log them.
Next time you encounter it, please check the console for exceptions and add them here.
On Windows, when this happens, you can also get a full thread dump by pressing <Ctrl><Break> in the java console. I don't know if it works in other systems as well, also not sure it will help.
Ctrl-Break should work on all platforms as it is a java feature, not a platform feature.
If you do in BeanShell console:
BeanShell> System.out.println("Test out");
BeanShell> System.err.println("Test err");
you get in activity log:
14:52:49 [AWT-EventQueue-0] [notice] AWT-EventQueue-0: Test out
14:52:59 [AWT-EventQueue-0] [error] AWT-EventQueue-0: Test err
So as I said, those streams are redirected and I doubt console will say anything helpful but we will see.
Logging exceptions and so on explicitly to a logging framework is of course cleaner and better practice than capturing stdout and stderr, I think because of that at many places they are logged explicitly.
Yes, I see now the line in 'main' that initializes logging and redirects the streams. I really did not know about it... Thanks!
Could this be a duplicate of the following?
http://sourceforge.net/tracker/index.php?func=detail&aid=2898661&group_id=588&atid=100588
If so, you should be able to reproduce it using the steps described there, and then check if the latest trunk version fixes it.
Very likely a duplicate of 2898661 - an exception during exit. Please check if this is not the case.
While I can reproduce 2898661 as suggested in that bug, it is a different problem than what I describe here, because I also get the exception described in that bug report in the activity log while I did not get any exception when this bug happened.
When you encounter this problem, is jEdit responsive afterwards, despite failing to close?
I realize that the view remains (you still have the upper right X). Is it still responsive to changes in size?
It seems like a deadlock, so Ctrl+Break in this case can reveal it.
Unfortunately I was not able to reproduce it yet. But the GUI was still responsive. I don't know about resizes, because I didn't try that, but e. g. I was able to open the "Activity Log" dockable which also got updated, and I was able to repeat the click on the upper right X which caused some log messages to appear in the Activity Log, but nothing helpful. One was that the perspective was saved.
I see. This changes the picture completely.
When you try to exit jEdit, it first sends the edit bus message "EditorExitRequested". When plugins receive this message, they can call its "cancelExit" method to cancel the exit. I've read the the Sessions plugin makes use of this to cancel the exit in some cases; do you have this plugin installed? I think it's when the plugin needs to save something prior to exiting. Maybe it showed some dialog that was somehow put at the back and you didn't see it?
No I don't have the Sessions Plugin installed, I will attach the pluginset I have installed in the instance where it happened. No, I don't think there was a dialog. If there would have been a modal dialog, I would not have been able to operate on the View. If there would have been a non-modal dialog, I think I should have seen it through A+Tab which I tried and there was nothing.
And if this happens, there jEdit itself should write at least a log message indicating which Plugin prevented the closing in my opinion.
It happened again. This time at home. I still don't know how to reproduce it. But I have right now an unclosable instance of jEdit running that is responsive.
If I trigger the "exit" action, the following four lines appear in the activity.log each time:
01:11:45 [AWT-EventQueue-0] [debug] EditBus: EditorExitRequested[source=org.gjt.sp.jedit.View[active]]
01:11:45 [AWT-EventQueue-0] [message] PerspectiveManager: Saving /home/vampire/.jedit/perspective.xml
01:11:45 [AWT-EventQueue-0] [debug] MiscUtilities: Saving backup of file "/home/vampire/.jedit/perspective.xml" to "/home/vampire/.jedit/settings-backup/perspective.xml~1~"
01:11:45 [AWT-EventQueue-0] [debug] EditBus: DynamicMenuChanged[menu=recent-files,source=null]
I unloaded all plugins that were loaded and still no change in behaviour so I don't think it is the EditorExitRequest that blocks the closing, except this can happen with unloaded plugins what I doubt.
Any ideas how to investigate further before I kill the process?
btw. this is with 4.3.1 on Ubuntu 9.10 and Sun Java 1.6
Here is a current thread dump if it helps anyone:
BeanShell> tmxb.dumpAllThreads(true, true)
Array: [Ljava.lang.management.ThreadInfo;@23a098d {
"AWT-EventQueue-0" Id=222500 RUNNABLE
at sun.management.ThreadImpl.dumpThreads0(Native Method)
at sun.management.ThreadImpl.dumpAllThreads(ThreadImpl.java:374)
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:597)
at org.gjt.sp.jedit.bsh.Reflect.invokeMethod(Reflect.java:134)
at org.gjt.sp.jedit.bsh.Reflect.invokeObjectMethod(Reflect.java:80)
...
"AWT-Shutdown" Id=222501 WAITING on java.lang.Object@148507d
at java.lang.Object.wait(Native Method)
- waiting on java.lang.Object@148507d
at java.lang.Object.wait(Object.java:485)
at sun.awt.AWTAutoShutdown.run(AWTAutoShutdown.java:259)
at java.lang.Thread.run(Thread.java:619)
"jEdit server daemon [/home/vampire/.jedit/server]" Id=15 RUNNABLE (in native)
at java.net.PlainSocketImpl.socketAccept(Native Method)
at java.net.PlainSocketImpl.accept(PlainSocketImpl.java:390)
- locked java.net.SocksSocketImpl@2ff9473a
at java.net.ServerSocket.implAccept(ServerSocket.java:453)
at java.net.ServerSocket.accept(ServerSocket.java:421)
at org.gjt.sp.jedit.EditServer.run(EditServer.java:132)
"jEdit I/O #4" Id=20 WAITING on java.lang.Object@16b34971
at java.lang.Object.wait(Native Method)
- waiting on java.lang.Object@16b34971
at java.lang.Object.wait(Object.java:485)
at org.gjt.sp.util.WorkThread.doRequests(WorkThread.java:198)
at org.gjt.sp.util.WorkThread.run(WorkThread.java:154)
"jEdit I/O #3" Id=19 WAITING on java.lang.Object@16b34971
at java.lang.Object.wait(Native Method)
- waiting on java.lang.Object@16b34971
at java.lang.Object.wait(Object.java:485)
at org.gjt.sp.util.WorkThread.doRequests(WorkThread.java:198)
at org.gjt.sp.util.WorkThread.run(WorkThread.java:154)
"jEdit I/O #2" Id=18 WAITING on java.lang.Object@16b34971
at java.lang.Object.wait(Native Method)
- waiting on java.lang.Object@16b34971
at java.lang.Object.wait(Object.java:485)
at org.gjt.sp.util.WorkThread.doRequests(WorkThread.java:198)
at org.gjt.sp.util.WorkThread.run(WorkThread.java:154)
"jEdit I/O #1" Id=17 WAITING on java.lang.Object@16b34971
at java.lang.Object.wait(Native Method)
- waiting on java.lang.Object@16b34971
at java.lang.Object.wait(Object.java:485)
at org.gjt.sp.util.WorkThread.doRequests(WorkThread.java:198)
at org.gjt.sp.util.WorkThread.run(WorkThread.java:154)
"DestroyJavaVM" Id=26 RUNNABLE
"TimerQueue" Id=21 TIMED_WAITING on javax.swing.TimerQueue@549aa55b
at java.lang.Object.wait(Native Method)
- waiting on javax.swing.TimerQueue@549aa55b
at javax.swing.TimerQueue.run(TimerQueue.java:236)
at java.lang.Thread.run(Thread.java:619)
"AWT-XAWT" Id=11 RUNNABLE (in native)
at sun.awt.X11.XToolkit.waitForEvents(Native Method)
at sun.awt.X11.XToolkit.run(XToolkit.java:548)
at sun.awt.X11.XToolkit.run(XToolkit.java:523)
at java.lang.Thread.run(Thread.java:619)
"Java2D Disposer" Id=9 WAITING on java.lang.ref.ReferenceQueue$Lock@74de24c1
at java.lang.Object.wait(Native Method)
- waiting on java.lang.ref.ReferenceQueue$Lock@74de24c1
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at sun.java2d.Disposer.run(Disposer.java:125)
at java.lang.Thread.run(Thread.java:619)
"Signal Dispatcher" Id=4 RUNNABLE
"Finalizer" Id=3 WAITING on java.lang.ref.ReferenceQueue$Lock@243f36d8
at java.lang.Object.wait(Native Method)
- waiting on java.lang.ref.ReferenceQueue$Lock@243f36d8
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:118)
at java.lang.ref.ReferenceQueue.remove(ReferenceQueue.java:134)
at java.lang.ref.Finalizer$FinalizerThread.run(Finalizer.java:159)
"Reference Handler" Id=2 WAITING on java.lang.ref.Reference$Lock@3229b17f
at java.lang.Object.wait(Native Method)
- waiting on java.lang.ref.Reference$Lock@3229b17f
at java.lang.Object.wait(Object.java:485)
at java.lang.ref.Reference$ReferenceHandler.run(Reference.java:116)
}
Hey Vampire. I know this is totally off the wall, but I recently saw some similar stuck applications on my Ubuntu machine.
I started doing some research as to what actions resulted in a stuck application, and somehow found out it had to do with PulseAudio getting stuck.
If I kill the PulseAudio process the application becomes exitable.
Again, I know it's completely off the wall, but was something I experienced recently that seemed similar to your situation.
Also.. what happens if you try to exit java specifically.
From beanshell, if you use "System.exit(0);"?
I killed the PulseAudio main process which restarted immediately. No change in jEdit behaviour.
I guess "System.exit(0);" would do as it is the sledgehammer. I just didn't/don't want to do it currently as I can not really reproduce the situation intentionally and maybe there can still be some test made.
Yay, I tracked it down. With all those morons at work I almost forgot how funny it can be to track down tricky bugs.
I'm still not able to even unreliably reproduce the problem, but at least for this case I know what the problem was.
Ok, the problem for me, at least this time, was the following:
Somehow there was an error *orphaned* in the VFSManager.errors Vector. Then there was another error that triggered the VFSManager.error(Component, String, String, Object[]) method. Because of the still there sitting error that shouldn't be there, the Runnable that has to clear the VFSManager.errors and set VFSManager.error to "false" wasn't started. Because of this VFSManager.errorOccurred() always returned "false". In jEdit.closeAllBuffers(View, boolean) this is checked and in case of "false" "false" is returned at line jEdit:1969 and because of this the editor closing is just prevented without any notice or log message in line jEdit:2793.
Now anyone has to fix it in a senseful way. :-)
After I retrieved the errors Vector in the BeanShell Console via Reflection and cleared it, I provoked an IO Error (opened a big file causing an OOME) and then I was able to close jEdit without any problems.