ncdump crashes on this file

[jswhit]

A netcdf4-python user reported that opening this file crashes the python interpreter. Simply running ncdump on it causes a crash. On my mac:

jwhitaker% ncdump s1a-wv2-ocn-vv-20151204t000217-20151204t000219-008884-00cb47-044.nc
Assertion failed: (type == NC_BYTE || type == NC_CHAR || type == NC_SHORT || type == NC_INT || type == NC_FLOAT || type == NC_DOUBLE || type == NC_UBYTE || type == NC_USHORT || type == NC_UINT || type == NC_INT64 || type == NC_UINT64 || type == NC_STRING), function v1h_get_nc_type, file v1hpg.c, line 211.
Abort

[jswhit]

ncFile.zip

[DennisHeimbigner]

This is a known problem and there is a fix for it. But unfortunately, we are backed up in merging pull requests, so it has not made it into master or the 4.5 rc. I am attaching the file that needs to change. (actually a zip containing that file) d4rc.zip It should be compatible with master branch and all the v4.5 rc branches.

[WardF]

Oh! I take back what I said about the issue. Dennis, was there an open issue (or closed) related to this I can reference?

On Fri, Sep 8, 2017 at 1:55 PM, DennisHeimbigner notifications@github.com wrote:

This is a known problem and there is a fix for it. But unfortunately, we are backed up in merging pull requests, so it has not made it into master or the 4.5 rc. I am attaching the file that needs to change. (actually a zip containing that file) d4rc.zip https://github.com/Unidata/netcdf-c/files/1288850/d4rc.zip It should be compatible with master branch and all the v4.5 rc branches.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Unidata/netcdf-c/issues/481#issuecomment-328198913, or mute the thread https://github.com/notifications/unsubscribe-auth/AEH-UhmzDOWOpmFGPT9SsfeNQ8xvJFTgks5sgZusgaJpZM4PRUm8 .

[DennisHeimbigner]

Fixed by pr https://github.com/Unidata/netcdf-c/pull/482 and now merged into branch v4.5-release-candidate

[stefanomattia]

Hi, I seem to be experiencing the same kind of problem opening my netCDF4 files. Everything was working fine until yesterday. Then I updated my python netCDF4 installation to 1.3.1 (py36_2 conda-forge) and now python crashes every time I try to open a product.

Whenever I try to open my products within python, the interpreter crashes with an Abort trap: 6 error. Same happens when trying to use ncdump on them.

$ ncdump S5P_OFFL_L2__NO2____20171129T010127_20171129T024256_00662_01_001107_20171202T195637.nc
Abort trap: 6

I downloaded the zip file from the original poster and it crashes too, giving some more information about failed asserts:

$ ncdump s1a-wv2-ocn-vv-20151204t000217-20151204t000219-008884-00cb47-044.nc
Assertion failed: (type == NC_BYTE || type == NC_CHAR || type == NC_SHORT || type == NC_INT || type == NC_FLOAT || type == NC_DOUBLE || type == NC_UBYTE || type == NC_USHORT || type == NC_UINT || type == NC_INT64 || type == NC_UINT64 || type == NC_STRING), function v1h_get_nc_type, file /Users/travis/miniconda3/conda-bld/libnetcdf_1510201535320/work/netcdf-c-4.5.0/libsrc/v1hpg.c, line 212.
Abort trap: 6

The ncdump executable comes from the Anaconda distribution, which I just reinstalled from scratch hoping it was just a dependency problem.

netcdf library version 4.5.0 of Nov 9 2017 04:27:50 $

As an additional information, in the meantime I also updated the Command Line Tools (macOS High Sierra version 10.13) for Xcode, not quite sure if that had an impact too, as I started experiencing this problem before this upgrade, and just after upgrading the python netCDF4 package to 1.3.1

EDIT: downgrading to conda netCDF4 package 1.2.4 solved my issue, now at least I can open my products again. (Strangely enough the ncdump executable is not installed with this version.)

In [1]: import netCDF4 as nc

In [2]: nc.__version__
Out[2]: '1.2.4'

In [3]: nc.Dataset('S5P_OFFL_L2__NO2____20171129T010127_20171129T024256_00662_01_001107_20171202T195637.nc')
Out[3]:
<class 'netCDF4._netCDF4.Dataset'>
[rest of output]

This version of the conda package uses libnetcdf 4.4.1:

netcdf4 1.2.4 np113py36_1
-------------------------
file name   : netcdf4-1.2.4-np113py36_1.tar.bz2
name        : netcdf4
version     : 1.2.4
build string: np113py36_1
build number: 1
channel     : defaults
size        : 551 KB
arch        : x86_64
date        : 2017-06-22
license     : MIT
md5         : d5e28712f32e963156e8d1322dc86217
noarch      : None
platform    : darwin
url         : https://repo.continuum.io/pkgs/free/osx-64/netcdf4-1.2.4-np113py36_1.tar.bz2
dependencies:
    hdf5 1.8.17
    libnetcdf 4.4.1
    numpy 1.13*
    python 3.6*
    zlib 1.2.*

The netCDF4 conda-forge package 1.3.1 uses libnetcdf version 4.5.0.

Using the latest netCDF4 conda package 1.3.1, which seems to be using libnetcdf >=4.4.1.1,<4.4.2.0a0 from Anaconda also fails in the same way.

