IDEA Hangs Scanning a Particular Directory + Other Anomalous Behaviors

Hi,

This morning when I started IDEA, no files were reopened from the previous day's session and the directory that was open (expanded) in the Project window showed "loading..." (in grey). All other directories can be opened (and closed, repeatedly) without problem. There is no CPU usage. I've quit and restarted several times. I've resynchronized the project several times. I've closed and reopened the project. All to no avail. The rest of the UI seems responsive and all the other UI state (besides open files sometimes) is remembered from one session to the next.

I can use "File -> Open File..." to open files ... sometimes. When I open files this way the structure view is always displayed and properly populated but the file contents itself sometimes does and sometimes does not appear in the editing area.

This is happening with Selena 7255 under JDK 1.5.0_12 and 1.6.0_02. Switching to 7269 is the same. (Furthermore 7269 requires JDK 1.6 and the slow scrolling but persists under both builds, so that's not an option for real work. Furthermore, 7269 has exhibited other more severe and less repeatable symptoms.)

Lastly, over the many times I've now shut down, reconfigured (changing build and / or JDK) and restarted, I've seen other non-reproducible problems, mostly of the form of non-actions (other hangs, failure to open files, etc.). Because I cannot repeat them, I cannot accurately describe them.

The only thing that's 100% reproducible is the "loading ..." hang on that one source directory.

I'm at my wits end. I can scarcely work with IDEA at all like this.

(And if anyone is going to suggest I file a bug report, then you're going to have to tell me how to categorize and characterize it, 'cause I have no idea what's up with this.)

Randall Schulz

29 comments
Comment actions Permalink

Here are some other anomalies I've discovered trying to use 7269:

- Open file tabs don't indicate when a file is modified.
- No inspections are occurring: The status indicator stays blank (grey, no "eye" icon) and the hover message is "Performing code analysis; No errors or warning found so far."


RRS

0
Comment actions Permalink

The Settings dialog will not activate (does not appear).

Furthermore, after clicking on the wrench icon, IDEA is now entirely unresponsive. No GUI element reacts to clicking nor is there any response to any use of the keyboard. Redrawing after shading or switching windows does work.

RRS

0
Comment actions Permalink

For situtations where IDEA stops responding you may want to consider opening up a JIRA and attaching a thread dump:

You can obtain one by one of the following:
-Ctrl-Break on console
-"jps" tool
-http://tmitevski.users.mcs2.netarray.com/stacktrace/app/launch.jnlp

Omair

0
Comment actions Permalink

I cleaned out everything in ~/.IntelliJIdea70/system except .../jetConnect/* and the symptoms remain unchanged (and the more I try to use it the more anomalies I see).

I've mostly stuck to 7269 after the original experimentation—it (7269) seemed less flakey than 7255, but that could just have been the randomness momentarily favoring it (things are certainly looking pretty random).

Anyway, I really need to fix this. What sort of diagnostic procedures should I carry out? Is there anything in ~/.IntelliJIdea70/config that I can safely remove (without having to endure a lot of reconfiguration)?

Any help or suggestions would be appreciated. I'm mostly high and dry, right now...

Thanks.

Randall Schulz

0
Comment actions Permalink

I might add, since it's not summarized as such in what I've written previously:

- The symptoms occur on #7255 and #7269
- With #7255 the symptoms occur both under JDK 1.5.0_12 and 1.6.0_02
- The symptom appeared

This suggests to me that the problem not in the IDEA code nore the JDK. That seems to leav only the project definition files (*.ipr, *.iws, *.iml) or the files in ~/IntellJIdea70/config. Does that reasoning seem sound?

-==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==-

New information: Apparently a very large number of exceptions are being generated. I keep all the output from standard out and standard error in a log file and assigned a new one for IDEA 7.

Surprisingly, when I looked just now, the most recent exception reported was a StackOverflowError There were 1024 lines in the backtrace In fact, there are quite a few of these SOEs, interspersed with lines or groups of lines such as these:


or


In fact, one symptom (among many) that I'm seeing is a sporadic failure to update the Structure window.


Also present between stack traces are these lines:



Another odd symptom are several backtraces for "java.lang.Throwable" (!?)

Other non-backtrace diagnostics include:


-==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==- -==-

What does it all mean?

0
Comment actions Permalink

Randall Schulz wrote:

What does it all mean?


Remove/disable your plugins (~/IntellJIdea70/config/plugins) one by one and see if it
helps. And next time please post all the actual stack traces, or even better the whole log
file. What was the last StackOverflowError you fixed when just being told there is one?

Sascha

0
Comment actions Permalink

Hello Randall,

This morning when I started IDEA, no files were reopened from the
previous day's session and the directory that was open (expanded) in
the Project window showed "loading..." (in grey).


This behavior is always caused by an exception which is reported in the status
bar popup and written to idea.log. The exception stacktrace is what we need
to investigate and resolve this problem.

--
Dmitry Jemerov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com/
"Develop with Pleasure!"


0
Comment actions Permalink

OK. Here's the log that resulted simply from starting up #7269 this morning. It's almost 29,000 lines long.

Note: The first exception is caused by SimpleUML and is reported via the on-screen pop-up ("Blame simpleUML"). This has been going on ever since I upgraded to v7 EA. I reported it on the Plug-ins list a couple of weeks ago. The symptoms I've been seeing for the past two days are entirely new.

RRS



Attachment(s):
Idea7-log-2007-09-09.01.zip
0
Comment actions Permalink

One of these exceptions is produced every time I switch from another application to IDEA. This is always from a different virtual screen to the one IDEA's on (it's there alone, window maximized), so a complete redraw is required, which does work.

RRS



Attachment(s):
Idea7-log-2007-09-09.02.zip
0
Comment actions Permalink

Here's the log from starting up IDEA, then doing nothing but expand that one source directory in the Project pane that always hangs on "loading ...", this time without switching windows other than to switch away from IDEA to complete the log file capture in a shell window.

RRS



Attachment(s):
Idea7-log-2007-09-09.03.zip
0
Comment actions Permalink

I removed all my plug-ins and everything in ~/IntellJIdea70/system (except the log/, LocalHistory/ and jetConnect/ directories) and captured the output from initial launch all the way through the appearance of the Structure and Project panes. This time no output appeared at all until I expanded that directory that always hangs on "loading ..."

RRS



Attachment(s):
Idea7-log-2007-09-09.04.zip
0
Comment actions Permalink

The SOE looks like a known problem: http://www.jetbrains.net/jira/browse/IDEADEV-18472

Though the chances to get it fixed probably rise when you can provide some example code
that reproduces the problem because it doesn't seem to be very common. Most likely it's
caused by one or more classes in the package that doesn't expand.

Sascha

PS: The other log entries you were seeing came from some plugins, namely SimpleUML and
EditorTree (which has just been updated).

0
Comment actions Permalink

What do you mean by "example code?" This happens with no source files open (and in large number of other circumstances) in an unpredictable but frequent manner. It started yesterday morning when I launched 7255 (not nearly for the first time) and is present in 7269, too (all the stack traces I posted are from 7269).

It seems that wherever the bug lies, the condition that triggers it has something to do with my config (as in ~/IntelliJIdea70/config/*) or my project definition files. I looked at the latter and so nothing obviously mangled.

Let me again emphasize: This happens A LOT and IDEA is barely usable as it stands. It is the the opposite of rare, uncommon or infrequent.

PS: The other log entries you were seeing came from
some plugins, namely SimpleUML and
EditorTree (which has just been updated).


As you saw in the last trace I posted, this happens when zero plug-ins are in my .../config/plugins directory.

Surely there is something someone can to do help me diagnose or repair this situation? For practical purposes, I have no IDE at this point.


Randall Schulz

0
Comment actions Permalink

Sorry for having bothered you with such useless information. You'll surely find someone else to help.

S.

0
Comment actions Permalink

Sarcasm?

Did I deserve that? Was my reply inappropriate, somehow?

RRS

0
Comment actions Permalink

I believe I misunderstood what you were saying.

I removed all the .java files (and one ".jsrc" file — I use these to hold code that I don't want compiled, often 'cause it's erroneous, but that don't want to delete). This changed the symptom. Now the remaining directory contents appear when I expand that directory but the top line of the listing is still "loading ..." and the SOE still occurs.

Then I removed all the other files in that directory and the symptom (including the SOE) no longer occur. Actually, after I tried, I thought to check for hidden files, and there were two: .pjrc and .xrh. They apparently are not the source of the problem...

Then I put back the Java files only and the symptom (and the SOE) return.

What sort of sensitivity could it be that both Java sources and non-Java source files could trigger it?

This isn't a small directory and trying to find the culprit one file at a time is going to be very tedious...

Randall Schulz

0
Comment actions Permalink

I had something similar happening with 7255 and I closed IDEA, deleted all the caches and the problem went away.

But I think you've stated that you already tried that...?

0
Comment actions Permalink

More information:

Starting with only the Java source files in that directory, I removed all those that had modification times subsequent to the appearance of the symptom. That yielded a further variation:

- The existing Java files are shown in the expanded directory
- The line showing "loading ..." remains but appeared first above the Java classes but then moved to the bottom
- The SOE still occurs

Randall Schulz

0
Comment actions Permalink

Yes, I did, numerous times. If you'll note my other replies from this morning, I've been trying to narrow down the field of culprit files. By removing certain files, I could change the manifestation of the problem but not eliminate it entirely.

When I got to the point of having only Java source files and only those older than the onset of the symptom and (a variation on) the problem was still present, I saw your post. So I deleted all the caches and now the symptom is gone!

So it appears there's a particular file (among the 10 that were new enough to have triggered the problem). Furthermore, once that file is scanned, some cache picks up some bad information and from then on, it's "stuck."

Next I'll try to find which of those ten files is the culprit.

Thanks Sascha and K.

Randall Schulz

0
Comment actions Permalink

I found the culprit.

Now what? Attach it to the JIRA you pointed me to? Naturally, it does not stand alone and I cannot send all the source of my project (it's fairly large).

Again, thanks for the hint.


Randall Schulz

0
Comment actions Permalink

I think I know the problem. I had a hunch, made a tiny change and now that file can be loaded without triggering the problem.

Here's what I changed:

Old (caused problem):


New (no SOE or other symptoms):


Can you spot the difference? The old, problem-triggering code has two non-ISO 8859-1 characters, the chevrons: « »

Is it a no-no to put non-ASCII characters in my Java source? Am I supposed to use those hideous, ugly \u#### escapes?


Randall Schulz

0
Comment actions Permalink

I scanned all my sources looking for non-ASCII characters and found several, including a few other uses of the chevrons (« and »). None of those other occurrences seem to trigger this problem.

The only other thing that I can think is notable about the file that does trigger the problem is that the non-ASCII string characters are in a nested class. It is a "static final class ..." that "implements Comparable<...>"


RRS

0
Comment actions Permalink

OK. That's not actually it.

I added files back into that directory, resynchronizing after each one until the SOE occurred and the new file failed to appear in the directory listing. This allowed me to identify the culprit file.

Then I looked at that file for possible anomalies. I thought the non-ASCII characters might have something to do with it, so I replaced them with ASCII characters and re-synchronized the directory. When I did that, the SOE did not occur and the file appeared inthe directory list. I could open it and no other symptoms that I'd seen before were evident. Admittedly, I did not proceed to do any real work at that point, but at least the inspections completed normally, which they did not before when I got to the file via File -> Open File...

So while the non-ASCII character in the string literal in the nested class may have something to do with it, even when those non-ASCII characters are not present, the initial directory scan still gets the SOE.


I experimented with other variations on the problematic file. I concentrated on the nested class. After several variations, I removed the "implements" clause and the SOE no longer occurred and the initial directory scan succeeded. The (nested) class intro was this:

    {
        ...
    }
]]>



The non-ASCII characters are still not present (i.e., I did not add them back).


Randall Schulz

0
Comment actions Permalink

Randall Schulz wrote:

Sarcasm?

Did I deserve that? Was my reply inappropriate, somehow?

RRS


It may have been unintentional, but the way you posted and answered was not really a
constructive way to get help fast. Namely:

- Java has stacktraces for a reason: to locate errors. Especially if you don't know what
they mean, if in doubt, post the stacktrace rather than pages of your own theories. My
first reply may have come across a bit harsh, but only because you made those willing to
help read through lots of text without any particularly useful information. I think a Java
programmer (and EAP user) can be expected to know what's important to locate an error.

- The first stacktraces you posted, are related to the mentioned plugins. This can be
seen at first glance, especially when you know what plugins are installed in your system.
I did not however suggest that they caused your actual problem.

- And finally, I do not need a definition of A LOT. I know how it feels to be in such a
situation, but there's no need to jump on those who voluntarily try to help. There's a
good chance to achieve the opposite.


Sascha

PS: No hard feelings - you'll find a way to solve your problem in a post below.

0
Comment actions Permalink

Randall Schulz wrote:

I experimented with other variations on the problematic file. I concentrated on the nested class. After several variations, I removed the "implements" clause and the SOE no longer occurred and the initial directory scan succeeded. The (nested) class intro was this:

     static
>     final
>     class       NameRef
> //  implements  Comparable
>     {
>         ...
>     }
> ]]>


Your problem is not reproducible with just that information. There must be more from its
context (or contents) that's relevant to trigger the error.

However, I can reliably reproduce the same SOE with this code:

public class Z implements Comparator { static final class NameRef implements java.lang.Comparable]]> {
public int compareTo(NameRef o) {
return 0;
}
}

public int compare(NameRef o1, NameRef o2) {
return 0;
}
}

It may not exactly reflect your code, but it's a start to file a proper JIRA request that
has a chance to be fixed. Good luck.

Sascha

0
Comment actions Permalink

I did post stack traces—several of them.

And I've gotten rather little real help with this. (The JIRA you pointed me to contained nothing but a stack trace. No information about context whatsoever. What good is that? It certainly doesn't help anyone without access to the source.)

I have identified the problem as best I can. I've spent over two days doing almost nothing but try to diagnose this crippling problem. I attached the information I found to the JIRA you specified.

RRS

0
Comment actions Permalink

I'm not going to discuss this further. This is getting ridiculous.

S.

0
Comment actions Permalink

Why are you expressing annoyance? I'm the one with the problem, the wasted time and very little help solving it.

RRS

0
Comment actions Permalink

Thanks Sascha,
And thanks Randall, for trying.
I am now elbow deep in the code fixing this.

--
regards,
--
Alexey Kudravtsev
Software Developer
JetBrains, Inc, http://www.jetbrains.com
"Develop with pleasure!"

"Sascha Weinreuter" <sascha.weinreuter@NOSPAM-cit.de> wrote in message
news:fc4d7h$2oc$2@is.intellij.net...

Randall Schulz wrote:

>> I experimented with other variations on the problematic file. I
>> concentrated on the nested class. After several variations, I removed the
>> "implements" clause and the SOE no longer occurred and the initial
>> directory scan succeeded. The (nested) class intro was this:
>>
>>

>     static
>>     final
>>     class       NameRef
>> //  implements  Comparable
>>     {
>>         ...
>>     }
>> ]]>

>

Your problem is not reproducible with just that information. There must be
more from its context (or contents) that's relevant to trigger the error.

>

However, I can reliably reproduce the same SOE with this code:

>

public class Z<T extends Z.NameRef> implements Comparator<T> {

>

static final class NameRef implements java.lang.Comparable<T.NameRef> {
public int compareTo(NameRef o) {
return 0;
}
}

>

public int compare(NameRef o1, NameRef o2) {
return 0;
}
}

>

It may not exactly reflect your code, but it's a start to file a proper
JIRA request that has a chance to be fixed. Good luck.

>

Sascha



0

Please sign in to leave a comment.