Open knutfrode opened 4 years ago
We found that the problem is avoided with python-netcdf4=1.5.1.2
and libnetcdf=4.6.2
Can't reproduce on my macos machine with libnetcdf 4.6.2, 4.7.0 or 4.7.2. Can't see how the netcdf4-python version would matter since it's a segfault in the netcdf-c library.
I forgot to say that conda-forge was used (as libnetcdf4=4.7.1 is not available in anaconda channel). The problem should be reproducible by:
conda create -n fail -c conda-forge libnetcdf=4.7.1 netcdf4=1.5.3
conda activate fail
and then these lines:
from netCDF4 import Dataset
d1 = Dataset('tmp.nc', 'w')
d1.close()
d2 = Dataset('http://thredds.met.no/thredds/dodsC/meps25epsarchive/2019/11/26/meps_mbr0_extracted_2_5km_20191126T00Z.nc')
print(d2.variables['time'])
do not produce a core dump this time, however, time is an empty variable, instead of length 67 which is correct and obtained within this environment:
conda create -n nofail -c conda-forge libnetcdf=4.6.2 netcdf4=1.5.1
For those trying to run the OP's test script, you have to change the date in the filename - older files age off.
Confirmed on macos x with Ananconda. Must be specific to the Anaconda packages though - if I build netcdf 4.7.1 and netcdf4-python 1.5.3 myself it works fine.
From the traceback, it looks perhaps like the netcdf-c lib is trying to access memory that has already been deallocated by the python garbage collector.
Error also disappears if I upgrade to conda-forge libnetcdf 4.7.3 (but this requires building netcdf4-python from source since the conda-forge package is pinned on 4.7.1 for some reason).
For binary compatibility, all packages in conda-forge are pinned to an exact version of libnetcdf, and they migrate in lock-step. Might be able to request a bump here: https://github.com/conda-forge/conda-forge-pinning-feedstock/issues
It seems that this is no longer an issue with:
netcdf4 1.5.3 nompi_py38hd35fb8e_102 conda-forge
I encounter the following problem on Ubuntu 18.04 with conda and python 3.6-3.8 (not with Python2). libnetcdf version is 4.7.1, and is locked since I need gdal simultaneously.
The following lines:
give a core dump:
If I omit the first generation of the local file (d1), it returns as expected:
This is the same for two different OPeNDAP datasets with time as an unlimited dimension. For another dataset with time as fixed size, there is no core dump.
Thus the problem can be formulated as:
Here is the back trace: