26

You may consider this a bug report, however I'm curious if I am terribly wrong here, or if there is an explanation from Eric or someone else at Microsoft.

Update

This is now posted as a bug on Microsoft Connect.

Description

Consider the following class:

class A 
{
    public object B {
        set { }
    }
}

Here, A.B is a write-only but otherwise fine property.
Now, imagine we assign it inside of expression:

Expression<Func<A>> expr = 
    () => new A {
        B = new object { }
    };

This code makes C# compiler (both 3.5.30729.4926 and 4.0.30319.1) spit out

Internal Compiler Error (0xc0000005 at address 013E213F): likely culprit is 'BIND'.

and crash.

However, merely replacing object initializer syntax ({ }) with a constructor (( )) compiles just fine.

Full code for reproduction:

using System;
using System.Linq.Expressions;

class Test {
    public static void Main()
    {
        Expression<Func<A>> expr = 
            () => new A {
                B = new object { }
            };
    }
}

class A {
    public object B { set { } }
}

(And yes, I did hit it working on a real project.)

Community
  • 1
  • 1
Dan Abramov
  • 264,556
  • 84
  • 409
  • 511
  • 5
    Looks like a bug, indeed. Of course you could argue it *can't* be a bug since the rules for expression tree construction are not defined anywhere in the spec, so any behaviour is technically legal (including choosing to format your HDD), but I think "bug" is more succinct :) – Marc Gravell Jun 24 '11 at 17:36
  • 1
    I wonder if someone can check if this compiles on Mono. – Dan Abramov Jun 24 '11 at 17:38
  • 16
    (concentrates hard, attempting to summon Eric by sheer willpower alone) – Marc Gravell Jun 24 '11 at 17:38
  • @gaearon I can check that later (not at PC at the moment); I'm also using the preview compiler (`async`) so can check that too. – Marc Gravell Jun 24 '11 at 17:40
  • *crackle* -- paging Eric Lippert to post 6471527, Eric Lippert to post 6471527 please -- *click* – Daniel DiPaolo Jun 24 '11 at 17:41
  • Maybe the magic `@` sign will work. @Eric Lippert, you're needed here :) – Frédéric Hamidi Jun 24 '11 at 17:44
  • 1
    *“Lipperto!”*, yelled Harry with a desperate expression. – Dan Abramov Jun 24 '11 at 17:49
  • 1
    Does it behave differently if you also provide a private getter? – Joseph Yaduvanshi Jun 24 '11 at 17:50
  • 2
    @Frédéric nope, not how @replies work, can't notify anyone not involved with the thread already - http://meta.stackoverflow.com/questions/43019/how-do-comment-replies-work/43020#43020 – Daniel DiPaolo Jun 24 '11 at 17:50
  • @Fred no, because he hasn't replied ... damnit @Daniel don't get ahead of me! :p (+1) – jcolebrand Jun 24 '11 at 17:52
  • @Daniel, @jcolebrand, thanks, I wasn't aware of that. I can understand the limitation (too much noise maybe?), but that's too bad, it would make a nice feature :) – Frédéric Hamidi Jun 24 '11 at 18:00
  • 1
    @Frédéric : No, it wouldn't. There are many people with duplicate usernames. – SLaks Jun 24 '11 at 18:09
  • Unless I'm mistake, Internal Compiler Errors are _always_ bugs, no matter what crazy illegal (or, in this case, not) syntax you throw at it. – Mike Caron Jun 24 '11 at 18:18
  • 2
    I just checked and this compiles after adding a private getter returning null in Windows .NET 3.5 SP1. It compiles without the getter under Mono 2.6.7. – Joseph Yaduvanshi Jun 24 '11 at 18:34
  • I tested this as well and When VS2010 Crashed i debugged it and it returned the error: Attempted to read or write protected memory. This is often an indication that other memory is corrupt. – Alex Jun 24 '11 at 20:11

2 Answers2

8

I'm afraid I'm not Eric Lippert (Oh, but could I be so dashing...), but as a former Visual Studio languages guy who can still search the sources, I can say two things about this:

  1. Any time you see something that starts with "Internal Compiler Error" you have most definitely found a bug. That's what that error exists for, whether it's the C#, VB or C++ compiler. It's the "Oh, s**t, something just went really unexpectedly wrong!" throw-up-our-hands-and-bail-out error.

  2. Beyond that, this is definitely a bug in the C# compiler that should be reported. The code that's crashing is assuming that when you're doing an initializer on a property that there's a getter it can look at and, hey, guess what? In this case, there isn't. Oddly enough, if I change the type being constructed to some type "C" instead of "object", I don't get the crash, so I'm guessing it's a failure further up the stack (i.e. the code never should have gotten down to the point where it was looking for the property getter).

Hope this helps.

panopticoncentral
  • 1,793
  • 11
  • 22
  • Wow, thanks for the insight. In fact, first time I did the crash, it was with a custom type, not the `object` (but still using initializer syntax). If you don't get a crash, I'll update the question with another non-`object` sample. – Dan Abramov Jul 02 '11 at 06:38
0

This is what I found online related to the error,

Posted by Microsoft on 3/9/2010 at 10:58 AM

Thanks everyone for the reports. I believe that this issue has been fixed post-RC. The problem is that the C# compiler is crashing as it is tries to report an error or warning. In several cases we have seen the warning being reported is that the LIB environment variable contains an invalid path. To avoid the crash, check that your LIB environment variable contains valid paths.

Regards,

Ed Maurer Development Manager, VB and C# compilers

Dan Abramov
  • 264,556
  • 84
  • 409
  • 511
Wicked Coder
  • 1,128
  • 6
  • 8
  • 1
    Source? So we can see the context of how (if) this is related? – Marc Gravell Jun 24 '11 at 17:48
  • 1
    Source: http://connect.microsoft.com/VisualStudio/feedback/details/534059/error-cs0583-internal-compiler-error-0xc0000005-at-address-3eac16a1-likely-culprit-is-begin – Teoman Soygul Jun 24 '11 at 17:52
  • 1
    I think the error message is generic, and therefore is seen for different kind of crashes. However the issue I described seems to occur for everyone, not just me, so I doubt it has to do with LIB variable. – Dan Abramov Jun 24 '11 at 17:54