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]

(e-mail address removed) (pj) wrote in

(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'

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.

 

[Christoph Nahr]

(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.

 

[Grant Richins [MS]]

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.

 

[Willy Denoyette [MVP]]

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]

This group covers compiler issues as well as language issues so your
post fits right in.


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.

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]

This group covers compiler issues as well as language issues so your
post fits right in.


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.

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.[/QUOTE]

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]

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.

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]

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

Willy.

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]

"Daniel O'Connell" <[email protected]> wrote in message

Christoph Nahr <[email protected]> wrote in message

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.)

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]

"Daniel O'Connell" <[email protected]> wrote in message

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?

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

 

[Daniel O'Connell]

"Daniel O'Connell" <[email protected]> wrote in message

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

Actually, Setting up mono isn't so hard if you aren't dead set on compiling
it yourself, they offer a windows installer package,
I have it running here so i can test things by just using mono <exefile>
instead of normally running the exe. Its not perfect but it runs most
console apps.
What about other versions of the MS C# compiler, 1.0 perhaps(or 1.1, not
sure which version this failed with). Just to see if the problem has been
fixed. If you are using 1.0, it may have been fixed in 1.1.

 

[Grant Richins [MS]]

I know this doesn't help much in this case, but the C# compiler actually
does try to give as much information as it has about where it 'died'. In
this case, it had no information (no source file, no method, no output file,
no nothing). Which usually means it had a problem with one of your
options/project settings.

The whole renaming a namespace issue is a known bug (if you really want to
know I can dig up the KB article on it). IIRC the solution actually
involved turning off incremental compilation. However in this case you said
you weren't using incremental compilation.

Since we can't give you the source code for the compiler so you can debug
it, the next best option is for you to send us your source code so that we
can debug it. Plus I'd like to think the compiler is good enough that you'd
never need to debug it, but obviously it isn't.

So next time this happens, just make a ZIP file of the whole solution and
post it if that's all you have time for. If you have more time, please try
narrow down what is causing the problem. Please always consider an ICE
(Internal Compiler Error) our bug and not yours.