Memory Leak

A common source in object-oriented and agentic systems. Objects with a long lifecycle (e.g., a session manager, agent orchestrator, or global cache) hold references to other objects, preventing their garbage collection even after they are logically 'done'.

• Example: An agent's conversation history is stored in a list referenced by the main Agent class. If the history is never trimmed or cleared, it grows indefinitely with each interaction.
• Root Cause: The reference chain from a GC root (like a static variable or main thread stack) to the unused data remains intact.

Prevalent in event-driven architectures common to UIs, agents, and streaming systems. Objects register as listeners for events but are not properly removed, causing the event publisher to hold live references.

• Example: An observability module subscribes to an agent's internal event bus. If the module is disposed but not unsubscribed, the agent retains the reference, leaking the module and all data it holds.
• Mitigation: Implement lifecycle hooks (e.g., dispose(), close()) that enforce deregistration.

Caches that grow without a bound or a eviction policy are deliberate memory leaks. This is a critical consideration for agentic memory systems like vector stores or conversation caches.

• Key Mechanisms:
  • No Size Limit: Cache accepts entries indefinitely.
  • No TTL: Entries never expire based on time.
  • Ineffective Policy: An eviction policy like LRU is implemented but never invoked because the cache limit is set too high or is dynamic.
• Engineering Control: Must implement explicit policies like LRU, LFU, or TTL and monitor cache size.

In languages with tracing garbage collectors (e.g., Java, Go, C#, Python), groups of objects that reference each other but are not reachable from any GC root can still be collected. However, circular references involving finalizers or references from native code can prevent collection.

• Modern GCs (Java's G1, Go's GC) handle simple circular references.
• Persistent Leak Scenario: Object A → Object B → Object A, where one object has a finalizer that references the other, delaying or preventing cleanup.
• Native Interop: A Java object held by JNI code creates a reference from the native side that the JVM GC cannot see.

Thread-local variables (ThreadLocal in Java, thread-local storage in C++) provide data isolation but can cause large leaks, especially in thread-pool environments.

• Mechanism: A worker thread from a pool uses a ThreadLocal to store a large context object (e.g., a request-specific agent session). After the request finishes, the thread returns to the pool, but the ThreadLocal data persists for the thread's lifetime.
• Impact: Memory usage scales with maximum pool size, not active workload.
• Solution: Explicitly call ThreadLocal.remove() after processing or use inheritable structures with scoped cleanup.

System resources that consume kernel-managed memory are often misdiagnosed as application memory leaks. The failure to release these resources causes the OS to leak memory on the application's behalf.

• Common Culprits:
  • File Descriptors: Unclosed files, sockets, or database connections.
  • Graphics/Memory Handles: In GPU-accelerated agent workloads.
  • Zombie Processes: Child processes not wait()ed on.
• Detection: Monitor system-level metrics (e.g., ls /proc/<PID>/fd on Linux) in addition to heap usage.

A cache eviction policy is a predetermined algorithm that determines which items to remove from a finite cache when it reaches capacity. Effective policies are crucial to prevent caches from growing unbounded—a common source of memory leaks.

• Purpose: Balances cache hit rate with memory footprint by removing less valuable data.
• Common Algorithms:
  • LRU (Least Recently Used): Evicts the item unused for the longest time.
  • LFU (Least Frequently Used): Evicts the item with the fewest accesses.
  • TTL (Time-To-Live): Evicts items after a fixed duration.
• Agentic Context: In agent memory systems, eviction policies manage the working set of relevant context, preventing the accumulation of stale experiences that consume resources without value.

The Out-Of-Memory (OOM) Killer is a Linux kernel process that selectively terminates applications when the system is critically low on available RAM. It is a last-resort consequence of unmitigated memory leaks or excessive allocation.

• Mechanism: The kernel assigns an oom_score to each process based on its memory usage and priority. The process with the highest score is terminated to free memory.
• Relation to Leaks: A process with a memory leak will continuously increase its RSS (Resident Set Size), raising its oom_score and making it the prime target for termination.
• System Design Implication: For production agentic systems, monitoring memory pressure and implementing soft limits is essential to avoid abrupt, non-deterministic termination by the OOM Killer.

Thrashing is a severe performance degradation state where a system spends excessive time swapping data pages between main memory (RAM) and disk (swap space), drastically reducing useful computational work.

• Cause: Often triggered by memory pressure from leaks or overload, causing the working set of active processes to exceed available physical RAM.
• Symptoms: Extremely high disk I/O, near-100% CPU wait time, and system unresponsiveness.
• In Agentic Systems: An agent whose memory footprint leaks and exceeds its allocation can cause thrashing in its container or host, degrading not only its own performance but that of co-located services. This violates performance isolation guarantees.

Memory fragmentation is a condition where free memory is broken into small, non-contiguous blocks, preventing the allocation of larger contiguous segments despite sufficient total free space. It exacerbates problems caused by memory leaks.

• Types:
  • External Fragmentation: Free memory is scattered between allocated blocks.
  • Internal Fragmentation: Allocated memory blocks are larger than requested, wasting space within the block.
• Impact: Leads to premature allocation failures and increased overhead for memory managers. Can force increased paging/swapping, contributing to thrashing.
• Management: Techniques like memory pooling (allocating fixed-size blocks) or compaction (relocating allocated blocks) are used to mitigate fragmentation, especially in long-running agent processes.

A resource leak is a broader category of software bug where a program fails to release a finite system resource after it is no longer needed. Memory is one type of resource; others include file handles, database connections, network sockets, and GPU memory.

• Broader Scope: While a memory leak specifically concerns RAM, a resource leak can starve any limited system pool.
• Common in Agents: Agentic systems are prone to resource leaks from:
  • Unclosed connections to vector databases or knowledge graphs.
  • Unreleased file descriptors from reading tool outputs or documents.
  • Unfreed GPU tensors after inference steps.
• Prevention: Requires disciplined use of try-finally blocks, RAII (Resource Acquisition Is Initialization) patterns, or context managers (with statements in Python) for all resource acquisition.