Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP

Loading…

MonoDevelop hangs with extremely high CPU usage #65

Closed
gavin-norman opened this Issue · 15 comments

2 participants

@gavin-norman
Collaborator

(I'm not sure if this is a bug in Mono-D or MonoDevelop, and I've not managed to find a 100% reproducible case yet, but will update the bug report if/when I do.)

Sometimes when the auto-completion dialog pops up (for example when typing an instance name followed by a dot), MonoDevelop hangs. It becomes completely unresponsive, and according to top is running with extremely high CPU usage (> 100% on my dual core machine). The IDE does not recover from this state and the process has to be killed.

@aBothe
Owner

hmm, seems to be an infinite resolution loop or something.. when I'll have updated the resolver we'll see if it's solved then..

Is it a special syntax construct you're using so it hangs when typing a dot?

@gavin-norman
Collaborator

Is it a special syntax construct you're using so it hangs when typing a dot?

Nothing specific that I've noticed, but I'll try to look for a pattern if it happens again.

One thing I did notice is that sometimes, once I've restarted MonoDevelop, the problem will not occur again at the same place (so it doesn't appear to be strictly syntax related).

On the other hand, sometimes I can restart the IDE several times, and try to re-type the offending piece of code several times, every time resulting in the same hang. In these latter cases I've found that typing the offending code in a different location (even just a few lines down), then cut & pasting it to the intended location, works.

No idea if that's at all helpful in working out what the problem might be!

@aBothe
Owner

Hmm, perhaps it's a concurrency problem -- so perhaps you are about to type some code, and then it reparses the code.. but then it throws because it's obstructing a foreach loop or something...we'll see :)

@gavin-norman
Collaborator

Hm it just happened again with the latest version (0.3.0).

I tried to reduce it to a simple test case, but couldn't. The bug itself was however reproducible in the very specific case in which it occurred.

  1. I copied two lines of code, one of which contained the identifier myclass_raw.
  2. I then pasted these lines of code into another location (in a different module) into a method like this: void method ( MyClass myclass )
  3. I then edited the newly pasted lines, deleting the underscore in myclass_raw, and pressing . in its place, intending to change the code to myclass.raw. At this point it hung.

raw is a valid member of MyClass, but I tested it with other identifiers and the same hang occurred.
It only occurs when the method into which it is pasted has an argument with the same name.

No idea if that description helps! I'll post more reports if it happens again...

@aBothe
Owner

Nice, I think I found the issue, and solved it in 0.3.1

@gavin-norman
Collaborator

Brilliant, I'll keep an eye out.

@gavin-norman
Collaborator

Unfortunately this just happened again. And again I couldn't reduce it to a simple test case.

Here's the situation it was occurring in.

  1. I have a base class with an abstract public method accepting a ref parameter (a struct). public abstract void func ( ref Struct s );

  2. I have a class which implements the abstract class.

  3. In the implementing class' version of func, I type s., expecting the list of members of s to pop up. At this point the IDE hangs.

(I tried the same thing without the ref, and it also happens in the same way.)

@aBothe
Owner

There's an other issue that seems to describe the same problem - did this occur again some time? Or were you able to recognize a specific pattern that lets the IDE hang?
In the other report, it's his code which lets the cpu usage rise up to the max - but unfortunately he can't show me his entire code - so I won't be able to determine where the exact point of deadlock is.

@gavin-norman
Collaborator

I have a repeatable case, which I just tried and the same bug still occurs. Unfortunately the repeatable case is in a complex project, and I've never managed to see much of a pattern in it, or to reduce it to a simple case. And all our code is far from open source here as well ;)

@aBothe
Owner

Could you say if there is a risk of circular dependency or something? So it tries to resolve one item and dies from doing it recursively because the first item depends on some other (second) item, whereas the first one depends or owns (dunno) an instance of the first one's type - confusing, but that's probably causing the headache :D

@gavin-norman
Collaborator

Well it's not a circular reference, but I did just notice something interesting about the situation which may be relevant.

Talking about the situation I described in comment 8 above. The type Struct is not imported in the module in which the abstract func is implemented, it is instead aliased in the base class.

A simplified version of the situation is:

Struct definition Struct.d:

struct Struct
{
    // ...
}

Base class Base.d:

import Struct;

class IBase
{
    protected alias .Struct Struct;

    abstract protected void func ( ref Struct s );
}

Deriving class Derived.d:

import Base;

class Derived : IBase
{
    protected void func ( ref Struct s )
    {
        // typing "s." in here causes the hang.
    }
}

Again, no idea if this is relevant, but it might help!

@aBothe
Owner

That's a known limitation of the resolver - that '.'-prefix isn't recognized so far - ok, thx for reminding me about that :)

@aBothe
Owner

Now it should work - though there's still the risk of a deadlock remaining. Still got to care about that. Nevertheless you can reinstall and test it now :)

@gavin-norman
Collaborator

Awesome! It worked :) I'm glad we managed to figure that out eventually -- it was very annoying and very obscure! I'll keep an eye out for other situations where this occurs, but I suspect that bug was the cause of the other hangs I'd experienced in the past, as I tend to use that aliasing technique quite often.

@aBothe
Owner

If you remove the leading dot from alias .Struct Struct;, it'll hang again -- it's because the resolver isn't looking if it's a circular definition - still got to fix that stuff, but nevertheless it's paying attention to the module scope dot now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.