Comment 5 for bug 1637228

Ubuntu xenial has GDAL 1.11.3 and the ubuntugis-unstable PPA has GDAL 2.1.0, and quite a lot of changes to the NetCDF driver have been made between those release.

Valgrid reports the following for the gdalinfo command with the gdal & netcdf debug packages installed:

==9254== Invalid read of size 1
==9254== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9254== by 0x53F2EC2: NCDFSafeStrcat(char**, char*, unsigned long*) (netcdfdataset.cpp:6268)
==9254== by 0x53F3124: NCDFGetAttr1(int, int, char const*, double*, char**, int) (netcdfdataset.cpp:6426)
==9254== by 0x53F3DC3: NCDFGetAttr (netcdfdataset.cpp:6449)
==9254== by 0x53F3DC3: netCDFDataset::ReadAttributes(int, int) (netcdfdataset.cpp:4085)
==9254== by 0x53FBCF1: netCDFDataset::Open(GDALOpenInfo*) (netcdfdataset.cpp:4809)
==9254== by 0x554A10C: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2314)
==9254== by 0x554A365: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2263)
==9254== by 0x402BB4: ??? (in /usr/bin/gdalinfo)
==9254== by 0x642B82F: (below main) (libc-start.c:291)
==9254== Address 0x0 is not stack'd, malloc'd or (recently) free'd
==9254==
==9254==
==9254== Process terminating with default action of signal 11 (SIGSEGV)
==9254== Access not within mapped region at address 0x0
==9254== at 0x4C30F62: strlen (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==9254== by 0x53F2EC2: NCDFSafeStrcat(char**, char*, unsigned long*) (netcdfdataset.cpp:6268)
==9254== by 0x53F3124: NCDFGetAttr1(int, int, char const*, double*, char**, int) (netcdfdataset.cpp:6426)
==9254== by 0x53F3DC3: NCDFGetAttr (netcdfdataset.cpp:6449)
==9254== by 0x53F3DC3: netCDFDataset::ReadAttributes(int, int) (netcdfdataset.cpp:4085)
==9254== by 0x53FBCF1: netCDFDataset::Open(GDALOpenInfo*) (netcdfdataset.cpp:4809)
==9254== by 0x554A10C: GDALOpenInternal(GDALOpenInfo&, char const* const*) (gdaldataset.cpp:2314)
==9254== by 0x554A365: GDALOpenInternal(char const*, GDALAccess, char const* const*) (gdaldataset.cpp:2263)
==9254== by 0x402BB4: ??? (in /usr/bin/gdalinfo)
==9254== by 0x642B82F: (below main) (libc-start.c:291)
==9254== If you believe this happened as a result of a stack
==9254== overflow in your program's main thread (unlikely but
==9254== possible), you can try to increase the size of the
==9254== main thread stack using the --main-stacksize= flag.
==9254== The main thread stack size used in this run was 8388608.
==9254==
==9254== HEAP SUMMARY:
==9254== in use at exit: 1,789,968 bytes in 6,243 blocks
==9254== total heap usage: 11,605 allocs, 5,362 frees, 2,340,923 bytes allocated
==9254==
==9254== LEAK SUMMARY:
==9254== definitely lost: 0 bytes in 0 blocks
==9254== indirectly lost: 0 bytes in 0 blocks
==9254== possibly lost: 0 bytes in 0 blocks
==9254== still reachable: 1,789,968 bytes in 6,243 blocks
==9254== of which reachable via heuristic:
==9254== length64 : 56,956 bytes in 61 blocks
==9254== newarray : 288 bytes in 16 blocks
==9254== suppressed: 0 bytes in 0 blocks
==9254== Rerun with --leak-check=full to see details of leaked memory
==9254==
==9254== For counts of detected and suppressed errors, rerun with: -v
==9254== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0)
Segmentation fault

The GDAL 1.11.3 code in question (frmts/netcdf/netcdfdataset.cpp):

6265 CPLErr NCDFSafeStrcat(char** ppszDest, char* pszSrc, size_t* nDestSize)
6266 {
6267 /* Reallocate the data string until the content fits */
6268 while(*nDestSize < (strlen(*ppszDest) + strlen(pszSrc) + 1)) {
6269 (*nDestSize) *= 2;
6270 *ppszDest = (char*) CPLRealloc((void*) *ppszDest, *nDestSize);
6271 #ifdef NCDF_DEBUG
6272 CPLDebug( "GDAL_netCDF", "NCDFSafeStrcat() resized str from %ld to %ld", (*nDestSize)/2, *nDestSize );
6273 #endif
6274 }
6275 strcat(*ppszDest, pszSrc);
6276
6277 return CE_None;
6278 }

ncdump does handle the file successfully and reports that the ctth_quality variable has the ushort type, GDAL 2.1.0 added full read/write support for new NetCDF4 types like this.

So I think we can conclude that GDAL 1.11.3 in xenial doesn't support NetCDF4 sufficiently. Since backporting a fix for this issue doesn't seem feasible, and the GIS packages in Ubuntu are not actively maintained (because the manpower is in Debian), a fix for the package in xenial can pretty much be ruled out. Using the newer packages from UbuntuGIS is a good alternative until the next LTS.