Function NC_check_nulls crashes with segfault for more than 1 var

[theZiz]

ParaView crashed for me while working with netcdf files. I was able to track this down to an error in libnetcdf in this line:

netcdf-c/libdispatch/dvar.c

Line 705 in 98e6384

*stride[i] = 1;

stride is a pointer to a list of integers and not a list of pointers to integers. So we need to dereference the pointer first with braces:

(*stride)[i] = 1; 

After changing this locally for me, everything works fine with ParaView. 😃

I will open a PR for this.

[edhartnett]

Yes, this is already covered as issue #1265. Sorry for any inconvenience, this was my fault. ;-(

A fix is pending in PR #1266.

[theZiz]

Ah, glad that someone else noticed it, too. I was surprised that I seemed to be the first one, but I wasn't able to find your issue or pull request. Thanks for your work. 😉

[edhartnett]

These changes have been merged into master. Check out the latest master and make sure it works for you, and if so, please close this issue.

[PaulWessel]

Could you possibly use your influence to get various package managers to move to 4.6.3? Apparently, macports just moved to 4.6.2 on March 9 and now lots of GMT users (who depend on the netcdf library) get various crashes. Is there any workaround other than getting 4.6.3 or reverting to 4.6.1?

[DennisHeimbigner]

By crash, do you mean the subject of this issue?

[DennisHeimbigner]

Looking at the code, It appears that if you specify a stride array (as all ones),
it should bypass the error.

[DennisHeimbigner]

Looking at the code, It appears that if you specify a stride array (as all ones),
it should bypass the error.

[PaulWessel]

Yes, here is a typical backtrace:

ERROR: Caught signal number 11 (Segmentation fault) at
0 libnetcdf.13.dylib 0x000000010d0d22b2 NC_check_nulls + 158
1 ??? 0x00000002e3071590 0x0 + 12398826896
Stack backtrace:
0 libgmt.6.dylib 0x000000010cb9d824 sig_handler + 580
1 libsystem_platform.dylib 0x00007fff775b3b3d _sigtramp + 29
2 ??? 0x000000011bed1ccc 0x0 + 4763491532
3 libnetcdf.13.dylib 0x000000010d0d39e7 NC_get_varm + 117
4 libnetcdf.13.dylib 0x000000010d0d3ac4 nc_get_varm_float + 14
5 libgmt.6.dylib 0x000000010cc35b81 gmtnc_io_nc_grid + 641
6 libgmt.6.dylib 0x000000010cc35495 gmt_nc_read_grd + 1893
7 libgmt.6.dylib 0x000000010cc00c97 gmtlib_read_grd + 199
8 libgmt.6.dylib 0x000000010cbc678b api_import_data + 9019
9 libgmt.6.dylib 0x000000010cbb2fab api_get_data + 315
10 libgmt.6.dylib 0x000000010cbaac47 GMT_Read_Data + 4007
11 libgmt.6.dylib 0x000000010cefecc8 GMT_grdvector + 5880
12 libgmt.6.dylib 0x000000010cbbb564 GMT_Call_Module + 628
13 gmt 0x000000010cb8fede main + 1070
14 libdyld.dylib 0x00007fff773c8ed9 start + 1

presumably NC_get_varm ens up calling NC_check_nulls which sets of the bug as described above. If I downgrade to 4.6.1 the problem goes away.

[PaulWessel]

I can see we are calling nc_put_varm_float with a stride of NULL. So are you saying we should pass a size_t stride[5] = {1, 1, 1, 1, 1} instead?

[DennisHeimbigner]

pass a size_t stride[5] = {1, 1, 1, 1, 1} instead?

Yes, you might try that since that error apparently is only
invoked when stride is null.

[DennisHeimbigner]

Also, I am curious. Do you actually need to use put_varm instead of put_vars?

[PaulWessel]

Not 100% sure (the guy who did that part is in Germany) but think so. At any rate, passing the ones avoids the crash so I will go with that. Thanks!

[DennisHeimbigner]

BTW, you only need a single vector of ones of length NC_MAX_VAR_DIMS
(see netcdf.h) and you can use it everywhere for the stride vector.

[PaulWessel]

Thanks, this problem is happening when reading 2-d slices from grids and they are of max 5 dimensions (same as size and count arrays) so I can get away with only 5.

[Dave-Allured]

Macports updated to netcdf 4.6.3 on March 23 from ticket 58212. This resolves the original issue with NC_check_nulls. I think you can close this issue.

It would be helpful for users needing Macports fixes and updates to start their own ticket, or to add a comment to an existing ticket. The Macports organization tends to be slow to respond, and a show of interest helps.