[BUG] OOM with Large PDF

[cpldxx]

---

std::bad_alloc OOM on large PDFs (700+ pages) with docling-parse backend

Bug

When processing large PDFs (700+ pages) with StandardPdfPipeline and the default docling-parse C++ backend, std::bad_alloc errors occur during the preprocessing stage, starting around page 300-345 and affecting the majority of remaining pages. The pipeline continues but layout analysis is silently skipped for failed pages.

Environment

• Docling version: 2.82
• Python version: 3.x
• OS: Windows
• RAM: 32GB
• VRAM: 8GB
• PDF: ~700 pages, math-heavy academic paper (linear algebra formulas, pictures, tables)

Steps to Reproduce

1. Use a 700+ page PDF containing math formulas, images, and tables
2. Convert with default settings:

from docling.document_converter import DocumentConverter

converter = DocumentConverter()
result = converter.convert("large_academic_paper.pdf")

3. Observe std::bad_alloc errors starting around page 300+

Error Output

ERROR:docling.pipeline.standard_pdf_pipeline:Stage preprocess failed for run 1, pages [345]: std::bad_alloc
ERROR:docling.pipeline.standard_pdf_pipeline:Stage preprocess failed for run 1, pages [346]: std::bad_alloc
... (continues for 300+ pages)

Root Cause Analysis

The docling-parse C++ backend accumulates memory internally across pages, bypassing the pipeline's streaming architecture and per-page resource cleanup. With 32GB RAM, memory is exhausted by ~page 345 on image/math-heavy PDFs.

Current Workarounds

1. Page-range batching — process in 50-100 page chunks:

   for start in range(1, 701, 100):
       end = min(start + 99, 700)
       result = converter.convert("large.pdf", page_range=(start, end))

   Problem: Tables spanning batch boundaries are split into separate TableItem objects with no continuation metadata, breaking semantic integrity.

2. PyPdfiumDocumentBackend — avoids memory accumulation but significantly reduces table extraction quality for complex academic tables.

3. Reducing batch sizes (ocr_batch_size=1, layout_batch_size=1) and disabling features — marginal improvement, doesn't solve the core issue.

Feature Request

A built-in mechanism to process large PDFs without accumulating memory in the C++ backend, ideally with:

1. Incremental memory management — release C++ backend memory per-page or per-batch instead of accumulating across the entire document
2. Cross-page table continuity — metadata or merging logic to detect and reconstruct tables that span page/batch boundaries (related: Continued table across pages is split into multiple tables #2976)

Related Issues/PRs

• Continued table across pages is split into multiple tables #2976 — Continued table across pages is split into multiple tables
• feat(pipeline): implement page chunking for converting large documents (parallelizable) #3162 — page_chunk_size PR (closed)
• Page Chunking for large PDF #3088 — Large document OOM

Notes

The v2.74.0 fix for std::bad_alloc resolved some cases but does not address 700+ page image-heavy PDFs on 32GB RAM systems. The StandardPdfPipeline has proper streaming architecture with bounded queues and lazy page loading, but the docling-parse backend's internal memory accumulation bypasses these protections.

[dosubot]

This is a well-documented bug report — thanks for the thorough analysis. Here's some additional context that may help:

Regarding the page_chunk_size approach: PR #3162 was closed/rejected [1], and page_chunk_size does not exist in the current codebase. However, a related parameter page_batch_size exists in BatchConcurrencySettings (default: 4 pages) and controls how pages are grouped during processing [2]. There's also a PageChunker in docling-core that provides page chunking functionality, as noted in #3088 [3].

For your batching workaround, one improvement to try: create a new DocumentConverter instance per batch rather than reusing the same one, as the docling-parse backend may retain internal caches between calls [4]:

from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.pipeline_options import PdfPipelineOptions
from docling.datamodel.base_models import InputFormat

pipeline_options = PdfPipelineOptions(
    generate_page_images=False,
    generate_picture_images=False,
)

for start in range(1, 701, 50):
    end = min(start + 49, 700)
    converter = DocumentConverter(
        format_options={InputFormat.PDF: PdfFormatOption(pipeline_options=pipeline_options)}
    )
    result = converter.convert("large.pdf", page_range=(start, end))
    # process result...
    del converter  # help release C++ backend memory

Recent related fixes that may be relevant:

• A pipeline cache miss bug causing duplicate pipeline instances (and extra memory usage) was fixed in April 2026 [5]
• Lazy parsing (generate_parsed_pages now defaults to False) was added to reduce memory overhead [6]
• PDFium resource lifecycle management improvements help prevent resource leaks [7]

The core issue you've identified — that docling-parse accumulates memory internally across pages, bypassing the pipeline's streaming protections — remains an open problem. The cross-page table continuity request you linked (#2976) is also still unresolved, which makes the batching workaround inherently lossy for spanning tables.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[himax12]

! i want to pick this issue @cpldxx @philnash @emerose @loleg @vancura

[HarryLesnar24]

🙋‍♂️same problem for just 15 pages parsing even I don't do any enrichment or ocr just layout analysis using DoclingParseDocumentBackend

[cpldxx]

This definitely has to do with docling-parse

docling-project/docling-parse#227

here are the reference. The team is working on it from the C++ model side so nothing could be done in this repo I guess.

[div-dhingra]

Such a fascinating issue, tried to get close with my approximation (parallelized chunking: #3162), but the team is working on something from the ground up for it :)