apache/beam · warning

Unable to dump heap:

Error message

Unable to dump heap: 

What it means

MemoryMonitor.tryToDumpHeap logs this warning when dumpHeap() throws any Exception while attempting to write a .hprof heap dump (after releasing the memory reserved for dumping). The method returns null, so no dump is produced; the message is appended to the wrapped cause. This means an OOM diagnosis will lack a heap dump.

Solutions

  1. Ensure the dump target directory has free disk space at least as large as the heap and is writable by the worker.
  2. Check the wrapped cause in the log for the exact failure and fix accordingly (disk full, permission, unsupported option).
  3. If disk is the constraint, configure a smaller heap, or reserve dump space by tuning MemoryMonitor's reservation.
  4. Verify the worker runs on a HotSpot-based JDK that supports the dumpHeap diagnostic command.

Example fix

// before: read-only or tiny volume
--heapDumpFolder=/mnt/ro-volume
// after: writable volume with headroom
--heapDumpFolder=/tmp/heapdumps
Defensive patterns

Strategy: validation

Validate before calling

// verify dump target viability before relying on dumping
File dumpDir = new File(dumpFolder);
long heapBytes = Runtime.getRuntime().maxMemory();
if (dumpDir.getUsableSpace() < heapBytes) throw new IllegalStateException("insufficient disk for heap dump in " + dumpFolder);

Try / catch

try { monitor.tryToDumpHeap(); } catch (Throwable t) { LOG.warn("dump attempt failed entirely", t); }

Prevention

When it happens

Trigger: The HotSpotDiagnosticMXBean / dumpHeap call fails under severe memory pressure: not enough free disk for the dump, dump target not writable, unsupported JVM flags, or OOM while writing the dump itself.

Common situations: Containers with small or read-only filesystems attempting to dump multi-GB heaps; JVMs started with HeapDumpOnOutOfMemoryError interfering; restricted security managers or non-HotSpot JVMs.

Related errors


AI-assisted analysis of apache/beam@12126d8942 (2026-09-13). Data as JSON: /api/errors/9eb7428e82881673. Report an issue: GitHub.

Appendix: source

Thrown at sdks/java/harness/src/main/java/org/apache/beam/fn/harness/status/MemoryMonitor.java:498

   * Dumps the heap to a file and return the name of the file, or {@literal null} if the heap should
   * not or could not be dumped.
   *
   * @return The name of the file the heap was dumped to, otherwise {@literal null}.
   */
  public @Nullable File tryToDumpHeap() {
    if (!canDumpHeap) {
      return null;
    }

    // Clearing this list should "release" some memory that will be needed to dump the heap.
    // We could try to reallocate it again if we later notice memory pressure has subsided,
    // but that is risk. Further, leaving this released may help with the memory pressure.
    reservedForDumpingHeap = null;

    try {
      return dumpHeap();
    } catch (Exception e) {
      LOG.warn("Unable to dump heap: ", e);
      return null;
    }
  }

  @SuppressFBWarnings("DM_EXIT") // we deliberately System.exit under memory
  private void shutDownDueToGcThrashing(int thrashingCount) {
    File heapDumpFile = tryToDumpHeap();
    LOG.error(
        "Shutting down JVM after {} consecutive periods of measured GC thrashing. "
            + "Memory is {}. Heap dump {}.",
        thrashingCount,
        describeMemory(),
        heapDumpFile == null ? "not written" : ("written to '" + heapDumpFile + "'"));

    System.exit(1);
  }

  /** Runs this thread. */

View on GitHub (pinned to 12126d8942)