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.
>To: <address@hidden> >From: "Doherty, Alastair" <address@hidden> >Subject: Memory leak >Organization: Agricultural Production Systems Research Unit / DPI >Keywords: 200308120115.h7C1FDLd028258 Hi Al, > I have just made a c++ dll of the new NetCDF version 3.5.1Beta12 and > linked it to an application that I have created and there is a > memory leak that wasn't present in version 3.5.0. > > It should be easy to trace as it compounds by creating and deleting > NcFile objects. You're right, I just duplicated the problem: Checking for memory leaks... Actual leaks report (actual leaks: 1 total size: 2048 bytes) Total Num of Leaked Allocation call stack Size Blocks Block Address ====== ====== ========== ======================================= 2048 1 0xdb1a0 operator new < NcVar::init_cur < NcVar::NcVar < NcFile::NcFile < main and this did not occur in 3.5.0. > Any suggestions? I think the fix is the following one-line addition to cxx/netcdf.cpp: *** 505,510 **** --- 505,511 ---- NcVar::~NcVar( void ) { delete[] the_cur; + delete[] cur_rec; delete[] the_name; } I'll include this in the next beta release. Thanks for reporting the bug! --Russ _____________________________________________________________________ Russ Rew UCAR Unidata Program address@hidden http://my.unidata.ucar.edu