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

[netCDF #YLE-912828]: NETCDF: Memory/resource leak in nc4hdf.c, netcdf

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 #YLE-912828]: NETCDF: Memory/resource leak in nc4hdf.c, netcdf
  • Date: Mon, 24 Nov 2008 15:35:34 -0700
> Hi!
>
> Sorry for not getting back to you regarding the memory leak issue ---
> it's been kinda hectic!

Tell me about it!

>
> I ran the test on the netcdf-4.0.1-beta1 snapshot 2008111002, and
> unfortunately there's
> still a leak. The property list referenced by xfer_plist_id is only
> deallocated if
> USE_PARALLEL is defined:
>
> nc4hdf.c:1145:
> #ifdef USE_PARALLEL
> if (h5->parallel && (H5Pclose(xfer_plistid) < 0))
> BAIL2(NC_EPARINIT);
> #endif
>
> The easiest (but perhaps not the best?) fix is to remove the parallel check
and
> return a NC_EHDFERR on error:
>
> if (xfer_plistid > 0 && H5Pclose(xfer_plistid) < 0)
> BAIL2(NC_EHDFERR);
>

The xfer_plistid is always used, so it always need to be closed. I have changed
the code to:
   if (H5Pclose(xfer_plistid) < 0)
      BAIL2(NC_EPARINIT);

> While looking through this code, I did wonder though: are we assured that
> HDF will never give us a valid hid_t that is zero? I couldn't find anything
> in the HDF docs to confirm this (only that e.g. H5Pcreate returns -1 on
> error, rather than a valid id.)

No, we cannot be sure of this. But if they do, I'm going to send them a dead
fish in the mail. ;-)

However they don't do this, and understand that it will be very silly to do
this. So I hope it will never happen. Possibly I should change the code
however, to be sure it never happens. However, looking at my code, I see that
would be difficult. Essentially I would have to introduce a new variable for
each HDF ID, to keep track of whether or not an ID has been assigned.

Perhaps I should just tell the HDF5 team that netCDF-4 counts on non-zero id
numbers...

>
> The leak-test code I attached to the last message, with the
mallinfo().uordblks,
> is probably specific to GNU libc.
>
> Best regards,
> Sam
>
>

Thanks a lot Sam!

If you can grab tomorrow's snapshot and give it a try, that would be really
helpful.

Ed

Ticket Details
===================
Ticket ID: YLE-912828
Department: Support netCDF
Priority: High
Status: Closed