#3003 Deadlock on startup
With the jEdit trunk version, and the released version of ProjectViewer (2.9.0.0), jEdit frequently fails to start. I debugged it to find out the following flow that causes the deadlock:
1. During startup, jEdit loads the view configuration from perspective.xml, and tries to open the buffers that are specified there. Loading the buffers is done in the background, in a work thread.
2. As part of loading the perspective.xml file, jEdit tries to restore the dockable windows that were open the last time, one of them was the ProjectViewer dockable.
3. As part of the initialization of the ProjectViewer dockable, it tries to set the root node of the project tree to the last-open project. I configured ProjectViewer to automatically close & open buffers as needed when switching projects, so setting the root node of the project tree attempts to close those buffers that are loaded in the background (that were listed in perpsective.xml as "auto load"). It does that by calling "jEdit.closeBuffer(...)".
4. jEdit.closeBuffer(...) finds that the buffer is still performing an I/O request (being loaded in the background), and invokes "VFSManager.waitForRequests()". This call never returns.
I don't know the exact cause of all this, but I suspect that the jEdit.closeBuffer(...) is called from PV in the AWT thread, and I guess that the notification that the buffer is done loading is also registered to run in the AWT thread, so closeBuffer(...) blocks the AWT thread and prevents the notification to which it is waiting to actually take place.
Logged In: YES
user_id=1477607
Originator: YES
I'm sorry I can't put exact steps to reproduce this, since this does not always happen and I guess it requires that at least 4 files were open last time.
Something else I don't understand is why files that are not in the last open project are registered as "autoload" in perspective.xml, I guess there's some problem with the PerspectiveManager / Projectviewer synchronization.
Logged In: YES
user_id=935841
Originator: NO
Marcelo, can you help Shlomy with this? I run into this myself quite often when testing the CtagsInterfacePlugin.
Also, I have seen this with PV 2.1.3.7 (last released PV). 2.9 is not the last released PV.
Logged In: YES
user_id=935841
Originator: NO
Marcelo, can you help Shlomy with this? I run into this myself quite often when testing the CtagsInterfacePlugin.
Also, I have seen this with PV 2.1.3.7 (last released PV). 2.9 is not the last released PV.
Logged In: YES
user_id=75113
Originator: NO
I hate sourceforge's bug tracking system. Why aren't there useful fields like "CC" or anything other than assignee, which are searchable and can be used for me to know which bugs I should at least take a peek at?
In any case, I don't think PV's at fault in this case. jEdit's I/O threads have weird semantics w.r.t. the AWT thread. So, if you look at how a buffer is loaded, it goes like this:
. a request is posted to the I/O thread
. a separate request is posted to the AWT thread in the pool, to be run after the previous is done
BUT, the second request doesn't have anything that says it depends on the first one, at all. Which seems to imply that, somehow, the I/O thread pool halts AWT-thread requests until all I/O requests are done (which is something I noticed before, and is the reason I wrote CommonControl's WorkerThreadPool class, which BTW could be ditched for Java 1.5's thread pools).
So, you get:
. Buffer load request is queued in I/O thread pool
. Post-load request is queued in I/O thread pool, and will only be run after the previous request is done
. Buffer load request starts running
. PV starts loading and calls jEdit.closeBuffer()
. jEdit calls WaitForRequests()
. call never returns because, after load request is done, the post-load request is queued in the AWT thread and never runs, because the AWT thread is blocked.
So the long answer is that jEdit needs to be fixed. The I/O thread pool, as far as I'm concerned, is broken. Unfortunately, I can't think of a quick work-around to this problem... maybe avoiding the call to jEdit.closeBuffer()? Buffer.close() doesn't seem to do any of this crazy request tracking thing.
This hasn't happened to me for a long time.
Just took a look at this again, and it seems like we were both incorrect wrt the reason why waitForRequests() never returns. waitForRequests() first waits for completion of all non-awt requests, and then executes all the awt requests. Hence, I don't see a reason for it to block. Maybe something changed in this mechanism in the last few months? Am I wrong in my interpretation of how this works?
I've been trying the new SF tracker, and it seems to be buggy. I added a comment, changed the status to pending, and clicked Update, but my comment was not included, so I am adding it again now.
This bug hasn't happened to me in a while, and I've been using ProjectViewer and CtagsInterface the whole time. Does anyone else still experience it? If so, please attach the activity.log file from the jEdit settings directory when it happens. If not, the item can be closed as far as I am concerned.
Probably not the cause of the behavior your were seeing before, but in WorkerThreadPool::waitForRequests(), there's a call to doAWTRequests() without holding the lock, when the documentation for that function says it must be called with the lock held.
You are very right. This non-synchronized call to doAWTRequests() occurs from the AWT thread, but in principle other threads may be modifying the list of AWT requests at the same time, which is a potential for threading issues.
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).