#1436 JavaSideKick Code Completion hangs badly on .length

closed-fixed
None
5
2011-09-25
2011-07-30
No

I was editing TextToolsComments.java, adding a line:

if (textArea.getSelection().length==0)

I couldn't finish. Before I type = (after "length") jedit hangs without any reactions to input. There's nothing left but killing it.

I can type this hard line if "Show completion popups where possible" is turned off.

Today's svn, linux, debian, openbox.

Discussion

  • Matthieu Casanova

    • status: open --> pending-works-for-me
     
  • Matthieu Casanova

    Hi, I unable to reproduce your bug, but I just fixed a deadlock in Sidekick, could you try the 1.2 version (from trunk, or you can wait for it's release)

     
  • Jarek Czekalski

    Jarek Czekalski - 2011-08-10

    The problem still exists, despite updating svns of SideKick, JavaSidekick and jEdit. I had problems today with reproducing, so I'll give now a more detailed description.

    1. Activate JavaSidekick. I dock it on the left. Without JavaSidekick activation I get no completion popups which are cause of described problem.
    2. Open TextToolsComments file and go to line 55 where textArea is declared.
    3. Insert new line after this declaration, type:
    if (textArea.get
    Nice popup must show up with names and types of textArea members.
    4. Finish the line to obtain
    if (textArea.getSelections().
    This dot is enough to have jedit hanging. I expect another popup but after a second cursor stops blinking and you know what.

    If your instance doesn't hang then what you see? Does popup pop up?

     
  • Jarek Czekalski

    Jarek Czekalski - 2011-08-10
    • status: pending-works-for-me --> open-works-for-me
     
  • michael michaud

    michael michaud - 2011-08-26

    I can confirm I could reproduce this problem.
    If I type :
    if (obj1.method(var2).
    jedit seems to enter an infinite loop after I have typed the last point (ui freezes, cpu increase to max)
    I use javasidekick
    The problem arise even if obj1, obj2 and method are does not represent real objects (no declared type)

    Michaël

     
  • Matthieu Casanova

    It seems it is a problem in Javasidekick

     
  • Matthieu Casanova

    • assigned_to: nobody --> daleanson
    • status: open-works-for-me --> open
     
  • Dale Anson

    Dale Anson - 2011-08-30
    • summary: SideKick Code Completion hangs badly on .length --> JavaSideKick Code Completion hangs badly on .length
     
  • michael michaud

    michael michaud - 2011-09-13

    This bug is very annoying because there is no other way than killing the process to escape.
    I can confirm that the bug appears with javasidekick and without any jedit plugin.
    The smallest sequence I could write which is showing the bug is
    (.().
    the following java code always freeze the application
    (id.id().

    Hope that helps

    Michaël

     
  • Gerard

    Gerard - 2011-09-22

    I have tried to look into this bug, and I think I have tracked it down to the getPossibleQualifiedCompletions method in sidekick.java.JavaCompletionFinder.

    This has a call to TextUtilities.findMatchingBracket (around line 354) which returns -1 in these hanging scenarios as there is no matching bracket, and so causes the code to get stuck in an endless loop.

    I think I have been able to resolve it by adding a specific check for this condition, and updating the loop pointers, eg

    ...
    if (paren != -1 && paren < dot) {
    j = TextUtilities.findMatchingBracket(temp, 0, paren);
    // Start addition
    if (j == -1) {
    j = paren + 1;
    i = j;
    }
    // End addition
    continue;
    }
    ....

    I am not really sure how the process works though, so this may not be the best approach, but hopefully this will help someone create a proper patch and get it released.

     
  • Jarek Czekalski

    Jarek Czekalski - 2011-09-23

    Gerard, I think you did the hardest part localizing the responsible line.

    By the way I would like to notice a possible inefficiency of a call to findMatchingBracket, which may be fixed by the same patch.

    If a file is big and correct then the matching bracket will not be found and it will take a considerable cpu time to tell this. So if it is necessary to call findMatchingBracket it would be good to limit its scope to a reasonable size, like 3 lines. In most cases 1 line would be enough.

    I wrote this without watching the code, so maybe this optimization is already done somehow.

     
  • Dale Anson

    Dale Anson - 2011-09-23

    Guys, thanks for the research on this. I should have time to look into this today.

     
  • Dale Anson

    Dale Anson - 2011-09-25

    Gerard, thanks for your fix, that was all that was needed.

    jarekczek, the inefficiency you suggest does not actually exist. At that point in the code, all that is being evaluated is a small fragment of the file, not the entire file. For example, in the case of obj1.method(). all that is being evaluated is exactly that text, not any of the rest of the file.

     
  • Dale Anson

    Dale Anson - 2011-09-25
    • status: open --> closed-fixed
     

Log in to post a comment.