[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[netCDF #XIX-708449]: Memory leaks using netcdf4

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.

  • Subject: [netCDF #XIX-708449]: Memory leaks using netcdf4
  • Date: Fri, 03 Oct 2014 12:57:11 -0600
> Full Name: Manh Ha NGUYEN
> Organization: Laboratoire des Sciences du Climate et de l'Environnement, 
> France
> Package Version: NetCdf 4.3.2 with hdf5 1.8.11 parallel
> Operating System: Fedora 20
> Hardware: Intel Xeon
> Description of problem: Hi,
> I am working with NetCdf 4.3.2 with hdf5 1.8.11.
> My process creates netcdf file, receives data in each time step and writes 
> them to the file.
> This program is made to run for several days.
> This program has worked well with a small number of time steps.
> However, there is one problem when I try to make the program run longer: The 
> memory increases and the program explodes.
> If I don't use nc_put_vara_xxx functions (just comment them in my code), 
> there is no "memory leak" any more.
> On using valgrind, with nc_put_vara functions activated and unactivated, I 
> see no memory leak.
> I have impression that nc_put_var_xxx functions use a temporary memory which 
> increases each or after several writes and is only released on closing netcdf 
> file.
> 
> Could you give me a suggestion how to get around this problem?
> 
> P.S: In fact, there is a thread about this phenomenon of netcdf [netCDF 
> #XIX-708449]

Yes, but that thread showed that the memory leak fix in version 4.1.2-rc1 
fixed the problem for that user, so that there were no longer any memory
leaks after the memory use reached 23 MB (or 21 MB if he nc_sync() was
called).  Since you are using version 4.3.2, that fix is in your library,
so while your problem may have similar symptoms, I think it is a different
problem.

Can you provide us with a complete example that demonstrates the memory leak?
That would really help to debug the problem.  If we can't duplicate it here,
debugging such problems from just a description is very difficult.

--Russ

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: XIX-708449
Department: Support netCDF
Priority: Normal
Status: Closed