std::bad_alloc error

[dreram]

I keep getting this memory error for bad_alloc. THis occurs at random for the same file at random times. For the same file, it occurs some times and does not occur some other times. I am runng docling -v -vv input.pdf outputDir

Here is a part of the error messages I am getting:
2026-07-19 21:19:03,467 DEBUG httpcore.http11: receive_response_body.complete
2026-07-19 21:19:03,467 DEBUG httpcore.http11: response_closed.started
2026-07-19 21:19:03,467 DEBUG httpcore.http11: response_closed.complete
2026-07-19 21:19:03,542 INFO docling.utils.accelerator_utils: Accelerator device: 'cpu'
2026-07-19 21:19:05,042 INFO docling.pipeline.base_pipeline: Processing document embedded-images-tables.pdf
2026-07-19 21:19:05,112 DEBUG pypdfium2._lazy: Evaluating lazy import 'PIL.Image' ...
2026-07-19 21:19:06,287 ERROR docling.pipeline.standard_pdf_pipeline: Stage preprocess failed for run 1, pages [1]: std::bad_alloc
2026-07-19 21:19:06,290 DEBUG docling.pipeline.standard_pdf_pipeline: Added 1 failed/skipped pages to document: [1]
2026-07-19 21:19:06,293 INFO docling.document_converter: Finished converting document embedded-images-tables.pdf in 7.24 sec.
2026-07-19 21:19:06,293 WARNING docling.cli.main: Document C:\Users\drera\AppData\Local\Temp\tmp06ccej_3\embedded-images-tables.pdf failed to convert.
2026-07-19 21:19:06,293 INFO docling.cli.main: [Failure Detail] Component: DoclingComponentType.MODEL, Module: preprocess, Message: std::bad_alloc
2026-07-19 21:19:06,293 INFO docling.cli.main: Processed 1 docs, of which 1 failed
2026-07-19 21:19:06,300 INFO docling.cli.main: All documents were converted in 7.25 seconds.

Is there some setting that can be altered for this to be corrected?

[dolfim-ibm]

@dreram can you please provide the output of docling --version and the example file which generates the error?

[dreram]

Thank you for the update.
Here is the verison output. Is there any other log settings that can be changed to create more granular logs that might be of help?

(venv) PS C:\projects\pythonServices\pdfService> docling --version
Docling version: 2.113.0
Docling Core version: 2.86.0
Docling IBM Models version: 3.13.3
Docling Parse version: 7.7.0
Python: cpython-314 (3.14.6)
Platform: Windows-11-10.0.26200-SP0

Explanation:
the error occurs often and randomly. Once one file fails like this, all other attempts at other files also fails with the same error. At times I have a whole batch working perfectly well, and then there are times when the exact same batch of files fails with the same std::bad_alloc error. So it does not matter which file I use. I was able to parse this without errors a few times, but then now it fails most of the time.

Any advise on how to automate this, for example from java spring boot back end.

Thanks
embedded-images-tables.pdf

[wittjeff]

I dug into this and found the root cause. TL;DR: upgrade docling-parse to ≥ 7.12.0 (pip install -U docling-parse) — it fixes exactly this. Your docling 2.113.0 accepts any docling-parse >=7.0,<8, so nothing else needs to change.

What's happening. In docling-parse ≤ 7.11, every page decode constructs seven internal cell containers, and each constructor did cells.reserve(1000000) — one million 352-byte cell slots — i.e. ~2.4 GB of allocations per page decode, regardless of the page's content. On Linux this went unnoticed because the memory is reserved but barely touched, and Linux only charges for touched pages. Windows charges the full amount against the commit limit (RAM + pagefile) at allocation time. So whenever your machine had less than ~2.4 GB of free commit at the moment a page decode started, the C++ new threw std::bad_alloc, which surfaces exactly as your log shows:

ERROR  docling.pipeline.standard_pdf_pipeline: Stage preprocess failed for run 1, pages [1]: std::bad_alloc
[Failure Detail] Component: DoclingComponentType.MODEL, Module: preprocess, Message: std::bad_alloc

That also explains the randomness: whether a run fails depends on what else is committed on the machine at that instant — same file, same command, different outcome. And once the machine is under commit pressure, every subsequent run fails too, which matches the "one fails, then everything fails" pattern you described.

This was fixed upstream in docling-parse#311 (released in v7.12.0 on 2026-08-08 — a few days ago).

Verification (Windows 11 build 26200, same docling versions as yours, process commit capped via a Job Object at model-load + 500 MB to simulate a machine under memory pressure):

• docling-parse 7.7.0: std::bad_alloc in preprocess — character-for-character your error. Peak commit for converting your attached PDF: 3.5 GB.
• docling-parse 7.12.1, same cap: SUCCESS. Peak commit: 1.8 GB.

Isolated, the per-page decode peak drops from ~2.2 GB to ~69 MB.

Still worth doing on a constrained Windows box:

1. If your Java/Spring Boot backend spawns docling processes, bound the concurrency — even after the fix, each process peaks around 1.8 GB of commit (models + inference).
2. Consider a long-lived docling-serve instance called over HTTP instead of a CLI process per document — you pay the ~1.4 GB model load once instead of per invocation.
3. If you ever see commit-related failures again, check Task Manager → Performance → Memory → "Committed" at failure time, and give Windows a roomier pagefile.