GRECLIPSE
  1. GRECLIPSE
  2. GRECLIPSE-1237

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

        Hide
        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
        Peter Rader added a comment -

        output of jstack

        Show
        Peter Rader added a comment - output of jstack
        Hide
        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
        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
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: