Activating the AI Autopilot: How I Used Claude Code to Hunt Down a Complex JNI Memory Leak

When executing an extended soak test on a high-throughput system, a linear rise in Resident Set Size (RSS) while Java heap metrics remain a perfect, stable sawtooth points to only one culprit: a native memory leak.

As a Lead QA Engineer, I recently faced this exact scenario. Our architecture was built for massive throughput: a customized Java test application simulated hundreds of concurrent users using our proprietary SDK to connect to the server. Simultaneously, a dedicated testing datasource blasted random real-time updates across a 500,000-row grid. Both streams fed into a performance-critical C server hosting a core Java Module via a JNI bridge. Tracking down native leaks across a JNI boundary usually requires days of manual pointer tracing or highly intrusive profiling tools that often crash heavy-load environments.

Instead, our team used Claude Code as an autonomous operations partner to implement Interval-Based Differential Core Dump Analysis, pinpointing a highly elusive race condition in our production codebase.

The Architecture & The Symptom

Our Grafana telemetry gave us a clear operational picture:

• The Java Module Heap: Stable, predictable sawtooth pattern (Garbage Collection functioning normally).
• The C Server Process RSS: Continuous linear growth over hours.
• The Implication: The leak was trapped on the native C side, likely tied to resources crossing or failing to clear the JNI boundary.

Phase 1: Falling into the "Passive Trap"

Initially, we fell straight into the common AI trap: Static Code Inspection. We spun up a replica test environment on a dedicated VM, gave Claude access to the live process, and let it passively scan the codebase for leaks.

Claude did identify several memory leaks in the code. However, our developer closely reviewed the findings and correctly caught that these were minor, edge-case leaks that rarely triggered. They were completely unrelated to the massive, aggressive memory creep we were actively seeing in our soak test environment.

Shortly after, Claude attempted intrusive runtime monitoring, which accidentally crashed the high-throughput server. This forced us to rethink our strategy entirely.

Phase 2: Moving to Snapshot Diffs

Our first instinct was the standard industry approach: running the C server under Valgrind. However, this approach failed immediately. Attaching Valgrind added a massive performance overhead that our high-throughput server could not sustain under the immense load of the 500,000-row grid simulation, causing the entire environment to stall and fail almost instantly.

If we couldn't hook into the process live or use heavy runtime instrumentation, we had to look at what was accumulating by comparing frozen states in time instead. We instructed Claude to interact with GDB and safely capture non-destructive core dump snapshots via gcore at 30-minute intervals without terminating the application.

Claude then parsed the data structures across both dumps, evaluated the memory deltas, and flagged a critical anomaly: the total count of a specific native C structure was growing linearly and never dropping. This structure functioned as a native cache, holding onto the calculated pivot results passed back from the Java module for our 500K-row grid. Each entry included a distinct subject name identifier designed to differentiate the cached pivot results—but the total number of these objects was now accumulating indefinitely.

Phase 3: Log Triage at Scale (Sifting Megabytes per Minute)

To validate if this was a true leak or just delayed processing, we asked Claude to extract specific examples of these accumulating subject identifiers. Cross-referencing these names against our test client’s output confirmed that discard requests for these exact subjects had already been sent.

However, proving why they weren't destroying themselves was incredibly difficult. Our test environment was heavily loaded, generating hundreds of megabytes of logs every minute with aggressive rotation policies. Manual grepping was out of the question.

We instructed Claude to act as a log-sifting agent. We tasked it with finding a specific leaked subject identifier that had a documented discard receipt in the older logs but still maintained an active memory footprint in the latest core dump.

Claude successfully isolated a target subject. The log timeline revealed a lethal concurrency anomaly:

• CLIENT: Sends DISCARD request for Subject_A.
• C SERVER: Processes DISCARD, deletes Subject_A from its native cache, and forwards the message to the Java Module.
• JAVA MODULE: In the same millisecond, but before the Java Module registers the discard, it concurrently fires an asynchronous UPDATE for Subject_A back down to the C Server.

Phase 4: Root Cause Discovery via Codebase Context

Armed with the isolated subject identifier and the overlapping log timeline, we fed the core server codebase to Claude to execute a structural trace.

Because Claude had full contextual visibility of the codebase, it mapped the concurrent events to the underlying state machine, exposing a classic race condition:

1. The DISCARD successfully cleared Subject_A from its native cache and forwarded the message to the Java Module.
2. At the exact same instant after Subject_A is cleared from the cache, but before DISCARD is received by the Java Module, the inbound asynchronous UPDATE from the Java Module forces the server to instantiate a new instance of the Subject_A.
3. Because the original request context was gone, this newly allocated object became a Zombie Subject—it possessed a completely different pointer, had no valid requested peer to listen to it, and lacked any mechanism to ever trigger its own deletion. It was permanently orphaned in native memory.

The Bigger Picture: A Universal Debugging Blueprint

While our team initially navigated this via an explicit log verification loop, this workflow highlights a repeatable paradigm we call Agentic Time-Slice Differential Analysis.

Because terminal-bound AI agents operate natively alongside system utilities, this exact snapshot-and-compare pattern can be applied broadly across other software ecosystems to eliminate manual triage:

• Java Heap Memory Creep: Instead of manual analysis, an agent can be tasked to pull JVM class histograms at set intervals, parse the raw text deltas, and automatically flag which custom class instances are climbing linearly while primitives remain flat.
• Thread Deadlocks & CPU Spinning: An agent can capture back-to-back thread dumps at rapid intervals. It can textually audit the dumps to immediately expose locked states, or track specific Native Thread IDs stuck in runnable states executing the exact same line of code—instantly isolating infinite loops.

By instructing an agent to isolate growing objects via differential snapshot analysis, grep localized timelines out of volatile log streams, and cross-reference those timestamps against code repositories, we transform debugging from a game of intuition into an automated science.