morluto/rea

Fork 0

mirror of https://github.com/morluto/rea.git synced 2026-11-05 06:45:22 +00:00

[GH-ISSUE #1801] [Bug] Managed static provider rejects game-sized assemblies: 256x per-byte IL/blob charge exhausts the 64 MiB budget at ~256 KB of IL #604

New issue

Closed

opened 2026-10-15 18:26:33 +00:00 by bsakaguchi · 5 comments

bsakaguchi commented

2026-10-15 18:26:33 +00:00

Owner

Originally created by @Nelglor on GitHub (Oct 11, 2026).
Original GitHub issue: https://github.com/morluto/rea/issues/1801

Note

🤖 Claude Fable 5.1 responding on behalf of Nick

Before submitting

I searched the open and closed issues for a related report (closest is #1371, which is a different failure on a large managed assembly).
I removed credentials, tokens, private paths, and sensitive target data.

Area

dotnet (managed static provider)

Observed behavior

inspect-managed-members (and the MCP tool) rejects ordinary game-sized assemblies with resource-limit / metadata.representation, returning zero types and zero methods. A 247 KB Unity Assembly-CSharp.dll and a 2.5 MB assembly_valheim.dll both fail. Only very small assemblies (a 23 KB stub, System.Memory.dll) succeed.

coverage: {"state":"unavailable","issues":[{"code":"resource-limit","scope":"metadata.representation","offset":136816,"detail":"Managed metadata exceeds the 67108864 byte representation budget"}]}

Reproduction

Take any Mono-backend Unity game assembly of a few hundred KB (Valheim's valheim_Data/Managed/assembly_valheim.dll from Steam is a public example).
npx -y rea-agents@6.4.0 inspect-managed-members /path/assembly_valheim.dll --format json
Observe types: [], methods: [], and the resource-limit coverage issue above.

Expected behavior

A 2.5 MB assembly with a few hundred KB of IL should decode fully, or at worst report partial coverage after a genuinely large amount of retained representation. The 64 MiB budget is described in docs as a representation budget, not a cap on raw IL size.

Impact and scope

Every real-world managed target I tried fails, so the managed track is unusable for game assemblies, which is the main case where a headless .NET inspector is attractive (dnSpy/ILSpy replacement). Small library assemblies work.

REA version

rea-agents 6.4.0 (npx)

Runtime and platform

Node 26.10.0; Linux x86_64 (CachyOS); no native provider involved

Target and artifact context

Windows PE/CLI x86 assemblies produced by Unity (Mono backend); public Steam game files; no .NET runtime involved

Interface

CLI (rea inspect-managed-members); the MCP tool shares the same path

Earliest failure stage

parseMethods → methodBody in dist/dotnet/ManagedMemberRows.js / ManagedMethodBodyReader.js, at file offset 136816 of the 2.5 MB Valheim assembly, i.e. roughly 5% into the method bodies.

Relevant output or evidence

Instrumented ManagedDecodeBudget.prototype.reserve to log the failing call and the cumulative reservation:

RESERVE FAIL bytes= 30464 offset= 136816 cumulative= 67126652
    at methodBody (dist/dotnet/ManagedMethodBodyReader.js:66:17)
    at dist/dotnet/ManagedMemberRows.js:95:23
    at readManagedValue (dist/dotnet/ManagedReaderFailure.js:14:16)
    at parseMethods (dist/dotnet/ManagedMemberRows.js:75:9)

Typed outcome or recovery expected

Full decode for assemblies of this size. If a budget must apply, a partial result with coverage.state: "partial" and the decoded prefix retained, rather than discarding everything.

Analysis or suspected cause

ManagedMethodBodyReader.js:66 charges il.length * 256 bytes per method body, and ManagedMemberRows.js:151 charges bytes.length * 256 per blob signature, all against the single shared 64 MiB ManagedDecodeBudget. 64 MiB / 256 = 256 KiB, so any assembly whose total IL plus signature blobs exceeds roughly 256 KB is rejected regardless of how much representation is actually retained. The 256x multiplier looks like a worst-case per-byte JSON projection estimate applied to the raw IL length, which overshoots by two orders of magnitude for normal code.

Additional context

Found while evaluating REA as a headless alternative to dnSpy for Unity save-file reversing. Two further gaps that would matter for that use case, noted here rather than as separate issues since they may be by design: ldstr anchors carry only the #US token (0x70000001), never the literal text; and call edges name member-ref targets without their declaring type (target_name: ".ctor"), so "who calls CryptoStream" is not answerable by name.

Originally created by @Nelglor on GitHub (Oct 11, 2026). Original GitHub issue: https://github.com/morluto/rea/issues/1801 > [!NOTE] > 🤖 **Claude Fable 5.1 responding on behalf of Nick** ### Before submitting - [x] I searched the open and closed issues for a related report (closest is #1371, which is a different failure on a large managed assembly). - [x] I removed credentials, tokens, private paths, and sensitive target data. ### Area dotnet (managed static provider) ### Observed behavior `inspect-managed-members` (and the MCP tool) rejects ordinary game-sized assemblies with `resource-limit` / `metadata.representation`, returning zero types and zero methods. A 247 KB Unity `Assembly-CSharp.dll` and a 2.5 MB `assembly_valheim.dll` both fail. Only very small assemblies (a 23 KB stub, `System.Memory.dll`) succeed. ``` coverage: {"state":"unavailable","issues":[{"code":"resource-limit","scope":"metadata.representation","offset":136816,"detail":"Managed metadata exceeds the 67108864 byte representation budget"}]} ``` ### Reproduction 1. Take any Mono-backend Unity game assembly of a few hundred KB (Valheim's `valheim_Data/Managed/assembly_valheim.dll` from Steam is a public example). 2. `npx -y rea-agents@6.4.0 inspect-managed-members /path/assembly_valheim.dll --format json` 3. Observe `types: []`, `methods: []`, and the `resource-limit` coverage issue above. ### Expected behavior A 2.5 MB assembly with a few hundred KB of IL should decode fully, or at worst report partial coverage after a genuinely large amount of retained representation. The 64 MiB budget is described in docs as a representation budget, not a cap on raw IL size. ### Impact and scope Every real-world managed target I tried fails, so the managed track is unusable for game assemblies, which is the main case where a headless `.NET` inspector is attractive (dnSpy/ILSpy replacement). Small library assemblies work. ### REA version rea-agents 6.4.0 (npx) ### Runtime and platform Node 26.10.0; Linux x86_64 (CachyOS); no native provider involved ### Target and artifact context Windows PE/CLI x86 assemblies produced by Unity (Mono backend); public Steam game files; no .NET runtime involved ### Interface CLI (`rea inspect-managed-members`); the MCP tool shares the same path ### Earliest failure stage `parseMethods` → `methodBody` in `dist/dotnet/ManagedMemberRows.js` / `ManagedMethodBodyReader.js`, at file offset 136816 of the 2.5 MB Valheim assembly, i.e. roughly 5% into the method bodies. ### Relevant output or evidence Instrumented `ManagedDecodeBudget.prototype.reserve` to log the failing call and the cumulative reservation: ``` RESERVE FAIL bytes= 30464 offset= 136816 cumulative= 67126652 at methodBody (dist/dotnet/ManagedMethodBodyReader.js:66:17) at dist/dotnet/ManagedMemberRows.js:95:23 at readManagedValue (dist/dotnet/ManagedReaderFailure.js:14:16) at parseMethods (dist/dotnet/ManagedMemberRows.js:75:9) ``` ### Typed outcome or recovery expected Full decode for assemblies of this size. If a budget must apply, a partial result with `coverage.state: "partial"` and the decoded prefix retained, rather than discarding everything. ### Analysis or suspected cause `ManagedMethodBodyReader.js:66` charges `il.length * 256` bytes per method body, and `ManagedMemberRows.js:151` charges `bytes.length * 256` per blob signature, all against the single shared 64 MiB `ManagedDecodeBudget`. 64 MiB / 256 = 256 KiB, so any assembly whose total IL plus signature blobs exceeds roughly 256 KB is rejected regardless of how much representation is actually retained. The 256x multiplier looks like a worst-case per-byte JSON projection estimate applied to the raw IL length, which overshoots by two orders of magnitude for normal code. ### Additional context Found while evaluating REA as a headless alternative to dnSpy for Unity save-file reversing. Two further gaps that would matter for that use case, noted here rather than as separate issues since they may be by design: `ldstr` anchors carry only the `#US` token (`0x70000001`), never the literal text; and call edges name member-ref targets without their declaring type (`target_name: ".ctor"`), so "who calls `CryptoStream`" is not answerable by name.

bsakaguchi

2026-10-15 18:26:33 +00:00

closed this issue
added the
area: providers

bug
labels

bsakaguchi commented

2026-10-15 18:26:35 +00:00

Author

Owner

@llegui commented on GitHub (Oct 11, 2026):

Same failure here on large .NET Framework 4.x (x86) assemblies:
of 18 assemblies, only the 7 smallest decoded; the rest failed with the same
resource-limit / metadata.representation issue, including one of 375 KB.

Workaround that confirms the diagnosis above: making the constant in
dist/dotnet/ManagedDecodeBudget.js configurable

const MAX_METADATA_REPRESENTATION_BYTES =
  Number(process.env.REA_MANAGED_BUDGET_MB ?? 64) * 1024 * 1024;

and running with REA_MANAGED_BUDGET_MB=4096 (plus node --max-old-space-size=8192)
decodes all 11 failing assemblies (5–40 s each, coverage partial with no issues,
JSON output 4–77 MB). So the accounting, not real memory, is what rejects them.
An env var / CLI option for the budget, or a lower per-byte charge, would fix it.

@llegui commented on GitHub (Oct 11, 2026): Same failure here on large .NET Framework 4.x (x86) assemblies: of 18 assemblies, only the 7 smallest decoded; the rest failed with the same `resource-limit / metadata.representation` issue, including one of 375 KB. Workaround that confirms the diagnosis above: making the constant in `dist/dotnet/ManagedDecodeBudget.js` configurable const MAX_METADATA_REPRESENTATION_BYTES = Number(process.env.REA_MANAGED_BUDGET_MB ?? 64) * 1024 * 1024; and running with `REA_MANAGED_BUDGET_MB=4096` (plus `node --max-old-space-size=8192`) decodes all 11 failing assemblies (5–40 s each, coverage `partial` with no issues, JSON output 4–77 MB). So the accounting, not real memory, is what rejects them. An env var / CLI option for the budget, or a lower per-byte charge, would fix it.

bsakaguchi commented

2026-10-15 18:26:35 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 11, 2026):

Confirming the diagnosis from reading origin/main (@ed084b3d): the flat 256x per-byte charge introduced by 0f0d6e4d exhausts the 64 MiB representation budget at ~256 KB of charged input.

Charging sites I measured:

src/dotnet/ManagedMemberRows.ts:273 — reserve(bytes.length * 256, layout.blob.offset) (blob heap; this is what fires first on MemberRef-dense assemblies like assembly_valheim.dll, offset 136816 in the report)
src/dotnet/ManagedMemberInstructionDecoder.ts:492 — count * 256 (IL bodies; a ~340 KB-IL synthetic assembly trips this at offset ~274 KB)

Reproduced red-to-green against a synthetic 965 KB assembly built with the dotnet SDK: current main returns resource-limit / metadata.representation with types: [], methods: []; the same DLL decodes fine (complete, all methods) on a checkout without 0f0d6e4d.

Working on a fix. Plan: replace the flat 256x factor with a bounded per-byte representation estimate (JSON-escape worst case, in line with the existing reserveString ×6 accounting in ManagedDecodeBudget.ts:32-35), keep the resource-limit failure semantics, and include {charged, budget} in the failure detail for diagnosability. I'll also evaluate making the budget overridable (env) as llegui suggests — happy to follow whatever the maintainers prefer between "tighter accounting" vs "configurable budget". One caveat for honesty: my fixtures are synthetic (dotnet SDK-generated IL + synthetic blob heap), not the commercial-obfuscator samples llegui tested.

🤖 AI-assisted: this comment and the upcoming fix were prepared with Claude (anthropic), account akushonkamen.

@akushonkamen commented on GitHub (Oct 11, 2026): Confirming the diagnosis from reading `origin/main` (@ed084b3d): the flat 256x per-byte charge introduced by 0f0d6e4d exhausts the 64 MiB representation budget at ~256 KB of charged input. Charging sites I measured: - `src/dotnet/ManagedMemberRows.ts:273` — `reserve(bytes.length * 256, layout.blob.offset)` (blob heap; this is what fires first on MemberRef-dense assemblies like `assembly_valheim.dll`, offset 136816 in the report) - `src/dotnet/ManagedMemberInstructionDecoder.ts:492` — `count * 256` (IL bodies; a ~340 KB-IL synthetic assembly trips this at offset ~274 KB) Reproduced red-to-green against a synthetic 965 KB assembly built with the dotnet SDK: current `main` returns `resource-limit / metadata.representation` with `types: []`, `methods: []`; the same DLL decodes fine (`complete`, all methods) on a checkout without 0f0d6e4d. Working on a fix. Plan: replace the flat 256x factor with a bounded per-byte representation estimate (JSON-escape worst case, in line with the existing `reserveString` ×6 accounting in `ManagedDecodeBudget.ts:32-35`), keep the `resource-limit` failure semantics, and include `{charged, budget}` in the failure detail for diagnosability. I'll also evaluate making the budget overridable (env) as llegui suggests — happy to follow whatever the maintainers prefer between "tighter accounting" vs "configurable budget". One caveat for honesty: my fixtures are synthetic (dotnet SDK-generated IL + synthetic blob heap), not the commercial-obfuscator samples llegui tested. 🤖 AI-assisted: this comment and the upcoming fix were prepared with Claude (anthropic), account akushonkamen.

bsakaguchi commented

2026-10-15 18:26:35 +00:00

Author

Owner

@netfox-web commented on GitHub (Oct 11, 2026):

Another data point, rea 6.4.0 / Node 24.19 / win32 x64, no obfuscator involved:

A 1.3 MB .NET Framework 4.0 x86 WinForms exe (strong-named, IL-only, references EPPlus/NPOI/System.Data): inspect-managed-artifact succeeds (classification, assembly, references all fine), but inspect-managed-members returns types: [] with resource-limit / metadata.representation at offset 239581 ("exceeds the 67108864 byte representation budget").
A 10.8 MB sibling exe (same vendor, metadata_size 2,054,868, resources_size 3,151,856) fails already in inspect-managed-artifact (metadata.status: partial, assembly: null).

So ordinary line-of-business WinForms apps hit this too, not only game-sized assemblies. An env override as suggested above would unblock us immediately. Thanks for the quick diagnosis.

@netfox-web commented on GitHub (Oct 11, 2026): Another data point, rea 6.4.0 / Node 24.19 / win32 x64, no obfuscator involved: - A **1.3 MB** .NET Framework 4.0 x86 WinForms exe (strong-named, IL-only, references EPPlus/NPOI/System.Data): `inspect-managed-artifact` succeeds (`classification`, `assembly`, `references` all fine), but `inspect-managed-members` returns `types: []` with `resource-limit / metadata.representation` at offset 239581 ("exceeds the 67108864 byte representation budget"). - A **10.8 MB** sibling exe (same vendor, `metadata_size` 2,054,868, `resources_size` 3,151,856) fails already in `inspect-managed-artifact` (`metadata.status: partial`, `assembly: null`). So ordinary line-of-business WinForms apps hit this too, not only game-sized assemblies. An env override as suggested above would unblock us immediately. Thanks for the quick diagnosis.

bsakaguchi commented

2026-10-15 18:26:35 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 11, 2026):

Update: the fix is implemented and validated on a local branch (fix/1801-managed-decode-budget-accounting, against main @ f2150eb9); a pull request referencing this issue follows.

Root cause (sharper than "the constant is too big"): the flat 256x per-byte pre-charges at ManagedMemberRows.ts:273 (signature blobs), ManagedMethodBodyReader.ts:102 (IL bodies), and ManagedMemberInstructionDecoder.ts:492 (exception clauses) bill transient decode expansion cumulatively against the 64 MiB retained representation budget introduced by 0f0d6e4d. Decoded records already get billed by the retained ledger through the existing precise paths (admitManagedProjection at ManagedMemberInspector.ts:214, heap string reserveString, per-digest charges) — so the pre-charge made the effective capacity for input 256x smaller while double-counting everything that is actually kept. 64 MiB ÷ 256 = the ~256 KB blow-up point in the title.

Fix: each decode call now admits its own 256x expansion against a new per-call admitDecodeExpansion ceiling (1 GiB, ManagedDecodeBudget.ts), preserving 0f0d6e4d's fail-before-expansion property for a single pathological body without letting transient work spend retained capacity; the signature charge becomes a precise retained estimate (reserveString(bytes.length * 11 + 64) — worst is an 11-char primitive name per blob byte, house ×6 factor); resource-limit details now carry attempted/remaining bytes for diagnosability. The 64 MiB retained budget itself is unchanged; docs/managed-code-analysis.md "Resource admission" is updated to describe the two accounts.

Validation (all commands run locally):

New src/dotnet/ManagedDecodeBudgetCapacity.test.ts: red 5/5 before the change (both fixture tests fail with exactly resource-limit / metadata.representation), green 5/5 after. Regression: vitest run src/dotnet/ 90/90; managed boundary/acceptance/composition suites 43/43; npm run check:fast (typecheck+lint) passes; node scripts/verify-test-discovery.mjs finds all 834 test files exactly once.
Real assemblies (dotnet SDK, no obfuscator): pre-change build rejects a 965 KB 5201-method assembly with resource-limit at offset 274572 (byte-identical symptom to this report); fixed build decodes all 5201 methods in 224 ms. A 286 KB 2201-method assembly (inspect-managed-members CLI) reports coverage: complete with all method bodies present.
Honesty note on scale limits: my fixtures are synthetic/SDK-built, not llegui's obfuscated samples or netfox-web's WinForms exes. Also measured: the fixed build decodes the 5201-method assembly fully, but its projected output (11.8 MiB JSON, 83K anchors) hits the unchanged 64 MiB retained projection ledger at admission, so that adversarial fixture still reports resource-limit — now with precise diagnostics. Reported-size assemblies (hundreds of KB to a few MB) sit well under that ledger. If maintainers want the projection ledger more permissive (its per-record ×6 key/scalar accounting dominates) or an env override as llegui and netfox-web suggest, I'm happy to follow up or fold it in.

🤖 AI-assisted: prepared with Claude (anthropic), account akushonkamen.

@akushonkamen commented on GitHub (Oct 11, 2026): Update: the fix is implemented and validated on a local branch (`fix/1801-managed-decode-budget-accounting`, against main @ f2150eb9); a pull request referencing this issue follows. **Root cause (sharper than "the constant is too big"):** the flat 256x per-byte pre-charges at `ManagedMemberRows.ts:273` (signature blobs), `ManagedMethodBodyReader.ts:102` (IL bodies), and `ManagedMemberInstructionDecoder.ts:492` (exception clauses) bill *transient decode expansion* cumulatively against the 64 MiB *retained representation* budget introduced by 0f0d6e4d. Decoded records already get billed by the retained ledger through the existing precise paths (`admitManagedProjection` at `ManagedMemberInspector.ts:214`, heap string `reserveString`, per-digest charges) — so the pre-charge made the effective capacity for input 256x smaller while double-counting everything that is actually kept. 64 MiB ÷ 256 = the ~256 KB blow-up point in the title. **Fix:** each decode call now admits its own 256x expansion against a new per-call `admitDecodeExpansion` ceiling (1 GiB, `ManagedDecodeBudget.ts`), preserving 0f0d6e4d's fail-before-expansion property for a single pathological body without letting transient work spend retained capacity; the signature charge becomes a precise retained estimate (`reserveString(bytes.length * 11 + 64)` — worst is an 11-char primitive name per blob byte, house ×6 factor); `resource-limit` details now carry `attempted`/`remaining` bytes for diagnosability. The 64 MiB retained budget itself is unchanged; `docs/managed-code-analysis.md` "Resource admission" is updated to describe the two accounts. **Validation (all commands run locally):** - New `src/dotnet/ManagedDecodeBudgetCapacity.test.ts`: red 5/5 before the change (both fixture tests fail with exactly `resource-limit / metadata.representation`), green 5/5 after. Regression: `vitest run src/dotnet/` 90/90; managed boundary/acceptance/composition suites 43/43; `npm run check:fast` (typecheck+lint) passes; `node scripts/verify-test-discovery.mjs` finds all 834 test files exactly once. - Real assemblies (dotnet SDK, no obfuscator): pre-change build rejects a 965 KB 5201-method assembly with `resource-limit` at offset 274572 (byte-identical symptom to this report); fixed build decodes all 5201 methods in 224 ms. A 286 KB 2201-method assembly (`inspect-managed-members` CLI) reports `coverage: complete` with all method bodies present. - Honesty note on scale limits: my fixtures are synthetic/SDK-built, not llegui's obfuscated samples or netfox-web's WinForms exes. Also measured: the fixed build decodes the 5201-method assembly fully, but its projected output (11.8 MiB JSON, 83K anchors) hits the unchanged 64 MiB *retained projection* ledger at admission, so that adversarial fixture still reports `resource-limit` — now with precise diagnostics. Reported-size assemblies (hundreds of KB to a few MB) sit well under that ledger. If maintainers want the projection ledger more permissive (its per-record ×6 key/scalar accounting dominates) or an env override as llegui and netfox-web suggest, I'm happy to follow up or fold it in. 🤖 AI-assisted: prepared with Claude (anthropic), account akushonkamen.

bsakaguchi commented

2026-10-15 18:26:35 +00:00

Author

Owner

@akushonkamen commented on GitHub (Oct 11, 2026):

An update after studying the freshly merged #1768 (current main @ f178bf1c): it supersedes my earlier comment above, and we are not opening a pull request for this issue.

Independent positive check of #1768. The real dotnet SDK assembly I used to reproduce this issue's aggregate failure (965 KB, 5201 methods, ~340 KB of aggregate IL — rejected on the pre-#1768 tree with resource-limit / metadata.representation at offset 274572) now decodes fully on f178bf1c: coverage.state: "complete", no issues, 5201/5201 method bodies present (inspect-managed-members --format json, ~1.6 s). That is the "few hundred KB of IL" class this report describes, so from our side the reported scenario is resolved.

One residual gap is still reproducible on f178bf1c: a single item whose ×256 decode bound alone exceeds the budget is still rejected, no matter how small the retained output is:

one method with a ~300 KB IL body → resource-limit / metadata.representation, offset 2572;
one method with a ~300,000-parameter signature blob → same code and scope, offset 1224.

Both are fixture-level repros against inspectManagedMembersBytes; exact steps available on request. Whether this is worth changing is the maintainer's call: #1768's live-accumulation bound looks deliberate, and its new regression test ("bounds a method's IL and exception sections together", src/dotnet/ManagedMemberInspector.test.ts) requires rejecting a method whose IL bound (~40 MiB) plus exception-section bound (~28 MiB) are live together. Admitting a lone 300 KB body (~76.8 MiB bound) is mathematically incompatible with keeping that test, so the two policies cannot be combined cleanly. We explored a per-call decode-expansion admission (1 GiB ceiling) that passes both residual cases but fails that test by construction, and shelved it rather than weaken a freshly reviewed bound — details on request. (Method-merging obfuscators can produce such oversized single bodies, so the residual may still matter for a minority of obfuscated targets.)

Investigated with AI assistance.

@akushonkamen commented on GitHub (Oct 11, 2026): An update after studying the freshly merged #1768 (current `main` @ `f178bf1c`): it supersedes my earlier comment above, and we are not opening a pull request for this issue. **Independent positive check of #1768.** The real dotnet SDK assembly I used to reproduce this issue's aggregate failure (965 KB, 5201 methods, ~340 KB of aggregate IL — rejected on the pre-#1768 tree with `resource-limit` / `metadata.representation` at offset 274572) now decodes fully on `f178bf1c`: `coverage.state: "complete"`, no issues, 5201/5201 method bodies present (`inspect-managed-members --format json`, ~1.6 s). That is the "few hundred KB of IL" class this report describes, so from our side the reported scenario is resolved. **One residual gap is still reproducible on `f178bf1c`:** a *single* item whose ×256 decode bound alone exceeds the budget is still rejected, no matter how small the retained output is: - one method with a ~300 KB IL body → `resource-limit` / `metadata.representation`, offset 2572; - one method with a ~300,000-parameter signature blob → same code and scope, offset 1224. Both are fixture-level repros against `inspectManagedMembersBytes`; exact steps available on request. Whether this is worth changing is the maintainer's call: #1768's live-accumulation bound looks deliberate, and its new regression test ("bounds a method's IL and exception sections together", `src/dotnet/ManagedMemberInspector.test.ts`) requires rejecting a method whose IL bound (~40 MiB) plus exception-section bound (~28 MiB) are live together. Admitting a lone 300 KB body (~76.8 MiB bound) is mathematically incompatible with keeping that test, so the two policies cannot be combined cleanly. We explored a per-call decode-expansion admission (1 GiB ceiling) that passes both residual cases but fails that test by construction, and shelved it rather than weaken a freshly reviewed bound — details on request. (Method-merging obfuscators can produce such oversized single bodies, so the residual may still matter for a minority of obfuscated targets.) Investigated with AI assistance.

bsakaguchi referenced this issue

2026-10-16 21:14:18 +00:00

[PR #604] [MERGED] fix(comparison): require decoded signatures for structural method matches #2104

bsakaguchi referenced this issue

2026-10-16 21:17:15 +00:00

[PR #889] [MERGED] fix(dotnet): compare members with undecoded signatures by exact identity #2321