Hello,
Since long time ago (I never tried to raise an issue for it, but always had this problem), I had some locks that completely block the UI thread:
I don't know the exact use of this method (here: https://sourceforge.net/p/jedit/svn/HEAD/tree/jEdit/trunk/org/gjt/sp/jedit/buffer/JEditBuffer.java#l293 ? ) but I think there should be at least some timeout, or long operation should never be done on UI thread.
In the case here, the file being saved was on a (slow) USB device. But I have seen the problem with other file, on SSD.
Versions :
I do have some plugins; list is found in plugins.txt.
Regards,
Baldurien
Trace below and in attached file.
"AWT-EventQueue-0" #25 prio=6 os_prio=0 cpu=5421.88ms elapsed=1209.19s allocated=1082M defined_classes=2666 tid=0x000001c8deead000 nid=0x1830 waiting on condition [0x00000008644fd000]
java.lang.Thread.State: WAITING (parking)
at jdk.internal.misc.Unsafe.park(java.base@11.0.9.1/Native Method)
- parking to wait for <0x00000007012fcaf0> (a java.util.concurrent.locks.ReentrantReadWriteLock$NonfairSync)
at java.util.concurrent.locks.LockSupport.park(java.base@11.0.9.1/LockSupport.java:194)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(java.base@11.0.9.1/AbstractQueuedSynchronizer.java:885)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(java.base@11.0.9.1/AbstractQueuedSynchronizer.java:917)
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(java.base@11.0.9.1/AbstractQueuedSynchronizer.java:1240)
at java.util.concurrent.locks.ReentrantReadWriteLock$WriteLock.lock(java.base@11.0.9.1/ReentrantReadWriteLock.java:959)
at org.gjt.sp.jedit.buffer.JEditBuffer.writeLock(JEditBuffer.java:293)
at org.gjt.sp.jedit.Buffer.finishSaving(Buffer.java:2298)
at org.gjt.sp.jedit.Buffer.lambda$save$0(Buffer.java:639)
at org.gjt.sp.jedit.Buffer$$Lambda$242/0x000000080055fc40.run(Unknown Source)
at org.gjt.sp.util.AwtRunnableQueue$RunRequestsInAWTThread.doAWTRequest(AwtRunnableQueue.java:157)
at org.gjt.sp.util.AwtRunnableQueue$RunRequestsInAWTThread.run(AwtRunnableQueue.java:136)
at java.awt.event.InvocationEvent.dispatch(java.desktop@11.0.9.1/InvocationEvent.java:313)
at java.awt.EventQueue.dispatchEventImpl(java.desktop@11.0.9.1/EventQueue.java:770)
at java.awt.EventQueue$4.run(java.desktop@11.0.9.1/EventQueue.java:721)
at java.awt.EventQueue$4.run(java.desktop@11.0.9.1/EventQueue.java:715)
Yes it's annoying. The purpose of this method is to prevent two threads from writing in the buffer at the same time, it cannot be disabled. I don't see any useful information in your threads. Just that while saving, jEdit tried to acquire the lock and it was blocked but I don't see any information about what did get the lock before.
Do you have the activity log ? Or maybe some idea to reproduce it ? It can comes from a plugin too, or be an internal bug of jEdit.
There is a read and write lock (ReentrantReadWriteLock) and I don't use them that often, but I do know that locking a read lock will also block the write lock. The trace may not help because it may simply be a readLock() being owned by another thread.
Sadly, I don't have the activity.log at the time it failed. And since it blocked the UI, I can't get access to the "Utilities->Troubleshooting->Update Activity Log on Disk command!". I'm not sure the activity log would be complete. Beside this, there are no trace in the read/write method that mention the thread/stack.
The plugin that I use often and that could write could be the XML plugin, when indenting, or the Search and Replace (in the past, I do remember using some complex regexp).
As for a way to reproduce, I don't have any : it is more or less "random"..
I'll try to start my jEdit instance using a debugger by default. It may help me find the two thread clashing at each other.