SIGABRT crash on Python 3.12 — all docling versions fail on Databricks Serverless

[Aviral0]

Bug

Docling crashes with SIGABRT (exit code 134) when calling converter.convert() on Python 3.12 in Databricks Serverless (Standard v5 runtime). The crash occurs on even a trivially small PDF (0.4 MB, ~10 pages). The same code works perfectly on Python 3.10 (Standard v1 runtime) with identical configuration.

The kernel is killed immediately after the StandardPdfPipeline initializes its plugins (layout, OCR, table structure engines all register successfully), but before any page processing begins. The error is a native-level SIGABRT, not a Python exception — suggesting an assertion failure inside a C/C++ extension (docling-parse or deepsearch-glm).

Last log output before crash:

Initializing pipeline for StandardPdfPipeline with options hash 0c22bedbf11f2ec242f5408ec6e34dfb
Loading plugin 'docling_defaults'
Registered picture descriptions: ['picture_description_vlm_engine', 'vlm', 'api']
Registered ocr engines: ['auto', 'easyocr', 'ocrmac', 'rapidocr', 'tesserocr', 'tesseract']
Registered layout engines: ['layout_object_detection', 'docling_layout_default', 'docling_experimental_table_crops_layout']
Accelerator device: 'cpu'
Registered table structure engines: ['docling_tableformer', 'docling_tableformer_v2']

Then:

The Python process exited with exit code 134 (SIGABRT: Aborted).

We are currently forced to pin our Databricks job environment to Python 3.10, which Databricks has deprecated as the default. Standard v5 (Python 3.12) is now the default serverless runtime, and Standard v1 (Python 3.10) will be retired. This makes docling unusable on the standard Databricks serverless platform for PDF processing.

We'd appreciate guidance on:

1. Is Python 3.12 on Linux officially supported/tested?
2. Are there known incompatibilities with docling-parse native wheels on certain glibc versions?
3. Is there a specific version combination that's known to work on 3.12?

Steps to reproduce

1. Create a Databricks Serverless notebook on Standard v5 (Python 3.12)
2. Install docling:

   %pip install setuptools>=70.0 docling>=2.73.1

3. Restart kernel:

   dbutils.library.restartPython()

4. Run:

   from docling.document_converter import DocumentConverter, PdfFormatOption
   from docling.datamodel.pipeline_options import PdfPipelineOptions
   from docling.datamodel.base_models import InputFormat
   
   pdf_options = PdfPipelineOptions()
   format_options = {InputFormat.PDF: PdfFormatOption(pipeline_options=pdf_options)}
   converter = DocumentConverter(format_options=format_options)
   
   # This line causes SIGABRT — even on any small PDF
   result = converter.convert("/path/to/any_small.pdf")

5. Kernel crashes with exit code 134 (SIGABRT)

Notes:

• DocumentConverter initialization succeeds (0.09s) — crash is during convert()
• OCR is disabled (do_ocr: False)
• Crash is not related to file size — happens on a 0.4 MB, ~10 page PDF
• Same file processes successfully on Python 3.10 (Standard v1) with identical code
• All other native packages (torch, scipy, sklearn, rdkit, lxml) load and run fine on 3.12
• Tested with docling>=2.61.2, docling>=2.73.1, and latest — all crash identically

Docling version

Tested with:

• docling>=2.61.2 (resolved to 2.61.2)
• docling>=2.73.1 (resolved to 2.73.1)
• docling latest as of 2026-03-28

All produce identical SIGABRT on Python 3.12.

Python version

Crashes on:

Python 3.12.x (Databricks Serverless Standard v5, Linux)

Works on:

Python 3.10.x (Databricks Serverless Standard v1, Linux)

[dosubot]

Hi @Aviral0! I'm Dosu and I’m helping the docling team.

This is a known issue — SIGABRT crashes with docling-parse native extensions have been reported on Python 3.12 with glibc 2.39. The crashes manifest as heap corruption (free(): invalid pointer) during PDF loading in the native C/C++ code, which is why you see a native-level abort rather than a Python exception.

Workaround: Switch to the pypdfium2 backend, which bypasses the problematic docling-parse native code:

from docling.backend.pypdfium2_backend import PyPdfiumDocumentBackend
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.base_models import InputFormat

converter = DocumentConverter(
    format_options={
        InputFormat.PDF: PdfFormatOption(backend=PyPdfiumDocumentBackend)
    }
)

result = converter.convert("/path/to/any_small.pdf")

This workaround has been confirmed to resolve similar crashes on Python 3.12, 3.13, and 3.14.

