Menu

#4106 jEdit hangs on while trying to acquire a writeLock on a buffer

normal bug
open
nobody
None
5
2021-01-17
2021-01-05
Baldurien
No

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:

  • jEdit is trying to get a write lock (JEditBuffer.writeLock)
  • jEdit wait until the world ends (or until I ran out of patience and kill jEdit :))

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 :

  • AdoptOpenJDK Java 11.0.9,
  • Windows 10
  • jEdit 5.6.0.

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)
2 Attachments

Discussion

  • Matthieu Casanova

    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.

     
  • Baldurien

    Baldurien - 2021-01-17

    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.

    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.

    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.

    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.

     

Log in to post a comment.

MongoDB Logo MongoDB