This archive contains answers to questions sent to Unidata support through mid-2025. Note that the archive is no longer being updated. We provide the archive for reference; many of the answers presented here remain technically correct, even if somewhat outdated. For the most up-to-date information on the use of NSF Unidata software and data services, please consult the Software Documentation first.
Hi Asheer, I'm not aware of any GDAL/netCDF issues. The assertion violation means that the netCDF library function that returns the size (in bytes) of a primitive type has been given a type that it doesn't recognize. The types in netCDF-3 are integers between 1 and 6. So the fact that this function is getting some other value could indicate that the netCDF file is corrupt (containing an invalid type code for a variable in the file header) or that some memory has been overwritten somewhere by a bad pointer or out-of-bounds array reference. Does "ncdump" also get the same error when run non the file you are reading? That would indicate a corrupt file. It's also possible you have encountered a bug in either netCDF or GDAL. But we are currently only fixing bugs in netCDF versions 3.6.2, 3.6.3, and 4.0, so you would have to demonstrate that the bug exists in one of those versions, and we would need to be able to reproduce it here, to diagnose the problem and fix it. It's also possible that what you are seeing is a symptom of a bug in the program you are linking with netCDF and GDAL. The fact that it works with pnetcdf doesn't guarantee that there is not a latent bug revealed by linking with netCCDF 3.6.1. Sorry that I can't be of more help, but maybe you could isolate the problem with a debugger and memory access checker, such as valgrind. If you can construct a small example that demonstrates the problem, please let us know. --Russ Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: DHP-215318 Department: Support netCDF Priority: Normal Status: Closed