Note: A memory lifecycle fix for the pypdfium2 backend (PR #3180) was just merged on March 24, 2026, addressing SIGSEGV crashes in concurrent scenarios. Make sure you're on the latest docling version to benefit from this fix.

To answer your specific questions:

1. Python 3.12 support: Yes, Python 3.12 is officially supported, but the docling-parse backend has known heap corruption issues on certain glibc versions.
2. glibc incompatibilities: Yes, crashes have been specifically confirmed on glibc 2.39 with Python 3.12/3.13 on Linux.
3. Working version combination: Use pypdfium2 backend instead of relying on a specific version—this is the recommended path forward for environments experiencing these crashes.

To reply, just mention @dosu.

---

Share context across your team and agents. Try Dosu.

[Aviral0]

@dosu - is the quality of parsing same with both docling-parse and PyPdfiumDocumentBackend?

[dosubot]

No, the parsing quality is not the same — docling-parse produces significantly better results in most cases:

Key differences:

• Layout analysis: docling-parse provides full layout analysis (heading detection, reading order, multi-column handling, semantic segmentation). pypdfium2 has no layout analysis — it uses simple heuristics that often fail for complex layouts.
• Table extraction: pypdfium2 can miss tables entirely or fail to detect cell structure. docling-parse (especially v4) provides much better table detection and cell matching.
• Cell granularity: docling-parse provides character, word, and textline cells with clean boundaries. pypdfium2 only provides textline cells and often produces fragmented sub-word boundaries.

Where pypdfium2 may be better:

• Faster and more memory-efficient
• Better handling of non-ASCII characters (e.g., Turkish) due to more robust font encoding
• Workaround for the SIGABRT crash you're experiencing

Bottom line: For your Databricks use case, pypdfium2 should work as a crash workaround, but expect reduced quality for complex layouts and tables. If your PDFs are simple (single-column, no complex tables), the difference may be acceptable.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Aviral0]

@dosu
isn't layout analysis backend agnostic?

Layout analysis, heading detection, reading order, semantic segmentation are NOT backend-dependent. These are all done by AI models in the StandardPdfPipeline, completely independent of the backend:

Layout analysis: Done by the DocLayNet model (layout_model) operating on page images — standard_pdf_pipeline.py creates dedicated layout stage
Reading order: Done by ReadingOrderModel — separate from backend
Heading detection / semantic segmentation: Done by the layout model's cluster predictions
Both backends produce identical page images via their get_page_image() method. The layout model doesn't care which backend rendered the bitmap.

[dosubot]

You're correct — I apologize for the confusion in my previous response.

Looking at the code, layout analysis, heading detection, reading order, and semantic segmentation are indeed backend-agnostic. The LayoutModel operates on rendered page images via layout_predictor.predict_batch(valid_page_images), and the StandardPdfPipeline architecture clearly separates backend responsibilities (stage 1: rendering) from AI model responsibilities (stages 2-5: semantic analysis).

What IS different between backends:

• Text cell extraction: docling-parse provides clean hierarchical cells (word, textline, char), while pypdfium2 produces fragmented sub-word level cells requiring merging
• Table cell matching: When do_cell_matching=True, the backend's cell boundaries affect how table structure predictions align with PDF text cells

So for your Databricks use case, switching to pypdfium2 should give you the same layout analysis quality — the main trade-off is in native text extraction and table cell matching accuracy, not in the AI-powered semantic understanding.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[Aviral0]

@dosu
so I think the only impact with the pypdfium2 backend could be in table structure

[dosubot]

Yes, that's the right takeaway. The main impact with pypdfium2 is in table cell matching — specifically when do_cell_matching=True, where the TableFormer model aligns its predictions with the backend's PDF cells. Since pypdfium2 produces more fragmented cells at sub-word boundaries, this can affect how cleanly table text gets extracted.

If your PDFs don't have complex tables (or you can live with slightly less precise table cell text), pypdfium2 should work well as a workaround for the SIGABRT crash on Python 3.12.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[ManojDjs]

Same issue

[MEdWat]

An odd hack fix. (you can create a cluster and run python 3.10 on that but you probably know that) or if you need to use serverless if you import an external notebook you can get serverless to run python 3.10 not 3.12

[Aviral0]

@dosu
Running 3.10 attracts a lot of question from devops /client/security team as to why we are not using the latest python version etc etc as because 3.10 is quite old now and may not have support for latest releases.
So wanted to ask, is there a plan to fix this in near future?

[Aviral0]

@dosu

[dosubot]

Completely understand the concern — pinning to Python 3.10 is not a sustainable solution, especially with enterprise security and compliance requirements.

To clarify the current state: Python 3.12 (and up to 3.14) is officially declared as supported by Docling. The underlying issue is specifically in the docling-parse native C/C++ backend, which has heap corruption problems on Python 3.12 with certain glibc versions. I don't have visibility into whether there's a specific fix timeline for docling-parse's native wheels on these environments — that would be a question for the maintainers.

In the meantime, rather than downgrading Python, using the pypdfium2 backend on Python 3.12 should let you stay on the latest runtime. As discussed above, the only quality trade-off is in table cell matching — layout analysis, heading detection, reading order, and semantic segmentation all remain identical since they're powered by AI models operating on page images, not the backend.

To reply, just mention @dosu.

---

Docs are dead. Just use Dosu.

[MEdWat]

I have tried the suggested fix
%pip install docling
dbutils.library.restartPython()

from docling.backend.pypdfium2_backend import PyPdfiumDocumentBackend
from docling.document_converter import DocumentConverter, PdfFormatOption
from docling.datamodel.base_models import InputFormat

converter = DocumentConverter(
format_options={
InputFormat.PDF: PdfFormatOption(backend=PyPdfiumDocumentBackend)
}
)

result = converter.convert("/path/to/any_small.pdf")

And it is still crashing the kernel, so the fix does not work for me running on serverless databricks

[Aviral0]

@dosu