Hi All.

I faced with strange behavior of C# compiler - in some cases it generates
not working code!
I mean code that lead to the exception - System.InvalidProgramException:
Common Language Runtime detected an invalid program.

The situation is following - 3rd vendor library generates a class that
contains too big InitializeComponent method (copy-paste of
InitializeComponent method to empty text file gives us 23.100 lines and size
= 1.9mb). When calls this method is called application immediately crashed
with the message - "System.InvalidProgramException: Common Language Runtime
detected an invalid program."

Content of InitializeComponent is similar to such methods in Windows.Forms
or Asp.Net application - there are initializations of components properties
ans so on - nothing special, just lot of assignments; no local variables -
ony class members used.

Just by a guess I tried to split up that method to more small pieces of
code - InitializeComponent1, InitializeComponent2 and so on. After that
mentioned error disappeared - all things begin to work fine.
I tested this case on 3 different computers - this error is stable (btw, I
my computer is Pentium4-3GHz/1Gb RAM/120Gb HDD, then I do not think that
error could appears because of weak computer).
One more case I tested - Debug and Release builds of that application -
mentioned error appears constantly only in Debug build, Release build of the
application works fine.

And one more interesting thing - this error stable appears in VS.Net 2003
and VS.Net 2005 Beta2.
Then is could be a problem of new VS.Net too.

My questions are:
Is it a BUG in C# compiler? Is it limitation of compiler? Where such
limitations described?
Should I think my conclusion about reason of this error (I mean - too many
code in one class method) is correct?
Or perhaps you could see any other possible reasons of the problem? Which?
Could we expect Microsoft to release the patch in the nearest future?
Or should we ask 3rd vendor to implement the workaround I found (I mean -
splitting up big method to smaller)?

The problem is very serious for us, please help!


WBR,
Dmitry.

>
> My questions are:
> Is it a BUG in C# compiler? Is it limitation of compiler? Where such
> limitations described?

It is as likely not a bug in the compiler as it is one. However it does look
like a bug. The question is if it is in the compiler(generating bad code at
some point) or if its in the runtime\JIT haivng a problem with some code
sequence. Try running peverify on it to see if it can give you an idea of
whats wrong, and if you know the platform well enough, analyzing the IL,
specifically the differences in the release and debug builds.

> Should I think my conclusion about reason of this error (I mean - too many
> code in one class method) is correct?

Without testing it myself, I can't say for sure, but the evidence you give
certainly suggests it. You might want to run something like

> Could we expect Microsoft to release the patch in the nearest future?

