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

Re: 20010103: netCDF and Labview

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: Re: 20010103: netCDF and Labview
  • Date: Wed, 3 Jan 2001 16:43:36 -0700 (MST)
>To: address@hidden,
>To: address@hidden
>From: "Matt D'Ortenzio" <address@hidden>
>Subject: netCDF and Labview
>Organization: NASA Ames Research Center
>Keywords: 200101030355.f033t1o23836

Hi Matt,

You asked:
<Question>

        I recently found the email you sent Unidata regarding netCDF data
access from within LabView (message below).  I'm presently having a
problem similar to the one you described, where LabView crashes when
exiting the current VI or the LabView environment.  Did you ever figure
out what was causing this problem? 
        The past couple of months I've been working on a general LabView
interface to netCDF for Windows using the pre-built netCDF DLL and
LabView's "Call Library Functions". For me, the problem only seems to
occur when using netCDF functions that require a pointer of type
"size_t" as an argument. Did you see this same pattern?  

</Question>

<Answer>
As far as I know, we never determined exactly what was causing the problem.
I'm CC:ing John Caron, who may know more.

If you know how to build DLLs, you might try rebuilding against your
specific environment.  The hint about using type size_t* arguments sounds
important; maybe the DLL we built used a different type for size_t than what
you are linking it with.  I assume the DLL we built was in an environment in
which size_t is a 32-bit unsigned int.

Something else we have seen occasionally in use of netCDF on Win32 platforms
with not much extra memory available is situations where the memory 
allocation function malloc() fails and netCDF doesn't recover well and may
not free all the memory previously allocated before the malloc() failure.
The argument to malloc is a size_t* ...
</Answer>

--Russ