netcdf-c/libdap2/dapdump.h

70 lines
1.9 KiB
C
Raw Normal View History

2011-04-18 02:56:10 +08:00
/*********************************************************************
2018-12-07 05:21:03 +08:00
* Copyright 2018, UCAR/Unidata
2011-04-18 02:56:10 +08:00
* See netcdf/COPYRIGHT file for copying and redistribution conditions.
*********************************************************************/
#ifndef DUMP_H
#define DUMP_H
typedef struct Dimschema {
int dimid;
/* int cloneid;*/
size_t size;
char name[NC_MAX_NAME+1];
} Dim;
typedef struct Varschema {
int varid;
/* int cloneid;*/
char name[NC_MAX_NAME+1];
nc_type nctype;
int ndims;
int dimids[NC_MAX_VAR_DIMS];
size_t nelems; /*# elements*/
size_t alloc; /* malloc size*/
int natts;
NCattribute* atts;
} Var;
typedef struct NChdr {
int ncid;
int format;
int ndims;
int nvars;
int ngatts;
int unlimid; /* id of the (1) unlimited dimension*/
Dim* dims;
Var* vars;
NCattribute* gatts;
NCbytes* content;
} NChdr;
extern int dumpmetadata(int ncid, NChdr**);
extern void dumpdata1(nc_type nctype, size_t index, char* data);
extern char* dumppath(struct CDFnode* node);
extern char* dumptree(CDFnode* root);
extern char* dumpvisible(CDFnode* root);
extern char* dumpnode(CDFnode* node);
Fix more memory leaks in netcdf-c library This is a follow up to PR https://github.com/Unidata/netcdf-c/pull/1173 Sorry that it is so big, but leak suppression can be complex. This PR fixes all remaining memory leaks -- as determined by -fsanitize=address, and with the exceptions noted below. Unfortunately. there remains a significant leak that I cannot solve. It involves vlens, and it is unclear if the leak is occurring in the netcdf-c library or the HDF5 library. I have added a check_PROGRAM to the ncdump directory to show the problem. The program is called tst_vlen_demo.c To exercise it, build the netcdf library with -fsanitize=address enabled. Then go into ncdump and do a "make clean check". This should build tst_vlen_demo without actually executing it. Then do the command "./tst_vlen_demo" to see the output of the memory checker. Note the the lost malloc is deep in the HDF5 library (in H5Tvlen.c). I am temporarily working around this error in the following way. 1. I modified several test scripts to not execute known vlen tests that fail as described above. 2. Added an environment variable called NC_VLEN_NOTEST. If set, then those specific tests are suppressed. This should mean that the --disable-utilities option to ./configure should not need to be set to get a memory leak clean build. This should allow for detection of any new leaks. Note: I used an environment variable rather than a ./configure option to control the vlen tests. This is because it is temporary (I hope) and because it is a bit tricky for shell scripts to access ./configure options. Finally, as before, this only been tested with netcdf-4 and hdf5 support.
2018-11-16 01:00:38 +08:00
extern char* dumpalign(struct NCD2alignment*);
2011-04-18 02:56:10 +08:00
extern char* dumpcachenode(NCcachenode* node);
extern char* dumpcache(NCcache* cache);
extern int dumpmetadata(int ncid, NChdr** hdrp);
extern void dumpdata1(nc_type nctype, size_t index, char* data);
extern char* dumpprojections(NClist* projections);
extern char* dumpprojection(DCEprojection* proj);
extern char* dumpselections(NClist* selections);
extern char* dumpselection(DCEselection* sel);
extern char* dumpconstraint(DCEconstraint* con);
extern char* dumpsegments(NClist* segments);
extern char* dumpslice(DCEslice* slice);
extern char* dumpslices(DCEslice* slice, unsigned int rank);
extern void dumpraw(void*);
extern void dumplistraw(NClist*);
2011-04-18 02:56:10 +08:00
#endif /*DUMP_H*/