netcdf4 1.3.1 py36hdbd7e57_2
----------------------------
file name   : netcdf4-1.3.1-py36hdbd7e57_2.tar.bz2
name        : netcdf4
version     : 1.3.1
build string: py36hdbd7e57_2
build number: 2
channel     : defaults
size        : 669 KB
arch        : None
license     : OSI Approved and MIT
md5         : 39527841c534f1f7201501d00baa7f15
noarch      : None
platform    : None
subdir      : osx-64
timestamp   : 1511886941305
url         : https://repo.continuum.io/pkgs/main/osx-64/netcdf4-1.3.1-py36hdbd7e57_2.tar.bz2
dependencies:
    hdf5 >=1.10.1,<1.10.2.0a0
    libnetcdf >=4.4.1.1,<4.4.2.0a0
    numpy >=1.9.3,<2.0a0
    python >=3.6,<3.7.0a0
    setuptools

Could it be related to the libnetcdf version used to write the products?

[stefanomattia]

2nd update.

Opening the same products on Linux, with either libnetcdf 4.1.1.1 or libnetcdf 4.5.0 (and of course 4.1.1) does not result in any crash: the products are perfectly readable.

The issue then seems to be only affecting OS X.

Would you know whom I should report this issue to?

[DennisHeimbigner]

Did you try applying the fix'd file above to see if it fixes your problem?

[stefanomattia]

I haven't yet, but I suspect it is a conda packaging issue, as the problem doesn't show up with the same environment on Linux. I opened an issue with anaconda, I'll keep you informed.

[stefanomattia]

It turned out to be a buffer overrun bug, which was caught on OS X because the netCDF4 package was built with the -fstack-protector-strong CFLAG.

[DennisHeimbigner]

Will you either setup a pull request or send me the fix?

[stefanomattia]

I believe it's been taken care of in issue 729.

[WardF]

I'm still seeing this with both the fix for #729 and #482 merged in. Investigating further.

[WardF]

Also seeing this in linux currently, so investigating further.

[DennisHeimbigner]

This appears to be a different problem than the previous one. The previous one was reference thru a NULL pointer. This is different., I tried it with valgrind, but valgrind failed. If anyone has abetter memory checker any result would be appreciated.

[WardF]

The issue is type=512 value failing an assert in v1phg.c:201. Are we certain this is a valid file? I'm proceeding with the assumption that it is.

[DennisHeimbigner]

Is there a known older version of netcdf that does not fail? If so, we might be able to look at the differences in v1hpg.c to see if there is anything suspicious.

[WardF]

I'm stepping back through now, back to v4.3.1 (under test) and have not yet found a version that works.

[WardF]

I've been testing on OSX, about to try linux since it has been reported that this worked on linux (although I was seeing failures on my linux vm locally). Still fails as far back as v4.3.1. Going back much further won't be possible on OSX, as there was an API change at some point that broke compiling on OSX for older versions.

[WardF]

(Note I am testing C library/ncdump, not the python interface).

[edhartnett]

Does h5dump work on the file?

[WardF]

No it doesn't.

[WardF]

This suggests it is a corrupt file, but if @jswhit can provide us with any provenance info, we can try to diagnose it further. Otherwise I'll re-close this issue and move on.

[DennisHeimbigner]

If it is corrupted, then it is important to know what software produced this netcdf-3 file.

[DennisHeimbigner]

BTW, the file I am testing is s1a-wv2-ocn-vv-20151204t000217-20151204t000219-008884-00cb47-044.nc and looking at its magic number it is a CDF version 1 file. So I would not expect h5dump to work.

[edhartnett]

OK sorry I assumed a netCDF-4 file....

[wkliao]

I ran ncvalidator to validate the file header and got the following error messages, which indicates the first dimension's ID of variable "owiWl" is invalid. The ID value is larger than the number of dimensions defined in the file, which is only 11 in the file.

Error @ [0x000030f8]:
    Variable "owiWl": dimid[0]=102 is larger than the number of dimensions defined in file (11)
    (Error NC_EBADDIM at line 1602 in file ../../../../parallel-netcdf-1.9.0/src/utils/ncvalidator/ncvalidator.c)
File "s1a-wv2-ocn-vv-20151204t000217-20151204t000219-008884-00cb47-044.nc" fails to conform with CDF file format specifications

[DennisHeimbigner]

Thanks. I forgot about your ncvalidator. So now the question is: how was this file constructed?

[WardF]

I am going to tentatively close this, since it's not an issue we will need to address, but closing it will also not prevent further comments.

[DennisHeimbigner]

One last note; ncdump should not crash, even if the file is illegal/corrupt.

[WardF]

It 'crashes' as a result of an assert statement, so we can rewrite that as need be.

[DennisHeimbigner]

True, we can fix the proximate cause, but ncvalidate indicates a different root cause that would be nice to catch instead.

[edhartnett]

Maybe ncdump should incorporate some or all of the features/code of ncvalidate? When a file can't be ncdumped, then some useful information can be given as to why.

If ncvalidate can figure out what is wrong, then why can't ncdump?

Just a thought for the future...

[WardF]

Perhaps at some point but with our current constraints there’s no reason to reinvent this particular wheel :).