[ jEdit-devel ] [ jedit-Plugin Bugs-3382969 ] JavaSideKick Code Completion hangs badly on .length

[SourceForge.net <no...@so...>]

Plugin Bugs item #3382969, was opened at 2011-07-30 12:39
Message generated for change (Comment added) made by daleanson
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382969&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: None
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Jarek Czekalski (jarekczek)
Assigned to: Dale Anson (daleanson)
Summary: JavaSideKick Code Completion hangs badly on .length

Initial Comment:
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.

----------------------------------------------------------------------

>Comment By: Dale Anson (daleanson)
Date: 2011-09-25 14:38

Message:
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.

----------------------------------------------------------------------

Comment By: Dale Anson (daleanson)
Date: 2011-09-23 07:33

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

----------------------------------------------------------------------

Comment By: Jarek Czekalski (jarekczek)
Date: 2011-09-23 00:10

Message:
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.

----------------------------------------------------------------------

Comment By: Gerard (gerardsmyth)
Date: 2011-09-22 09:08

Message:
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.

----------------------------------------------------------------------

Comment By: michael michaud (michaudm)
Date: 2011-09-13 15:42

Message:
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

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2011-08-28 04:35

Message:
It seems it is a problem in Javasidekick

----------------------------------------------------------------------

Comment By: michael michaud (michaudm)
Date: 2011-08-26 00:26

Message:
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

----------------------------------------------------------------------

Comment By: Jarek Czekalski (jarekczek)
Date: 2011-08-10 11:09

Message:
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?

----------------------------------------------------------------------

Comment By: Matthieu Casanova (kpouer)
Date: 2011-08-09 16:24

Message:
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)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=565475&aid=3382969&group_id=588