Menu
▾
▴
[ jEdit-devel ] [ jedit-Bugs-1861282 ] Deadlock on startup
|
From: SourceForge.net <no...@so...> - 2008-10-08 04:51:49
|
Bugs item #1861282, was opened at 2007-12-31 11:04 Message generated for change (Comment added) made by shlomy You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1861282&group_id=588 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: severe bug Status: Pending Resolution: None Priority: 7 Private: No Submitted By: Shlomy Reinstein (shlomy) Assigned to: Nobody/Anonymous (nobody) Summary: Deadlock on startup Initial Comment: 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. ---------------------------------------------------------------------- Comment By: Shlomy Reinstein (shlomy) Date: 2008-10-08 06:51 Message: 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. ---------------------------------------------------------------------- Comment By: Shlomy Reinstein (shlomy) Date: 2008-10-07 23:28 Message: 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? ---------------------------------------------------------------------- Comment By: Marcelo Vanzin (vanza) Date: 2008-03-28 08:36 Message: 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. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2007-12-31 21:37 Message: 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. ---------------------------------------------------------------------- Comment By: Alan Ezust (ezust) Date: 2007-12-31 21:37 Message: 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. ---------------------------------------------------------------------- Comment By: Shlomy Reinstein (shlomy) Date: 2007-12-31 11:06 Message: 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. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=100588&aid=1861282&group_id=588 |