Skip to content

ILGenerator computation of maxstack is too conservative #63805

@shonk-msft

Description

@shonk-msft

Description

When generating a dynamic method both with many unconditional jumps, the ILGenerator's computation of maxstack is way to large - it adds the max stack of each basic block ending with an unconditional transfer (br, ret, throw, etc). If the generated code has many such bbs (eg, from the "then" clauses of if-then-else constructs) this sum can overflow 2^16. When it does, the maxstack recorded/used is the computed value mod 2^16. When that is less than the correct value, the JIT throws an InvalidProgramException.

For example, if there are 2^12 (4096) such blocks, each with a max stack of 2^4 (16), the computed maxstack is 2^16. That value mod 2^16 is zero. Since that is less than the actual (16 or more), the JIT will throw.

See the attached example code. This is written as a "test" that passes when the bug is present. The line enclosed by Assert.ThrowsException really should not throw.

ClrBugTests.cs.txt

Reproduction Steps

Build and run the unit test code above with .Net Core (verified with 3.1, and many later versions).

Expected behavior

The line marked with Assert.ThrowsException should not throw.

Actual behavior

An InvalidProgramException is thrown. Also, the computed max stack values (as written to console) are way too large. The actual max stack needed for this dynamic method is 4, and it doesn't depend on the number of basic blocks (the num parameter). The computed max stack values increase with num.

Regression?

No response

Known Workarounds

No good ones. This is blocking.

Configuration

No response

Other information

I'm working on a fix by fixing the computation in ILGenerator.cs.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions