Fix SIGSEGV from HDF5 library teardown and concurrent access

[chraibi]

Loading an HDF5 simulation could crash the editor outright:

LogHdf5SimulationReader: Error: Failed to open HDF5 file: .../mobius_ringed.h5
=== Critical error: ===
SIGSEGV: invalid attempt to access memory at address 0x20

Hdf5DataPlugin!H5P__access_class()
Hdf5DataPlugin!H5P_create_id()
Hdf5DataPlugin!H5T__init_package()
Hdf5DataPlugin!H5_init_library()
Hdf5DataPlugin!H5open()
Hdf5DataPlugin!FHdf5SimulationReader::OpenFile(FString const&)
ProjectMobius!FProcessSimulationDataRunnable::LoadAndDeserializeHDF5File()
ProjectMobius!FProcessSimulationDataRunnable::Run()
Core!FRunnableThreadPThread::Run()

Cause

Two independent problems combine:

1. H5close() is a process-wide shutdown, not a per-file close. It was called in three places — CloseFile(), OpenFile()'s error path, and DetectFormat(). Any reader finishing its work therefore demolished the HDF5 library for every other reader. In the crash above, one thread ran H5close() while the trajectory worker was still inside H5_init_library(), so the property-class table it was walking was freed underneath it.

2. The bundled HDF5 is not thread-safe. Plugins/Hdf5DataPlugin/Source/ThirdParty/hdf5-2.0.0/install/lib/libhdf5.settings reports Threadsafety: OFF, and the superbuild passes no HDF5_ENABLE_THREADSAFE. Two threads executing HDF5 code at once is undefined behaviour even when they are reading different files — and the geometry loader (FAssimpMeshLoaderRunnable) and the trajectory loader (FProcessSimulationDataRunnable) each open .h5 files on their own threads.

Change

• Every public reader method takes a process-wide recursive critical section: OpenFile, CloseFile, DetectFormat, and the nine Read* methods. Recursive because OpenFile calls CloseFile internally.
• All H5close() calls removed. The library now lives for the lifetime of the process, which is the normal way to use HDF5; H5Fclose(FileId) still releases each file.

Known trade-off: a geometry load and a trajectory load of the same file now queue rather than interleave. Ordered and slower beats concurrent and crashing. The alternative — rebuilding HDF5 with HDF5_ENABLE_THREADSAFE=ON — is a larger change and may conflict with HDF5_BUILD_HL_LIB=ON; worth considering separately if the serialization ever shows up as a bottleneck.

Verification

macOS, UE 5.5.4, 170 MB Juelich file (7.17M trajectory records, 516 entities): crashed reliably before, loads cleanly after, with geometry and trajectories read from the same file on different threads.

Note

Hdf5DataExampleTest.cpp still calls H5open()/H5close() directly. It is automation-test-only code and left untouched here to keep the change minimal, but running that test alongside a loaded simulation would reintroduce the same teardown hazard.

[Copilot]

Pull request overview

This PR prevents editor crashes when loading HDF5 simulations by removing process-wide HDF5 shutdown calls (H5close) from the reader and serializing all HDF5 API usage in FHdf5SimulationReader to account for the bundled non-thread-safe HDF5 build.

Changes:

• Introduces a process-wide critical section guard used by all public FHdf5SimulationReader methods that touch HDF5.
• Removes H5close() calls from OpenFile() error paths, CloseFile(), and DetectFormat() so one reader cannot tear down the HDF5 library for the entire process.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.