-
Notifications
You must be signed in to change notification settings - Fork 262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ncdump crashes after a 2D NC_STRING variable is written to this file #2002
Comments
So it turns out that for netcdf-4 files, it is not the case that the maximum dimension id is not equal to the (total number of dimensions -1); that is there are holes in the assignment of dimension ids. This error occurs because ncdump was making the false assumption of equality of those two values. |
re: issue Unidata#2002 It turns out that ncdump has an error where it assumes that the set of all dimension ids has no holes. That is that (maxid+1) = ndims. This is incorrect for a variety of reasons for netcdf-4. So instead of counting total number of dimensions in a dataset, it is necessary to look for the maximum dimension id and use that when allocating a table of all dimensions.
Fixed by #2004 |
This is great! Thank you, Dennis! I no longer see the crash after applying your changes to dumplib.c |
Hi all!
So far I am seeing this issue with only one specific file (nctest_netcdf4_orig.nc in attached.zip , mostly full of dummy data). Before, ncdump works fine on the file, but after I write a 2D NC_STRING variable to it, ncdump seems to crash with "Segmentation fault: 11".
I isolated the reproduction steps for writing the NC_STRING variable (and thus creating the problematic file) to the string_ncdump_crush.cpp in attached.zip
Here are the output and details of what I am observing:
The above is with netcdf-c 4.7.4 on a macOS 11.2.3 machine. @DennisHeimbigner has mentioned an ncdump crash on another issue I reported (#1985), and I tried building ncdump with the new dumplib.c he attached, and I still saw the crash.
I have also tried running ncdump on the same problematic file on a linux machine. There the issue presents a bit differently:
Do you think the issue is with ncdump, or with how the NC_STRING variable is written, or something is wonky with this one file itself?
I am most of all concerned about - and would like to rule out - any latent issues (that are somehow only make apparent by ncdump) in the writing of NC_STRING data...
Would appreciate your thoughts!
The text was updated successfully, but these errors were encountered: