Importing consumes a lot of memory.

[vext01]

Hi,

I've been experimenting with CTADL's PCODE frontend.

I've been able to import small toy binaries and run queries, but anything larger and the import step causes my system to run out of memory.

For example, trying to import /bin/ls, a relatively small program:

$ ls -al /bin/ls
lrwxrwxrwx 1 root root 29 Sep 26  2025 /bin/ls -> ../lib/cargo/bin/coreutils/ls
$ du -hs $(realpath /bin/ls)
11M     /usr/lib/cargo/bin/coreutils/ls
$ ctadl import pcode /bin/ls -o work

I have btop running and can see Java consume GBs of memory, eventually exhausting the system and making it unresponsive (the system is a VM with about 5GB of RAM).

(Putting some heap limits in place, I can stop it killing the system and get a dump out of Java, but it doesn't look all that useful)

Would we expect this much memory consumption?

As I understand, the import step is just calling ghidra to get the PCODE as fact files (and not doing any actual datalog stuff)? Perhaps this can be tweaked to be more memory efficient?

Thanks!

[dbueno]

Couple of things to note:

• That ls binary looks larger than I'd expect for a standalone ls binary. I believe it contains the code of all of coreutils, not just ls
• You're correct that Ghidra is exhausting resources decompiling the binary.
• As far as improving it: you could try editing the export script to use a serial decompiler; around this line:

  ctadl/src/ctadl/souffle-logic/pcode/ExportPcode.java

  Line 1206 in 4cab3c6

  ParallelDecompiler.decompileFunctions(callback, toProcessList, monitor);

  . Use the DecompInterface directly https://github.com/NationalSecurityAgency/ghidra/blob/b3eef5912c67aaff5eaae534f5d94f9837f5227a/Ghidra/Features/Decompiler/src/main/java/ghidra/app/decompiler/DecompInterface.java#L82. I have found this helps when memory is tight since multiple decompilations aren't happening in parallel.

[vext01]

Hi,

Thanks for getting back to me.

That ls binary looks larger than I'd expect for a standalone ls binary. I believe it contains the code of all of coreutils, not just ls

It looks like a Rust implementation of ls (cargo being the giveaway), so it's probably statically linking parts of the Rust std/core that it needs. Regardless, I'd like to be able to run taint analyses on binaries much bigger than this.

As far as improving it: you could try editing the export script to use a serial decompiler

Right. I tried this, or rather, I tried getting Claude to do this for me (forgive me, it's been a long time since I wrote any Java code).

The following diff removes parallel compilation, but that wasn't enough alone: I had to also tweak MAXMEM and make the Java JIT/GC less greedy. And then I had to disable "batching" of decompilations.

Eventually I got it to run, but it consumed over 2GB of RAM and took almost 20 minutes:

$ /usr/bin/time -v ctadl import pcode /bin/ls -o import
...
Elapsed (wall clock) time (h:mm:ss or m:ss): 18:27.67
...
Maximum resident set size (kbytes): 2210492
...

All of this was done under a ulimit -d of roughly 3GB to stop the system being OOMed.

FWIW, here's the diff:

diff --git a/plugins/ghidra/src/ctadl_ghidra_fact_generator_plugin/__init__.py b/plugins/ghidra/src/ctadl_ghidra_fact_generator_plugin/__init__.py
index 1df8488..191ec0b 100644
--- a/plugins/ghidra/src/ctadl_ghidra_fact_generator_plugin/__init__.py
+++ b/plugins/ghidra/src/ctadl_ghidra_fact_generator_plugin/__init__.py
@@ -9,10 +9,10 @@ from pathlib import Path
 
 logger = logging.getLogger(__name__)
 
-MAXMEM = "40G"
+MAXMEM = "2500M"
 LAUNCH_MODE = "fg"
 DEBUG_ADDRESS = "127.0.0.1:13002"
-VMARG_LIST = "-XX:ParallelGCThreads=4 -XX:CICompilerCount=4 "
+VMARG_LIST = "-XX:ParallelGCThreads=2 -XX:CICompilerCount=2 "
 
 
 def read_version():
diff --git a/src/ctadl/souffle-logic/pcode/ExportPcode.java b/src/ctadl/souffle-logic/pcode/ExportPcode.java
index a650053..79b7391 100644
--- a/src/ctadl/souffle-logic/pcode/ExportPcode.java
+++ b/src/ctadl/souffle-logic/pcode/ExportPcode.java
@@ -43,9 +43,6 @@ import java.util.concurrent.TimeUnit;
 import ghidra.app.decompiler.DecompInterface;
 import ghidra.app.decompiler.DecompileOptions;
 import ghidra.app.decompiler.DecompileResults;
-import ghidra.app.decompiler.parallel.DecompileConfigurer;
-import ghidra.app.decompiler.parallel.DecompilerCallback;
-import ghidra.app.decompiler.parallel.ParallelDecompiler;
 import ghidra.app.script.GhidraScript;
 import ghidra.framework.plugintool.PluginTool;
 import ghidra.graph.GDirectedGraph;
@@ -129,14 +126,13 @@ class PcodeBlockBasicEdge implements GEdge<PcodeBlockBasicVertex> {
 	}
 }
 
-class DecompilerConfigurer implements DecompileConfigurer {
+class DecompilerConfigurer {
 
 	DecompInterface ifc;
 
 	DecompilerConfigurer(Program p) {
 	}
 
-	@Override
 	public void configure(DecompInterface decompiler) {
 		this.ifc = decompiler;
 		DecompileOptions options = new DecompileOptions();
@@ -1159,30 +1155,9 @@ public class ExportPcode extends GhidraScript {
 
 		DecompilerConfigurer configurer = new DecompilerConfigurer(currentProgram);
 
-		DecompilerCallback<DecompileResults> callback = new DecompilerCallback<DecompileResults>(currentProgram,
-				configurer) {
-			int count = 0;
-
-			@Override
-			// This could be done better, when results are available, other decompiler
-			// results will stall.
-			public synchronized DecompileResults process(DecompileResults results, TaskMonitor tMonitor)
-					throws Exception {
-				// This routine could pass the results to another thread's queue to add to the
-				// DB
-				// then there is only one DB writer and no synchronization needed. Decompiler
-				// threads can go as fast as they can without waiting for writing.
-				// With the chunking method, all decompiler threads would stall until the write
-				// was finished and a new chunk of functions could be gotten.
-				ex.processFunction(results, results.getFunction(), configurer.getInteface());
-				count++;
-				if (count > 20) {
-					ex.writeFacts(false);
-					count = 0;
-				}
-				return null;
-			}
-		};
+		DecompInterface ifc = new DecompInterface();
+		configurer.configure(ifc);
+		ifc.openProgram(currentProgram);
 
 		Set<Function> toProcess = new HashSet<Function>();
 		currentProgram.getFunctionManager().getFunctions(true).forEach(f -> {
@@ -1203,7 +1178,14 @@ public class ExportPcode extends GhidraScript {
 		ex.exportRegisterInfo(currentProgram);
 		ex.writeFacts(true);
 
-		ParallelDecompiler.decompileFunctions(callback, toProcessList, monitor);
+		for (Function func : toProcessList) {
+			if (monitor.isCancelled()) break;
+			DecompileResults results = ifc.decompileFunction(func, 60, monitor);
+			ex.processFunction(results, func, ifc);
+			ex.writeFacts(false);
+			monitor.incrementProgress(1);
+		}
+		ifc.dispose();
 
 		// System.out.println("Done producing");

At this point, the bottleneck could be ghidra itself?

(By the way, I notice that there are two copies of the Pcode exporter, one in CTADL, one in ghidra)

Cheers

[dbueno]

That diff looks good.

It looks like a Rust implementation of ls (cargo being the giveaway), so it's probably statically linking parts of the Rust std/core that it needs. Regardless, I'd like to be able to run taint analyses on binaries much bigger than this.

Right. This makes sense.

At this point, the bottleneck could be ghidra itself?

This is all Ghidra, unfortunately. I'm not sure why an 11MB binary blows up like that, though. Is this the latest Ghidra version?

(By the way, I notice that there are two copies of the Pcode exporter, one in CTADL, one in ghidra)

Yeah, this is because it's possible to run ctadl entirely from within Ghidra as well as outside of it. The one in this repo just extracts a few more (currenly unused) facts.