This is an odd bug, they may not know about it. Try reporting it to product
services(don't know how to off hand, but someone else here should.)

> Or should we ask 3rd vendor to implement the workaround I found (I mean -
> splitting up big method to smaller)?

I'd talk to the 3rd party vendor, they are smaller and will probably be able
to fix the problem far faster than MS. They also might be able to put more
pressure on MS to fix the problem. It is odd they havn't run into this
circumstance.

Thank you for answer.

Yes, I know about PEVERIFY. Sorry I forget to say - I run it and it said all
is ok:

All Classes and Methods in TestStiApp2.exe Verified

Then, perhaps it could be a problem of JIT/VM...

to-All: does anybody know how to contact MS product services to report this
problem?
I browsed microsoft.com for a 20 minutes but unfortunately not found how to
submit problem report.
Looks like such task is far non trivial for MS, isn't it?... ;-)



"Daniel O'Connell [C# MVP]" <onyxkirx@--NOSPAM--comcast.net> wrote in
message news:(E-Mail Removed)...
>
> >
> > My questions are:
> > Is it a BUG in C# compiler? Is it limitation of compiler? Where such
> > limitations described?
>
> It is as likely not a bug in the compiler as it is one. However it does
look
> like a bug. The question is if it is in the compiler(generating bad code
at
> some point) or if its in the runtime\JIT haivng a problem with some code
> sequence. Try running peverify on it to see if it can give you an idea of
> whats wrong, and if you know the platform well enough, analyzing the IL,
> specifically the differences in the release and debug builds.
>
> > Should I think my conclusion about reason of this error (I mean - too
many
> > code in one class method) is correct?
>
> Without testing it myself, I can't say for sure, but the evidence you give
> certainly suggests it. You might want to run something like
>
> > Could we expect Microsoft to release the patch in the nearest future?
>
> This is an odd bug, they may not know about it. Try reporting it to
product
> services(don't know how to off hand, but someone else here should.)
>
> > Or should we ask 3rd vendor to implement the workaround I found (I
mean -
> > splitting up big method to smaller)?
>
> I'd talk to the 3rd party vendor, they are smaller and will probably be
able
> to fix the problem far faster than MS. They also might be able to put more
> pressure on MS to fix the problem. It is odd they havn't run into this
> circumstance.
>
>

Dmitry Bond. wrote:
> Then, perhaps it could be a problem of JIT/VM...

I think it is a problem with JIT or the execution engine. To be honest,
a method with over 23 thousand lines is extreme. That is a bug in the
vendor's code IMO. The vendor should delay some of this initialization.

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm

Dmitry,

Well, I was able to reproduce the exception, but I don't think it's a
bug. What I found is that there is a limit to the number of local
variables you can declare in a method. That limit is 32767. Anything
more than that will generate the said exception. I also attempted to
find a limit to the size of the method. I made it up to 2^20 lines of
code in a single method that produced a ~25MB source file and compiled
to ~13MB before I gave up. ILDASM, though slow, was quite content when
I forced it to show me the contents of that method. What was amazing
though was that it only took ~8 seconds to JIT compile the method. Not
too bad eh?

Brian

Dmitry Bond. wrote:
> Hi All.
>
> I faced with strange behavior of C# compiler - in some cases it generates
> not working code!
> I mean code that lead to the exception - System.InvalidProgramException:
> Common Language Runtime detected an invalid program.
>
> The situation is following - 3rd vendor library generates a class that
> contains too big InitializeComponent method (copy-paste of
> InitializeComponent method to empty text file gives us 23.100 lines and size
> = 1.9mb). When calls this method is called application immediately crashed
> with the message - "System.InvalidProgramException: Common Language Runtime
> detected an invalid program."
>
> Content of InitializeComponent is similar to such methods in Windows.Forms
> or Asp.Net application - there are initializations of components properties
> ans so on - nothing special, just lot of assignments; no local variables -
> ony class members used.
>
> Just by a guess I tried to split up that method to more small pieces of
> code - InitializeComponent1, InitializeComponent2 and so on. After that
> mentioned error disappeared - all things begin to work fine.
> I tested this case on 3 different computers - this error is stable (btw, I
> my computer is Pentium4-3GHz/1Gb RAM/120Gb HDD, then I do not think that
> error could appears because of weak computer).
> One more case I tested - Debug and Release builds of that application -
> mentioned error appears constantly only in Debug build, Release build of the
> application works fine.
>
> And one more interesting thing - this error stable appears in VS.Net 2003
> and VS.Net 2005 Beta2.
> Then is could be a problem of new VS.Net too.
>
> My questions are:
> Is it a BUG in C# compiler? Is it limitation of compiler? Where such
> limitations described?
> Should I think my conclusion about reason of this error (I mean - too many
> code in one class method) is correct?
> Or perhaps you could see any other possible reasons of the problem? Which?
> Could we expect Microsoft to release the patch in the nearest future?
> Or should we ask 3rd vendor to implement the workaround I found (I mean -
> splitting up big method to smaller)?
>
> The problem is very serious for us, please help!
>
>
> WBR,
> Dmitry.

- I think I read about such a bug 1 1/2 year ago and it was confirmed to be
a known bug by a MS guy.
- bug report link: http://lab.msdn.microsoft.com/productfeedback/
it's on the start page ;-)
- try out VS2005, maybe they fixed it?

"Dmitry Bond." <(E-Mail Removed)> wrote in message
news:dkpnrp$4h9$(E-Mail Removed)...
> Hi All.
>
> I faced with strange behavior of C# compiler - in some cases it generates
> not working code!
> I mean code that lead to the exception - System.InvalidProgramException:
> Common Language Runtime detected an invalid program.
>
> The situation is following - 3rd vendor library generates a class that
> contains too big InitializeComponent method (copy-paste of
> InitializeComponent method to empty text file gives us 23.100 lines and
> size
> = 1.9mb). When calls this method is called application immediately crashed
> with the message - "System.InvalidProgramException: Common Language
> Runtime
> detected an invalid program."
>
> Content of InitializeComponent is similar to such methods in Windows.Forms
> or Asp.Net application - there are initializations of components
> properties
> ans so on - nothing special, just lot of assignments; no local variables -
> ony class members used.
>
> Just by a guess I tried to split up that method to more small pieces of
> code - InitializeComponent1, InitializeComponent2 and so on. After that
> mentioned error disappeared - all things begin to work fine.
> I tested this case on 3 different computers - this error is stable (btw, I
> my computer is Pentium4-3GHz/1Gb RAM/120Gb HDD, then I do not think that
> error could appears because of weak computer).
> One more case I tested - Debug and Release builds of that application -
> mentioned error appears constantly only in Debug build, Release build of
> the
> application works fine.
>
> And one more interesting thing - this error stable appears in VS.Net 2003
> and VS.Net 2005 Beta2.
> Then is could be a problem of new VS.Net too.
>
> My questions are:
> Is it a BUG in C# compiler? Is it limitation of compiler? Where such
> limitations described?
> Should I think my conclusion about reason of this error (I mean - too many
> code in one class method) is correct?
> Or perhaps you could see any other possible reasons of the problem? Which?
> Could we expect Microsoft to release the patch in the nearest future?
> Or should we ask 3rd vendor to implement the workaround I found (I mean -
> splitting up big method to smaller)?
>
> The problem is very serious for us, please help!
>
>
> WBR,
> Dmitry.
>
>
>
>
>

Hi Richard,

"Richard Grimes" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> Dmitry Bond. wrote:
>> Then, perhaps it could be a problem of JIT/VM...
>
> I think it is a problem with JIT or the execution engine. To be honest, a
> method with over 23 thousand lines is extreme. That is a bug in the
> vendor's code IMO. The vendor should delay some of this initialization.
>
> Richard
> --
> http://www.grimes.demon.co.uk/workshops/fusionWS.htm
> http://www.grimes.demon.co.uk/workshops/securityWS.htm

If .NET does not have a documentation entry that limits this, then the
vendor's code does not have a bug. Although I think 23000 lines is a lot,
there is by my knowledge no limit to the number of executed statements
inside a function.

Anyway, documentation on InvalidProgramException:
<quote>
The exception that is thrown when a program contains invalid Microsoft
intermediate language (MSIL) or metadata. Generally this indicates a bug in
the compiler that generated the program.
</quote>

Since the compiler was able to compile the generated program without
compilation errors or ICE's, the compiler in question generated bad IL.

Kind regards,
--
Tom Tempelaere.

Hi Brian,

"Brian Gideon" <(E-Mail Removed)> schreef in bericht
news:(E-Mail Removed)...
> Dmitry,
>
> Well, I was able to reproduce the exception, but I don't think it's a
> bug. What I found is that there is a limit to the number of local
> variables you can declare in a method. That limit is 32767. Anything
> more than that will generate the said exception. I also attempted to
> find a limit to the size of the method. I made it up to 2^20 lines of
> code in a single method that produced a ~25MB source file and compiled
> to ~13MB before I gave up. ILDASM, though slow, was quite content when
> I forced it to show me the contents of that method. What was amazing
> though was that it only took ~8 seconds to JIT compile the method. Not
> too bad eh?
>
> Brian

Where does the limitation apply? To the C# language? To the MSIL?

If the C# compiler didn't complain when compiling the code, then isn't the
compiler in fault? It should know the limits of the IL, or shouldn't it?

Kind regards,
--
Tom Tempelaere.

TT (Tom Tempelaere) wrote:
> Hi Brian,
>
> "Brian Gideon" <(E-Mail Removed)> schreef in bericht
> news:(E-Mail Removed)...
> > Dmitry,
> >
> > Well, I was able to reproduce the exception, but I don't think it's a
> > bug. What I found is that there is a limit to the number of local
> > variables you can declare in a method. That limit is 32767. Anything
> > more than that will generate the said exception. I also attempted to
> > find a limit to the size of the method. I made it up to 2^20 lines of
> > code in a single method that produced a ~25MB source file and compiled
> > to ~13MB before I gave up. ILDASM, though slow, was quite content when
> > I forced it to show me the contents of that method. What was amazing
> > though was that it only took ~8 seconds to JIT compile the method. Not
> > too bad eh?
> >
> > Brian
>
> Where does the limitation apply? To the C# language? To the MSIL?
>
> If the C# compiler didn't complain when compiling the code, then isn't the
> compiler in fault? It should know the limits of the IL, or shouldn't it?
>

You bring up a good point. If there is a limitation to IL then it
should be in the specification somewhere. If it is in the
specification then the bug lies in the C# compiler. But, if it isn't
then the bug lies in the JIT compiler. Either way there is a bug
somewhere.

> Kind regards,
> --
> Tom Tempelaere.

TT (Tom Tempelaere) wrote:
> If .NET does not have a documentation entry that limits this, then the
> vendor's code does not have a bug. Although I think 23000 lines is a
> lot, there is by my knowledge no limit to the number of executed
> statements inside a function.

Well, I think that is passing the buck, although I take your point
(albeit a double negative point) that if the spec doesn't say you cannot
do it, then that means that you should be able to do it.

As to a limit, well, of course there is one. The spec says that IL of a
method is preceded by a header, either fat format or tiny format. Tiny
format uses 6 bits to say how many bytes (not opcodes, but the total of
opcodes and their parameters) that make up the method. Clearly tiny
format is not used in this monster method <g>. The fat format uses 4
bytes (ie it's a uint) to give the number of bytes. (Partitian II 24.4.1
to 24.4.3) Of course, it's very doubtful that in this case the number of
bytes has been exceeded.

> Anyway, documentation on InvalidProgramException:
> <quote>
> The exception that is thrown when a program contains invalid Microsoft
> intermediate language (MSIL) or metadata. Generally this indicates a
> bug in the compiler that generated the program.
> </quote>
>
> Since the compiler was able to compile the generated program without
> compilation errors or ICE's, the compiler in question generated bad
> IL.

True. Someone on the C# team should have put in a count the number of
local variable (as another poster suggested was the problem) and threw
an error. However, having said that, I would not recommend anyone to buy
a tool that produces such monsterous code, regardless of whether it was
'correct' or not.

Richard
--
http://www.grimes.demon.co.uk/workshops/fusionWS.htm
http://www.grimes.demon.co.uk/workshops/securityWS.htm