Details

    • Type: Bug Bug
    • Status: Closed Closed
    • Priority: Critical Critical
    • Resolution: Fixed
    • Affects Version/s: 0.5
    • Fix Version/s: 0.7
    • Component/s: #develop addin
    • Labels:
      None
    • Environment:
      SVN 1412 // SVN 1439
    • Number of attachments :
      1

      Description

      SharpDevelop exhibits perplexing behavior when coding some Boo files. This only occurs when using BooBinding and not any of the other bindings (C#, VB.NET, etc), so I can only assume it is a problem with BooBinding itself. It consists of a strange error message when typing in certain .boo files created by SharpDevelop (presumably), and it looks like the linked image.

      ( see: http://img164.exs.cx/img164/1315/setupfailerror9ys.png )

      100% reproducable on my side, even when opening this particular file seperately, outside of the project but within SharpDevelop.

      Infact, here's the elementary .boo file that causes SharpDevelop to die!

        Issue Links

          Activity

          Hide
          Daniel Grunwald added a comment -

          Well... this just fixes the symptom, not the root cause.
          I really would like to know where the stack overflow occurs, but I was not able to find it.
          Debugging boo code with DebugCLR does not seem to work very well...

          I don't exactly know what ProcessMethodBodies does.
          Does it need type information about the types operating on? BooBinding does not load referenced libraries/projects; it is using the information provided by SharpDevelop. And that is loaded directly from the assembly (using ICSharpCode.SharpAssembly, not System.Reflection) and is not available to the compiler steps.

          So what seems to work with BCL types could fail with types from custom assemblies.
          That's why BooBinding does most resolving on its own, not reusing the methods from the boo compiler.
          I have implemented my own methods to infer the return type using the information available from SharpDevelop. (believe me I checked that code for possibilities of infinite recursion; I just can't find the place where the stack overflow it is happening!)

          If ProcessMethodBodiesWithDuckTyping works even when the information from the referenced assemblies is not available, this patch can be applied because ProcessMethodBodiesWithDuckTyping will do a much better job than my code.

          Show
          Daniel Grunwald added a comment - Well... this just fixes the symptom, not the root cause. I really would like to know where the stack overflow occurs, but I was not able to find it. Debugging boo code with DebugCLR does not seem to work very well... I don't exactly know what ProcessMethodBodies does. Does it need type information about the types operating on? BooBinding does not load referenced libraries/projects; it is using the information provided by SharpDevelop. And that is loaded directly from the assembly (using ICSharpCode.SharpAssembly, not System.Reflection) and is not available to the compiler steps. So what seems to work with BCL types could fail with types from custom assemblies. That's why BooBinding does most resolving on its own, not reusing the methods from the boo compiler. I have implemented my own methods to infer the return type using the information available from SharpDevelop. (believe me I checked that code for possibilities of infinite recursion; I just can't find the place where the stack overflow it is happening!) If ProcessMethodBodiesWithDuckTyping works even when the information from the referenced assemblies is not available, this patch can be applied because ProcessMethodBodiesWithDuckTyping will do a much better job than my code.
          Hide
          Arron Washington added a comment -

          Been using the addin like this for awhile (with the suggested patch I mean) and I haven't noticed any ill effects.

          Show
          Arron Washington added a comment - Been using the addin like this for awhile (with the suggested patch I mean) and I haven't noticed any ill effects.
          Hide
          Daniel Grunwald added a comment -

          If the step ProcessMethodBodiesWithDuckTyping should be used or not is another issue, the point where this bug has to be fixed is the method that overflows the stack.
          I just noticed that the bug does not happen if the property does not have a setter. In my earlier debugging sessions I ignored the setter; so that's propably the reason I did not find the method that was crashing until now.

          Show
          Daniel Grunwald added a comment - If the step ProcessMethodBodiesWithDuckTyping should be used or not is another issue, the point where this bug has to be fixed is the method that overflows the stack. I just noticed that the bug does not happen if the property does not have a setter. In my earlier debugging sessions I ignored the setter; so that's propably the reason I did not find the method that was crashing until now.
          Hide
          Daniel Grunwald added a comment -

          Fixed.
          The problem was that the 'local variable' _b = value in the setter was used to resolve B instead of the field _b. 'value' resolved to the properties type, so we got a stack overflow.
          Fields are now tried before the variable is tried to be resolved as local variable.
          Moreover, BooBinding now distinguishes between the local variables in the getter and the setter.

          Show
          Daniel Grunwald added a comment - Fixed. The problem was that the 'local variable' _b = value in the setter was used to resolve B instead of the field _b. 'value' resolved to the properties type, so we got a stack overflow. Fields are now tried before the variable is tried to be resolved as local variable. Moreover, BooBinding now distinguishes between the local variables in the getter and the setter.
          Hide
          Rodrigo B. de Oliveira added a comment -

          opening just to changed the fixed version

          Show
          Rodrigo B. de Oliveira added a comment - opening just to changed the fixed version

            People

            • Assignee:
              Daniel Grunwald
              Reporter:
              Arron Washington
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: