[PR #5325] fix(ghidra): raise decompiler max payload cap for very large functions #6882

New issue

Open

opened 2026-11-01 21:43:48 +00:00 by bsakaguchi · 0 comments

bsakaguchi commented

2026-11-01 21:43:48 +00:00

Owner

📋 Pull Request Information

Original PR: https://github.com/morluto/rea/pull/5325
Author: @RhombusMaximus
Created: 10/20/2026
Status: 🔄 Open

Base: main ← Head: fix/ghidra-decompile-max-payload

📝 Commits (1)

e23983b fix(ghidra): raise decompiler max payload cap for very large functions

📊 Changes

1 file changed (+5 additions, -0 deletions)

View changed files

📝 bridge/ghidra/ReaGhidraBridge.java (+5 -0)

📄 Description

Problem

ReaGhidraBridge.initializeDecompiler() already lifts Ghidra's instruction cap
(setMaxInstructions(Integer.MAX_VALUE)) but leaves DecompileOptions'
max payload at its default 50 MB. For very large functions the
decompiler's XML response (syntax tree, symbols, p-code — far larger than the
flat pseudocode text) exceeds that cap, and the response is killed
mid-decompile. With an unbounded decompile timeout this surfaces as an item
status error rather than a clear payload-size diagnostic.

Observed on Ghidra 12.1.4 against a Windows x86 PE: a 101,285-byte /
~14,020-line procedure died ~600 s into an unbounded-timeout decompile with an
item status error. The same procedure decompiled cleanly once the cap was
raised — its flat pseudocode alone is 388,540 characters.

Fix

One line in initializeDecompiler(), right after setMaxInstructions:

options.setMaxPayloadMBytes(1024);

1024 MB keeps a hard upper bound (a pathological decompile still fails
eventually) while clearing the ceiling for legitimately huge functions.

Verification

Before the change: decompile of the procedure above fails mid-run
(~600 s, unbounded timeout) with an item status error.
After the change: the same decompile completes and the full output
(388,540 chars of pseudocode) is returned.
Scope: one call site, no other option handling touched.

_{🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.}

## 📋 Pull Request Information **Original PR:** https://github.com/morluto/rea/pull/5325 **Author:** [@RhombusMaximus](https://github.com/RhombusMaximus) **Created:** 10/20/2026 **Status:** 🔄 Open **Base:** `main` ← **Head:** `fix/ghidra-decompile-max-payload` --- ### 📝 Commits (1) - [`e23983b`](https://github.com/morluto/rea/commit/e23983b83bf5af7f982d9b87d5bdb447ef67a341) fix(ghidra): raise decompiler max payload cap for very large functions ### 📊 Changes **1 file changed** (+5 additions, -0 deletions) <details> <summary>View changed files</summary> 📝 `bridge/ghidra/ReaGhidraBridge.java` (+5 -0) </details> ### 📄 Description ## Problem `ReaGhidraBridge.initializeDecompiler()` already lifts Ghidra's instruction cap (`setMaxInstructions(Integer.MAX_VALUE)`) but leaves `DecompileOptions`' **max payload** at its default **50 MB**. For very large functions the decompiler's XML response (syntax tree, symbols, p-code — far larger than the flat pseudocode text) exceeds that cap, and the response is killed mid-decompile. With an unbounded decompile timeout this surfaces as an item status error rather than a clear payload-size diagnostic. Observed on Ghidra 12.1.4 against a Windows x86 PE: a 101,285-byte / ~14,020-line procedure died ~600 s into an unbounded-timeout decompile with an item status error. The same procedure decompiled cleanly once the cap was raised — its flat pseudocode alone is 388,540 characters. ## Fix One line in `initializeDecompiler()`, right after `setMaxInstructions`: ```java options.setMaxPayloadMBytes(1024); ``` 1024 MB keeps a hard upper bound (a pathological decompile still fails eventually) while clearing the ceiling for legitimately huge functions. ## Verification - Before the change: decompile of the procedure above fails mid-run (~600 s, unbounded timeout) with an item status error. - After the change: the same decompile completes and the full output (388,540 chars of pseudocode) is returned. - Scope: one call site, no other option handling touched. --- <sub>🔄 This issue represents a GitHub Pull Request. It cannot be merged through Gitea due to API limitations.</sub>

bsakaguchi added the

pull-request

label

2026-11-01 21:43:48 +00:00

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference

morluto/rea#6882

No description provided.

Rows
Columns