#107 TaskList exception on project change

closed-accepted
None
6
2012-01-19
2012-01-17
No

TaskList throws exceptions on project change.

Steps to reproduce:
1 Download jedit daily 2012-01-16
2 Run it with new settings dir
3 Download plugins ProjectViewer 3.2.0 and TaskList
4 Replace TaskList with svn version
5 Have PV docked at the left, and TaskList at the bottom. Both should be active.
6 Create 2 projects: A and B. A contains 1 file test.txt, B contains 1 file test2.txt. Fill both files with 2 lines of text.
7 Choose project A
8 Choose project B - notice files closing and opening with project change
9 Choose project A again

I get exceptions which vary from time to time. Full log attached. No exceptions on stable TaskList.

Discussion

  • Jarek Czekalski

    Jarek Czekalski - 2012-01-17

    full log

     
  • Dale Anson

    Dale Anson - 2012-01-17

    Jarek, I can't seem to reproduce this, but I think it is because I'm trying to use the buffer before it is loaded. I checked in what I think is a fix for this, would you give it a try, please, and see if you still see the error?

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-01-18

    Seems to hang on waitForRequests

    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: java.lang.InterruptedException
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at java.lang.Object.wait(Native Method)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at java.lang.Object.wait(Object.java:485)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at org.gjt.sp.util.WorkThreadPool.waitForRequests(WorkThreadPool.java:169)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at org.gjt.sp.jedit.io.VFSManager.waitForRequests(VFSManager.java:231)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at tasklist.TaskListPlugin.setMode(TaskListPlugin.java:714)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at tasklist.AbstractTreeTaskList$Runner.buildTreeModel(AbstractTreeTaskList.java:308)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at tasklist.AbstractTreeTaskList$Runner.doInBackground(AbstractTreeTaskList.java:185)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at tasklist.AbstractTreeTaskList$Runner.doInBackground(AbstractTreeTaskList.java:143)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at common.swingworker.SwingWorker$1.call(SwingWorker.java:277)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at java.util.concurrent.FutureTask.run(Unknown Source)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at common.swingworker.SwingWorker.run(SwingWorker.java:316)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
    08:28:04 [SwingWorker-pool-29945686-thread-6] [error] WorkThreadPool: at java.lang.Thread.run(Unknown Source)

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-01-18

    But this seems to be close to a fix, because when replacing this blocking call with something as dumb as this:

    while(!buffer.isLoaded()) {
    ;
    }

    the exception is gone. Loading a project takes ages, but no errors appear.

    By the way, 2 tabs sneaked into these lines.

     
  • Dale Anson

    Dale Anson - 2012-01-18

    I considered a 'while' loop like that, but it scares me. I think I'll look into Matthieu's suggestion to use a work thread pool.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-01-18

    I managed to avoid exceptions by wrapping a call to Buffer.setMode() into Swing.invokeAndWait. According to the documentation this method should not be called from non-edt threads. But I still notice race conditions, which cause some files being unseen by TaskList dockable (Open Files tab). Then I need to refresh using a button. Fixing this would require more thorough analysis of how the parsing is triggerd, which I cannot afford at the moment. Pressing "refresh" is an acceptable workaround for me.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-01-18

    One more thing: I don't see any readLock in the code and I now get exceptions from parseBufferByLines.

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-01-19

    waitUntilLoaded() patch

     
  • Jarek Czekalski

    Jarek Czekalski - 2012-01-19

    I attached a patch serving as a Buffer.waitUntilLoaded() method. When this patch is applied, the bug is unreproducible, even without wrapping setMode.

     
  • Alan Ezust

    Alan Ezust - 2012-01-19
    • labels: 2748066 -->
     
  • Alan Ezust

    Alan Ezust - 2012-01-19

    moving to plugin patches tracker

     
  • Dale Anson

    Dale Anson - 2012-01-19
    • status: open --> closed-accepted
     
  • Dale Anson

    Dale Anson - 2012-01-19

    The patch seems to work fine, although I couldn't reproduce the problem in the first place. At least, it doesn't seem to cause any problems and if you're seeing good results, I'll commit the code.

    About readLocks in parseBufferByLines, TaskList doesn't need to get a readLock since it is done in the JEditBuffer.getLineText method already.

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks