INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

[pj]

(Was originally, probably wrongly, posted to the vc subgroup.)
(This doesn't appear to be a c# problem, but a problem with a bug in
the Visual Studio c# compiler, but, any help will be welcome...)


Oh, I forgot to list the error messages; I would be delighted if
someone could explain how to deduce which line number in which file is
the one that the VC compiler cannot handle. Actually I'm using C#, but
the only post I could find about INTERNAL ERROR had an annotation
saying the problem is the vc compiler. Unfortunately it was from a
year ago and had no resolution. What do other people do when they hit
compiler bugs ? Perhaps you others know how to decode this information
to find out what file and line number is confusing the compiler ?

************* QUOTE INFORMATIONAL MESSAGES BELOW *************


Internal Compiler Error (0xc0000005 at address 5315C743): likely
culprit is 'BEGIN'.

An internal error has occurred in the compiler. To work around this
problem, try simplifying or changing the program near the locations
listed below. Locations at the top of the list are closer to the point
at which the internal error occurred.



Internal Compiler Error: stage 'BEGIN'

[Chris R. Timmons]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

peterjohannsen@ hotmail.com (pj) wrote in
news:127ce4a9.0 309232126.25cd2 0ca@posting.goo gle.com:
[color=blue]
> (Was originally, probably wrongly, posted to the vc subgroup.)
> (This doesn't appear to be a c# problem, but a problem with a
> bug in the Visual Studio c# compiler, but, any help will be
> welcome...)
>
>
> Oh, I forgot to list the error messages; I would be delighted if
> someone could explain how to deduce which line number in which
> file is the one that the VC compiler cannot handle. Actually I'm
> using C#, but the only post I could find about INTERNAL ERROR
> had an annotation saying the problem is the vc compiler.
> Unfortunately it was from a year ago and had no resolution. What
> do other people do when they hit compiler bugs ? Perhaps you
> others know how to decode this information to find out what file
> and line number is confusing the compiler ?
>
> ************* QUOTE INFORMATIONAL MESSAGES BELOW *************
>
>
> Internal Compiler Error (0xc0000005 at address 5315C743): likely
> culprit is 'BEGIN'.
>
> An internal error has occurred in the compiler. To work around
> this problem, try simplifying or changing the program near the
> locations listed below. Locations at the top of the list are
> closer to the point at which the internal error occurred.
>
>
>
> Internal Compiler Error: stage 'BEGIN'[/color]

pj,

I've never run into any Internal Compiler Errors with C#. Two
possible causes that come to mind are: 1) you've got some really
strange C# code or, 2) your installation of .Net is corrupted in some
way.

To cover possibility #1, if the error is reproducible, post some code
that demonstrates the problem.

For possibility #2, you might try re-installing VS.NET or the SDK
(whichever one you're using). I've heard of cases where "lingering
pieces" of a beta version of VS.NET (or the SDK) caused all kinds of
strange problems when the final version of the software was installed
over it.


Hope this helps.

Chris.
-------------
C.R. Timmons Consulting, Inc.

http://www.crtimmonsinc.com/

[Christoph Nahr]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj) wrote:
[color=blue]
>(Was originally, probably wrongly, posted to the vc subgroup.)
>(This doesn't appear to be a c# problem, but a problem with a bug in
>the Visual Studio c# compiler, but, any help will be welcome...)[/color]

This group covers compiler issues as well as language issues so your
post fits right in.
[color=blue]
>What do other people do when they hit
>compiler bugs ? Perhaps you others know how to decode this information
>to find out what file and line number is confusing the compiler ?[/color]

Don't know, and it's not my job. When a compiler generates an
internal error (I think I actually got one in the 1.0 framework, once)
I look at the error message and try to change things around until the
code compiles. Moreover, you should let the compiler makers (i.e.
Microsoft) know if they aren't alreay aware of the bug. That's all.
--

http://www.kynosarges.de

[pj]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

Christoph Nahr <christoph.nahr @kynosarges.de> wrote in message news:<hl13nvoj6 neuh5bq86jcorji c2l6139l7l@4ax. com>...[color=blue]
> On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj) wrote:
>[color=green]
> >(Was originally, probably wrongly, posted to the vc subgroup.)
> >(This doesn't appear to be a c# problem, but a problem with a bug in
> >the Visual Studio c# compiler, but, any help will be welcome...)[/color]
>
> This group covers compiler issues as well as language issues so your
> post fits right in.
>[color=green]
> >What do other people do when they hit
> >compiler bugs ? Perhaps you others know how to decode this information
> >to find out what file and line number is confusing the compiler ?[/color]
>
> Don't know, and it's not my job. When a compiler generates an
> internal error (I think I actually got one in the 1.0 framework, once)
> I look at the error message and try to change things around until the
> code compiles. Moreover, you should let the compiler makers (i.e.
> Microsoft) know if they aren't alreay aware of the bug. That's all.[/color]


I guess here you cut to the heart of the problem. It also isn't my job
to debug the C# compiler, and if the compiler writers couldn't be
bothered to tell me in what file and line the problem is, I'm less
inclined to work hard at debugging it. If they told me at least in
what file the problem was, I might be more inclined to try; but, as I
understand it, they're telling me, "there is something in your code we
can't handle; change your code". I am reluctant to start randomly
permuting random parts of the code (for fear that that will be a huge
time sink of low reward), so it is easiest for me to rollback to a
previous day's version, and redesign and rewrite recent code. Of
course, then I avoid diagnosing the bug entirely.

[Daniel O'Connell]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?


"pj" <peterjohannsen @hotmail.com> wrote in message
news:127ce4a9.0 309241322.3ce10 91c@posting.goo gle.com...[color=blue]
> Christoph Nahr <christoph.nahr @kynosarges.de> wrote in message[/color]
news:<hl13nvoj6 neuh5bq86jcorji c2l6139l7l@4ax. com>...[color=blue][color=green]
> > On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj) wrote:
> >[color=darkred]
> > >(Was originally, probably wrongly, posted to the vc subgroup.)
> > >(This doesn't appear to be a c# problem, but a problem with a bug in
> > >the Visual Studio c# compiler, but, any help will be welcome...)[/color]
> >
> > This group covers compiler issues as well as language issues so your
> > post fits right in.
> >[color=darkred]
> > >What do other people do when they hit
> > >compiler bugs ? Perhaps you others know how to decode this information
> > >to find out what file and line number is confusing the compiler ?[/color]
> >
> > Don't know, and it's not my job. When a compiler generates an
> > internal error (I think I actually got one in the 1.0 framework, once)
> > I look at the error message and try to change things around until the
> > code compiles. Moreover, you should let the compiler makers (i.e.
> > Microsoft) know if they aren't alreay aware of the bug. That's all.[/color]
>
>
> I guess here you cut to the heart of the problem. It also isn't my job
> to debug the C# compiler, and if the compiler writers couldn't be
> bothered to tell me in what file and line the problem is, I'm less
> inclined to work hard at debugging it. If they told me at least in
> what file the problem was, I might be more inclined to try; but, as I
> understand it, they're telling me, "there is something in your code we
> can't handle; change your code". I am reluctant to start randomly
> permuting random parts of the code (for fear that that will be a huge
> time sink of low reward), so it is easiest for me to rollback to a
> previous day's version, and redesign and rewrite recent code. Of
> course, then I avoid diagnosing the bug entirely.[/color]

Do other errors come up? Usually a ICE is caused by major confusion IN the
compiler and is often not due to a specific place(or it is impossible to
tell where the problem is occuring), however the other errors displayed in
the compile should give you hints of where you need to look.
Almost every ICE I've seen has been due to code with questionable
correctness (I've generated atleast two due to some stupid constructs of my
own over the years), however it is possibly due to legally correct code that
the compiler doesn't handle.
Examine the errors and see if you can find something that looks strange,
finding the problem is important to the community as a whole, not just
Microsoft.

[pj]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

Christoph Nahr <christoph.nahr @kynosarges.de> wrote in message news:<hl13nvoj6 neuh5bq86jcorji c2l6139l7l@4ax. com>...[color=blue]
> On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj) wrote:
>[color=green]
> >(Was originally, probably wrongly, posted to the vc subgroup.)
> >(This doesn't appear to be a c# problem, but a problem with a bug in
> >the Visual Studio c# compiler, but, any help will be welcome...)[/color]
>
> This group covers compiler issues as well as language issues so your
> post fits right in.
>[color=green]
> >What do other people do when they hit
> >compiler bugs ? Perhaps you others know how to decode this information
> >to find out what file and line number is confusing the compiler ?[/color]
>
> Don't know, and it's not my job. When a compiler generates an
> internal error (I think I actually got one in the 1.0 framework, once)
> I look at the error message and try to change things around until the
> code compiles. Moreover, you should let the compiler makers (i.e.
> Microsoft) know if they aren't alreay aware of the bug. That's all.[/color]


I guess here you cut to the heart of the problem. It also isn't my job
to debug the C# compiler, and if the compiler writers couldn't be
bothered to tell me in what file and line the problem is, I'm less
inclined to work hard at debugging it. If they told me at least in
what file the problem was, I might be more inclined to try; but, as I
understand it, they're telling me, "there is something in your code we
can't handle; change your code". I am reluctant to start randomly
permuting random parts of the code (for fear that that will be a huge
time sink of low reward), so it is easiest for me to rollback to a
previous day's version, and redesign and rewrite recent code. Of
course, then I avoid diagnosing the bug entirely.

[Daniel O'Connell]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?


"pj" <peterjohannsen @hotmail.com> wrote in message
news:127ce4a9.0 309241322.3ce10 91c@posting.goo gle.com...[color=blue]
> Christoph Nahr <christoph.nahr @kynosarges.de> wrote in message[/color]
news:<hl13nvoj6 neuh5bq86jcorji c2l6139l7l@4ax. com>...[color=blue][color=green]
> > On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj) wrote:
> >[color=darkred]
> > >(Was originally, probably wrongly, posted to the vc subgroup.)
> > >(This doesn't appear to be a c# problem, but a problem with a bug in
> > >the Visual Studio c# compiler, but, any help will be welcome...)[/color]
> >
> > This group covers compiler issues as well as language issues so your
> > post fits right in.
> >[color=darkred]
> > >What do other people do when they hit
> > >compiler bugs ? Perhaps you others know how to decode this information
> > >to find out what file and line number is confusing the compiler ?[/color]
> >
> > Don't know, and it's not my job. When a compiler generates an
> > internal error (I think I actually got one in the 1.0 framework, once)
> > I look at the error message and try to change things around until the
> > code compiles. Moreover, you should let the compiler makers (i.e.
> > Microsoft) know if they aren't alreay aware of the bug. That's all.[/color]
>
>
> I guess here you cut to the heart of the problem. It also isn't my job
> to debug the C# compiler, and if the compiler writers couldn't be
> bothered to tell me in what file and line the problem is, I'm less
> inclined to work hard at debugging it. If they told me at least in
> what file the problem was, I might be more inclined to try; but, as I
> understand it, they're telling me, "there is something in your code we
> can't handle; change your code". I am reluctant to start randomly
> permuting random parts of the code (for fear that that will be a huge
> time sink of low reward), so it is easiest for me to rollback to a
> previous day's version, and redesign and rewrite recent code. Of
> course, then I avoid diagnosing the bug entirely.[/color]

Do other errors come up? Usually a ICE is caused by major confusion IN the
compiler and is often not due to a specific place(or it is impossible to
tell where the problem is occuring), however the other errors displayed in
the compile should give you hints of where you need to look.
Almost every ICE I've seen has been due to code with questionable
correctness (I've generated atleast two due to some stupid constructs of my
own over the years), however it is possibly due to legally correct code that
the compiler doesn't handle.
Examine the errors and see if you can find something that looks strange,
finding the problem is important to the community as a whole, not just
Microsoft.

[Grant Richins [MS]]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

Chris is right on. However, based on the error message I would suspect the
problem is more likely to be caused your command-line options/project
settings, so you'll need to include those in your repro.

As a side note we've discovered a lot of bugs in the compiler's incremental
compilation feature and generally recommend against using it for this very
reason.

--
--Grant
This posting is provided "AS IS" with no warranties, and confers no rights.

[Grant Richins [MS]]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

Chris is right on. However, based on the error message I would suspect the
problem is more likely to be caused your command-line options/project
settings, so you'll need to include those in your repro.

As a side note we've discovered a lot of bugs in the compiler's incremental
compilation feature and generally recommend against using it for this very
reason.

--
--Grant
This posting is provided "AS IS" with no warranties, and confers no rights.

[Willy Denoyette [MVP]]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

It's not clear to me what compiler VC++ or C# you are talking about, moreover you should mention the compilers version number.

Willy.

[Willy Denoyette [MVP]]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

It's not clear to me what compiler VC++ or C# you are talking about, moreover you should mention the compilers version number.

Willy.

[pj]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message news:<n6ocb.567 281$Ho3.103168@ sccrnsc03>...[color=blue]
> "pj" <peterjohannsen @hotmail.com> wrote in message
> news:127ce4a9.0 309241322.3ce10 91c@posting.goo gle.com...[color=green]
> > Christoph Nahr <christoph.nahr @kynosarges.de> wrote in message[/color]
> news:<hl13nvoj6 neuh5bq86jcorji c2l6139l7l@4ax. com>...[color=green][color=darkred]
> > > On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj) wrote:
> > >
> > > >(Was originally, probably wrongly, posted to the vc subgroup.)
> > > >(This doesn't appear to be a c# problem, but a problem with a bug in
> > > >the Visual Studio c# compiler, but, any help will be welcome...)
> > >
> > > This group covers compiler issues as well as language issues so your
> > > post fits right in.
> > >
> > > >What do other people do when they hit
> > > >compiler bugs ? Perhaps you others know how to decode this information
> > > >to find out what file and line number is confusing the compiler ?
> > >
> > > Don't know, and it's not my job. When a compiler generates an
> > > internal error (I think I actually got one in the 1.0 framework, once)
> > > I look at the error message and try to change things around until the
> > > code compiles. Moreover, you should let the compiler makers (i.e.
> > > Microsoft) know if they aren't alreay aware of the bug. That's all.[/color]
> >
> >
> > I guess here you cut to the heart of the problem. It also isn't my job
> > to debug the C# compiler, and if the compiler writers couldn't be
> > bothered to tell me in what file and line the problem is, I'm less
> > inclined to work hard at debugging it. If they told me at least in
> > what file the problem was, I might be more inclined to try; but, as I
> > understand it, they're telling me, "there is something in your code we
> > can't handle; change your code". I am reluctant to start randomly
> > permuting random parts of the code (for fear that that will be a huge
> > time sink of low reward), so it is easiest for me to rollback to a
> > previous day's version, and redesign and rewrite recent code. Of
> > course, then I avoid diagnosing the bug entirely.[/color]
>
> Do other errors come up? Usually a ICE is caused by major confusion IN the
> compiler and is often not due to a specific place(or it is impossible to
> tell where the problem is occuring), however the other errors displayed in
> the compile should give you hints of where you need to look.
> Almost every ICE I've seen has been due to code with questionable
> correctness (I've generated atleast two due to some stupid constructs of my
> own over the years), however it is possibly due to legally correct code that
> the compiler doesn't handle.
> Examine the errors and see if you can find something that looks strange,
> finding the problem is important to the community as a whole, not just
> Microsoft.[/color]

Nope, no other errors at all came up.

I've had this (ICE) before, but never diagnosed it as having
anything to do with my code. In fact, because it did not tell
me in what file it was, I had to do then the same thing I did
this time -- simply rewrite the previous days work. I got lucky,
and no ICE the second time through.

I really wouldn't mind helping debug the VC compiler, but, I
don't see how I can even start (no error message of value,
no source to compiler). If I had the source to the compiler,
I could put a breakpoint where it is dying, and look at
the call stack (same as debugging anything else), and see
if anything is legible.

But of course, I can't really now, as I rolled back and rewrote
the code, and it works and compiles fine now.

I think one time (not this time but a previous time), I
renamed a namespace to the default (and renamed all
references to it), and I'm guessing that might have been
the problem. (I don't know for sure, because I rewrote
some code, and that is the one thing I noticed that I did
differently the second time -- I chose a different namespace
name -- or rather, I stuck with the name the wizard gave -- it
wasn't terribly appropriate, but I was already behind due to
having to rewrite, so I decided to leave it.)

[pj]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

"Willy Denoyette [MVP]" <willy.denoyett e@pandora.be> wrote in message news:<eqbSe9sgD HA.3616@TK2MSFT NGP11.phx.gbl>. ..[color=blue]
> It's not clear to me what compiler VC++ or C# you are talking about, moreover you should mention the compilers version number.
>
> Willy.[/color]

I did mention that it is the C# compiler, but as you say, I should give
the version: Microsoft Visual C# .NET 55524-652-0000007-18524


(If it were the MSVC++ compiler, I'd know what to do -- when it dies
with an internal error, I try to redo anything I did with templates
again without templates, or only with really simple ones --
because I have read repeatedly that the MSVC++ compiler has lots
of bugs with templates, and I got the impression that they are
complicated bugs, and it is best to avoid going anywhere near them.)

(Plus, the MSVC++ compiler says what module it dies on when it
dies with an internal error, so that helps a lot.)

[Daniel O'Connell]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?


"pj" <peterjohannsen @hotmail.com> wrote in message
news:127ce4a9.0 309251743.3c4e6 3ac@posting.goo gle.com...[color=blue]
> "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message[/color]
news:<n6ocb.567 281$Ho3.103168@ sccrnsc03>...[color=blue][color=green]
> > "pj" <peterjohannsen @hotmail.com> wrote in message
> > news:127ce4a9.0 309241322.3ce10 91c@posting.goo gle.com...[color=darkred]
> > > Christoph Nahr <christoph.nahr @kynosarges.de> wrote in message[/color]
> > news:<hl13nvoj6 neuh5bq86jcorji c2l6139l7l@4ax. com>...[color=darkred]
> > > > On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj)[/color][/color][/color]
wrote:[color=blue][color=green][color=darkred]
> > > >
> > > > >(Was originally, probably wrongly, posted to the vc subgroup.)
> > > > >(This doesn't appear to be a c# problem, but a problem with a bug[/color][/color][/color]
in[color=blue][color=green][color=darkred]
> > > > >the Visual Studio c# compiler, but, any help will be welcome...)
> > > >
> > > > This group covers compiler issues as well as language issues so your
> > > > post fits right in.
> > > >
> > > > >What do other people do when they hit
> > > > >compiler bugs ? Perhaps you others know how to decode this[/color][/color][/color]
information[color=blue][color=green][color=darkred]
> > > > >to find out what file and line number is confusing the compiler ?
> > > >
> > > > Don't know, and it's not my job. When a compiler generates an
> > > > internal error (I think I actually got one in the 1.0 framework,[/color][/color][/color]
once)[color=blue][color=green][color=darkred]
> > > > I look at the error message and try to change things around until[/color][/color][/color]
the[color=blue][color=green][color=darkred]
> > > > code compiles. Moreover, you should let the compiler makers (i.e.
> > > > Microsoft) know if they aren't alreay aware of the bug. That's all.
> > >
> > >
> > > I guess here you cut to the heart of the problem. It also isn't my job
> > > to debug the C# compiler, and if the compiler writers couldn't be
> > > bothered to tell me in what file and line the problem is, I'm less
> > > inclined to work hard at debugging it. If they told me at least in
> > > what file the problem was, I might be more inclined to try; but, as I
> > > understand it, they're telling me, "there is something in your code we
> > > can't handle; change your code". I am reluctant to start randomly
> > > permuting random parts of the code (for fear that that will be a huge
> > > time sink of low reward), so it is easiest for me to rollback to a
> > > previous day's version, and redesign and rewrite recent code. Of
> > > course, then I avoid diagnosing the bug entirely.[/color]
> >
> > Do other errors come up? Usually a ICE is caused by major confusion IN[/color][/color]
the[color=blue][color=green]
> > compiler and is often not due to a specific place(or it is impossible to
> > tell where the problem is occuring), however the other errors displayed[/color][/color]
in[color=blue][color=green]
> > the compile should give you hints of where you need to look.
> > Almost every ICE I've seen has been due to code with questionable
> > correctness (I've generated atleast two due to some stupid constructs of[/color][/color]
my[color=blue][color=green]
> > own over the years), however it is possibly due to legally correct code[/color][/color]
that[color=blue][color=green]
> > the compiler doesn't handle.
> > Examine the errors and see if you can find something that looks strange,
> > finding the problem is important to the community as a whole, not just
> > Microsoft.[/color]
>
> Nope, no other errors at all came up.
>
> I've had this (ICE) before, but never diagnosed it as having
> anything to do with my code. In fact, because it did not tell
> me in what file it was, I had to do then the same thing I did
> this time -- simply rewrite the previous days work. I got lucky,
> and no ICE the second time through.
>
> I really wouldn't mind helping debug the VC compiler, but, I
> don't see how I can even start (no error message of value,
> no source to compiler). If I had the source to the compiler,
> I could put a breakpoint where it is dying, and look at
> the call stack (same as debugging anything else), and see
> if anything is legible.
>
> But of course, I can't really now, as I rolled back and rewrote
> the code, and it works and compiles fine now.
>
> I think one time (not this time but a previous time), I
> renamed a namespace to the default (and renamed all
> references to it), and I'm guessing that might have been
> the problem. (I don't know for sure, because I rewrote
> some code, and that is the one thing I noticed that I did
> differently the second time -- I chose a different namespace
> name -- or rather, I stuck with the name the wizard gave -- it
> wasn't terribly appropriate, but I was already behind due to
> having to rewrite, so I decided to leave it.)[/color]
That sounds familiar, I think the last ICE I had was due to redoing
namespaces and screwing up one reference somewhere...It is curious as to
what exactly is causing the problem.
Did you try compiling the code with any other compilers?

[pj]

Re: INTERNAL ERROR -- how to deal with buggy (?) MSC# compiler ?

"Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message news:<_pNcb.579 625$YN5.417530@ sccrnsc01>...[color=blue]
> "pj" <peterjohannsen @hotmail.com> wrote in message
> news:127ce4a9.0 309251743.3c4e6 3ac@posting.goo gle.com...[color=green]
> > "Daniel O'Connell" <onyxkirx@--NOSPAM--comcast.net> wrote in message[/color]
> news:<n6ocb.567 281$Ho3.103168@ sccrnsc03>...[color=green][color=darkred]
> > > "pj" <peterjohannsen @hotmail.com> wrote in message
> > > news:127ce4a9.0 309241322.3ce10 91c@posting.goo gle.com...
> > > > Christoph Nahr <christoph.nahr @kynosarges.de> wrote in message[/color][/color]
> news:<hl13nvoj6 neuh5bq86jcorji c2l6139l7l@4ax. com>...[color=green][color=darkred]
> > > > > On 23 Sep 2003 22:26:59 -0700, peterjohannsen@ hotmail.com (pj)[/color][/color]
> wrote:[color=green][color=darkred]
> > > > >
> > > > > >(Was originally, probably wrongly, posted to the vc subgroup.)
> > > > > >(This doesn't appear to be a c# problem, but a problem with a bug[/color][/color]
> in[color=green][color=darkred]
> > > > > >the Visual Studio c# compiler, but, any help will be welcome...)
> > > > >
> > > > > This group covers compiler issues as well as language issues so your
> > > > > post fits right in.
> > > > >
> > > > > >What do other people do when they hit
> > > > > >compiler bugs ? Perhaps you others know how to decode this[/color][/color]
> information[color=green][color=darkred]
> > > > > >to find out what file and line number is confusing the compiler ?
> > > > >
> > > > > Don't know, and it's not my job. When a compiler generates an
> > > > > internal error (I think I actually got one in the 1.0 framework,[/color][/color]
> once)[color=green][color=darkred]
> > > > > I look at the error message and try to change things around until[/color][/color]
> the[color=green][color=darkred]
> > > > > code compiles. Moreover, you should let the compiler makers (i.e.
> > > > > Microsoft) know if they aren't alreay aware of the bug. That's all.
> > > >
> > > >
> > > > I guess here you cut to the heart of the problem. It also isn't my job
> > > > to debug the C# compiler, and if the compiler writers couldn't be
> > > > bothered to tell me in what file and line the problem is, I'm less
> > > > inclined to work hard at debugging it. If they told me at least in
> > > > what file the problem was, I might be more inclined to try; but, as I
> > > > understand it, they're telling me, "there is something in your code we
> > > > can't handle; change your code". I am reluctant to start randomly
> > > > permuting random parts of the code (for fear that that will be a huge
> > > > time sink of low reward), so it is easiest for me to rollback to a
> > > > previous day's version, and redesign and rewrite recent code. Of
> > > > course, then I avoid diagnosing the bug entirely.
> > >
> > > Do other errors come up? Usually a ICE is caused by major confusion IN[/color][/color]
> the[color=green][color=darkred]
> > > compiler and is often not due to a specific place(or it is impossible to
> > > tell where the problem is occuring), however the other errors displayed[/color][/color]
> in[color=green][color=darkred]
> > > the compile should give you hints of where you need to look.
> > > Almost every ICE I've seen has been due to code with questionable
> > > correctness (I've generated atleast two due to some stupid constructs of[/color][/color]
> my[color=green][color=darkred]
> > > own over the years), however it is possibly due to legally correct code[/color][/color]
> that[color=green][color=darkred]
> > > the compiler doesn't handle.
> > > Examine the errors and see if you can find something that looks strange,
> > > finding the problem is important to the community as a whole, not just
> > > Microsoft.[/color]
> >
> > Nope, no other errors at all came up.
> >
> > I've had this (ICE) before, but never diagnosed it as having
> > anything to do with my code. In fact, because it did not tell
> > me in what file it was, I had to do then the same thing I did
> > this time -- simply rewrite the previous days work. I got lucky,
> > and no ICE the second time through.
> >
> > I really wouldn't mind helping debug the VC compiler, but, I
> > don't see how I can even start (no error message of value,
> > no source to compiler). If I had the source to the compiler,
> > I could put a breakpoint where it is dying, and look at
> > the call stack (same as debugging anything else), and see
> > if anything is legible.
> >
> > But of course, I can't really now, as I rolled back and rewrote
> > the code, and it works and compiles fine now.
> >
> > I think one time (not this time but a previous time), I
> > renamed a namespace to the default (and renamed all
> > references to it), and I'm guessing that might have been
> > the problem. (I don't know for sure, because I rewrote
> > some code, and that is the one thing I noticed that I did
> > differently the second time -- I chose a different namespace
> > name -- or rather, I stuck with the name the wizard gave -- it
> > wasn't terribly appropriate, but I was already behind due to
> > having to rewrite, so I decided to leave it.)[/color]
> That sounds familiar, I think the last ICE I had was due to redoing
> namespaces and screwing up one reference somewhere...It is curious as to
> what exactly is causing the problem.
> Did you try compiling the code with any other compilers?[/color]

Unfortunately I'm not energetic enough (or have enough free time)
to set up mono, which is the only other compiler I know about.

It is on my wish list, of things I'd like to do :)