GRECLIPSE

compiler freezing on projects with classpatherrors

Details

  • Type: Bug Bug
  • Status: Resolved Resolved
  • Priority: Critical Critical
  • Resolution: Cannot Reproduce
  • Affects Version/s: 2.5.2.Release
  • Fix Version/s: 2.8.0.Release
  • Component/s: Compiler Integration
  • Labels:
  • Environment:
    linux, sts-eclipse
  • Number of attachments :
    1

Description

After 36 classpath problems the build-progress freezes and the build can't be aborted.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andy Clement added a comment -

If it is hanging, can you try to collect a stack trace to show what it is up to? use 'jps' to get the process id, then 'jstack' to get a stack for that process. thanks.

Show
Andy Clement added a comment - If it is hanging, can you try to collect a stack trace to show what it is up to? use 'jps' to get the process id, then 'jstack' to get a stack for that process. thanks.
Hide
Permalink
Peter Rader added a comment -

output of jstack

Show
Peter Rader added a comment - output of jstack
Hide
Permalink
Andrew Eisenberg added a comment -

My guess is that things are not hanging here, but just progressing really, really slowly. In older versions of the groovy compiler, unresolved classes would not be cached. So, every time an unresolvable class was found, even if the compiler had just tried to resolve it, another resolve attempt would occur. Resolve attempts are very, very slow, especially when they fail.

With later versions of 1.8.6, and 2.0, we are now caching unresolved classes and this situation should be much slower.

Is this still a problem for you? If so, there may be something else going on.

Show
Andrew Eisenberg added a comment - My guess is that things are not hanging here, but just progressing really, really slowly. In older versions of the groovy compiler, unresolved classes would not be cached. So, every time an unresolvable class was found, even if the compiler had just tried to resolve it, another resolve attempt would occur. Resolve attempts are very, very slow, especially when they fail. With later versions of 1.8.6, and 2.0, we are now caching unresolved classes and this situation should be much slower. Is this still a problem for you? If so, there may be something else going on.
Hide
Permalink
Andrew Eisenberg added a comment -

No response from original reporter. Resolving because cannot reproduce. Problem could also come about from limited memory on the heap causing thrashing.

Show
Andrew Eisenberg added a comment - No response from original reporter. Resolving because cannot reproduce. Problem could also come about from limited memory on the heap causing thrashing.

People

  • Assignee:
    Andrew Eisenberg
    Reporter:
    Peter Rader
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: