From: SourceForge.net <no...@so...> - 2007-12-31 19:37:49
|
Bugs item #1861282, was opened at 2007-12-31 01:04 Message generated for change (Comment added) made by ezust 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: Open 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: Alan Ezust (ezust) Date: 2007-12-31 11: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 11: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 01: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 |