Loading hsdis library failed

Hi! I am running a C2RCC operator for Sentinel-2 image. Whenever I specify output format as NetCDF4-CF I am getting an error. It does not happen when the output format is BEAM-DIMAP. The error is as follows:


# A fatal error has been detected by the Java Runtime Environment:

# SIGSEGV (0xb) at pc=0x00007fece4b78089, pid=522790, tid=522860

# JRE version: OpenJDK Runtime Environment (21.0.6+10) (build 21.0.6+10-LTS)

# Java VM: OpenJDK 64-Bit Server VM (21.0.6+10-LTS, mixed mode, tiered, compressed class ptrs, g1 gc, linux-amd64)

# Problematic frame:

# C [libc.so.6+0x1a1089]

# Core dump will be written. Default location: Core dumps may be processed with "/usr/lib/systemd/systemd-coredump %P %u %g %s %t %c %h" (or dumping to /processor/snap_gdal_processing/core.522790)

# An error report file with more information is saved as:

# /processor/snap_gdal_processing/hs_err_pid522790.log

[16.022s][warning][os] Loading hsdis library failed

# If you would like to submit a bug report, please visit:

# https://bell-sw.com/support

# The crash happened outside the Java Virtual Machine in native code.

# See problematic frame for where to report the bug.

INFO: org.esa.snap.core.gpf.operators.tooladapter.ToolAdapterIO: Initializing external tool adapters

INFO: org.esa.snap.core.util.EngineVersionCheckActivator: Please check regularly for new updates for the best SNAP experience.

[main] INFO hdf.hdflib.HDFLibrary - HDF4 library:

[main] INFO hdf.hdflib.HDFLibrary - successfully loaded.

[main] INFO hdf.hdf5lib.H5 - HDF5 library:

[main] INFO hdf.hdf5lib.H5 - successfully loaded.

INFO: eu.esa.opt.c2rcc.ancillary.AtmosphericAuxdataBuilder: Atmospheric auxdata product can't be used. At least one is not specified. Using constant values for ozone (330.0) and surface pressure (1000.0).

[main] INFO serverStartup - Nc4Iosp: NetCDF-4 C library loaded (jna_path='/mnt/vol/snapuser/auxdata/netcdf_natives/13.0.0/amd64', libname='netcdf').

[main] INFO serverStartup - NetcdfLoader: set log level: old=0 new=0

[main] INFO serverStartup - Nc4Iosp: set log level: old=0 new=0

It seems to be related to other threads like Java error "invalid memory access" or NetCDF-CF writing: Segmentation fault and metadata issues with SNAP v9.0.4+ but whatever worked in these cases does not help. The image that I am using does not have the mentioned metadata structure, so there is nothing to delete. Is there any workaround or potential fix?

Additional logs from JVM: 1.log (201.8 KB)
The graph: c2rcc_msi_graph.xml (1.5 KB)

You should be able to recreate this with any Sentinel-2 image but I was using: S2C_MSIL1C_20250710T104041_N0511_R008_T32VNM_20250710T141929.SAFE

Could you please confirm that you are using SNAP 13 on Ubuntu 22.04.1 LTS?

Thanks

Yes, I am using Ubuntu 22.04.1 LTS with Snap 13.0.0.

Jira ticket SNAP-4203 created.

1 Like

Dear MrSquidward,

checking the stacktrace you suppplied, the problem should be the same as with the other tickets and threads concerning S2 MSI L1 metadata. The graph you supplied should most likely not be running this way, C2RCC requires the MSI L1 data to be re-sampled to one resolution; it does not operate on multi-resolution data.

Could you please try to remove the “Satellite_Ancillary_Data_Info” during the re-sampling stage and try again to process C2RCC to NetCDF output?

Thanks,

Tom

Sorry for no response - I was on vacation :slight_smile: I will try and let you know. But why this seems to be an issue only when the NetCDF output is selected. It does not happen with other output format options. Did you explore what could be a possible answer?

Hi, yes, I know the answer.

The problem is that the MSI metadata contains this field that I mentioned above, “Satellite_Ancillary_Data_Info”. SNAP stores all structured metadata from a product using nested groups to keep the hierarchical logic of the metadata. Now, this element contains more nodes than the NetCDF library allows (> 32768), so while writing it to NetCDF, this limit is triggered and hence the crash.

It does not happen with other formats, as these do not have a limit on the number of nested metadata groups.

Tom

1 Like