TDocStd_Document constructor aborts with uncaught Standard_NullObject on Ubuntu 26.04 (conda-forge builds 7.8.1.1 and 7.9.0)

[ViNOJ-DAViS]

On an up-to-date Ubuntu 26.04 x86_64 machine, constructing any OCAF document terminates the interpreter immediately:

from OCC.Core.TCollection import TCollection_ExtendedString
from OCC.Core.TDocStd import TDocStd_Document
TDocStd_Document(TCollection_ExtendedString("x"))

terminate called after throwing an instance of 'Standard_NullObject'
Aborted (core dumped)

Everything else in pythonocc works on this machine (STEP read via STEPControl_Reader/read_step_file, BRep queries, GProp, BRepMesh, BRepAlgoAPI). Only the OCAF/XCAF layer is affected, and it fails before any file is read — at the first TDocStd_Document construction.

Reproduction

Reproduces in a fresh, minimal environment (so it is not contamination):

conda create -n occtest -c conda-forge python=3.11 pythonocc-core=7.9 -y
conda run -n occtest python -c "from OCC.Core.TCollection import TCollection_ExtendedString; from OCC.Core.TDocStd import TDocStd_Document; TDocStd_Document(TCollection_ExtendedString('x')); print('OK')"
# -> terminate called after throwing an instance of 'Standard_NullObject'

Identical behaviour on:

• pythonocc-core 7.8.1.1 (occt 7.8.1 novtk_he2768ca_103)
• pythonocc-core 7.9.0 novtk_hd67cc01_102 (occt 7.9.0 novtk_h09ba48e_104)

Tried with and without registering the document through XCAFApp_Application.GetApplication().NewDocument(...) — same abort, and the application handle itself is obtained successfully.

Environment

• OS: Ubuntu 26.04 (glibc 2.43)
• CPU: AMD Ryzen AI 7 350 (Zen 5)
• Python 3.11 (conda-forge), all packages conda-forge, no pip OCC packages present (verified: no OCP/cadquery distributions, single copy of libTK* in the env, LD_LIBRARY_PATH/LD_PRELOAD unset)

Backtrace

gdb on the reproducer:

#5  __gnu_cxx::__verbose_terminate_handler ()
#6  __cxxabiv1::__terminate
#7  std::terminate ()
#8  __cxxabiv1::__cxa_throw (tinfo=<typeinfo for Standard_NullObject>)
#9  ?? () from <env>/lib/python3.11/site-packages/OCC/Core/../../../../libTKernel.so.7.9
#10 _wrap_new_TDocStd_Document () from <env>/lib/python3.11/site-packages/OCC/Core/_TDocStd.so

Two observations that may help localise it:

1. The throw originates in libTKernel during _wrap_new_TDocStd_Document. Reading OCCT 7.9 sources, the constructor body reaches TDocStd_Owner::SetDocument(myData, this) -> indata->Root().FindAttribute(...), i.e. handle dereferences whose null-check throws Standard_NullObject — yet myData is initialised as new TDF_Data() in the member initialiser list, so a genuinely null handle there seems impossible in a healthy build.
2. The exception propagates straight from __cxa_throw to std::terminate — no catch handler is found — although the SWIG wrapper for the constructor should catch Standard_Failure. This looks like exception handling / typeinfo matching failing across the DSO boundary (libTKernel.so -> _TDocStd.so) on this toolchain, in which case even a benign internal throw would become fatal.

Cross-check
The pip-distributed OCCT binding (cadquery-ocp 7.9.3, manylinux build, different toolchain) runs the equivalent XCAF code successfully on the same machine — document creation, STEPCAFControl transfer, shape/colour/ material/DimTol tools all fine. So the machine itself is capable of running OCCT 7.9 XCAF; the failure appears specific to the conda-forge build in combination with this OS/toolchain (possibly the new glibc 2.43 / Ubuntu 26.04 runtime).

Happy to run additional diagnostics on this machine (debug builds, LD_DEBUG traces, specific probes) — please tell me what would help.