In preparing to paste a code snippet, I found that this *only* happens if I
include a string in the file. Here is a test function that I made, as well
as an example of how I'm calling nc_open and nc_close:
http://pastebin.com/63HbAWSy
If I comment out either method of putting the string in there, the same
thing happens, unless I comment out both methods. Variables, arrays and
groups don't cause the issue.
Here's a raw paste if you don't want to look at pastebin:
// Test function testing strings.
int rv, ncid;
if(rv = nc_create(fname, NC_NETCDF4, &ncid))
goto error; // Error opening file.
char *string = malloc(250);
sprintf(string, "This is a string.");
nc_put_att_string(ncid, NC_GLOBAL, "string1", 1, &string);
char *string2 = "This is also a string";
nc_put_att_string(ncid, NC_GLOBAL, "string2", 1, &string2);
free(string);
nc_close(ncid);
return rv;
/******* nc_open call: ********/
// Open the netCDF file.
if(rv = nc_open(fname, NC_NOWRITE, &ncid))
goto error;
/******* nc_close call: ********/
if(ncid >= 0)
nc_close(ncid);
Note that I can actually read those strings or variables and attributes
which are arrays of strings just fine. The only thing that causes problems
is the nc_close(ncid) call, which suspends execution/crashes the program if
there's a string in the file for some reason.
Now that I know this, it's not such a horrible thing, since I can just store
those as arrays of chars, but the string type is actually pretty convenient,
so if anyone has suggestions as to how I can make it deal with the fact that
strings exist, please let me know.
-Paul
On Mon, Aug 1, 2011 at 15:32, Kyle Shannon <ksshannon@xxxxxxxxx> wrote:
> Paul,
> Could you post a small example code snippet that is failing, or is it
> literally nc_open() and nc_close()?
>
>
> /**
> *
> * Kyle Shannon
> * ksshannon@xxxxxxxxx
> *
> */
>
>
>
>
> On Mon, Aug 1, 2011 at 16:25, Paul Ganssle <p.g.anssle@xxxxxxxxx> wrote:
>
>> As a follow-up, I've spent considerable time dealing with this issue, and
>> it seems like the problem is that nc_open() *always* locks files. I've
>> found that if I use a debug executable or a release executable and run from
>> within the LabWindows/CVI IDE, execution suspends on the nc_close() calls,
>> but if I just continue execution a few times (it suspends 3 times, I
>> believe), the function will finish executing and the file won't be locked
>> anymore. Of course, if I run the executable from outside the IDE, it crashes
>> completely. It seems like it's either a problem with nc_open or nc_close.
>> Any help would be greatly appreciated.
>>
>> -Paul
>>
>>
>> On Mon, Aug 1, 2011 at 13:50, Paul Ganssle <p.g.anssle@xxxxxxxxx> wrote:
>>
>>> Hi all,
>>> I'm looking for some help with a netcdf-powered application, and it
>>> seemed like this was the right mailing list to ask. Apologies in advance if
>>> this is an inappropriate place to ask this question.
>>>
>>>
>>> The problem I'm having is with the file open/close model in netcdf 4
>>> (4.1.3). I'm using LabWindows/CVI 9.0 to build a program and using netCDF
>>> for all my data reading/writing needs. The problem is that in a few cases it
>>> seems like I'm leaving these files open causing them to lock, but given that
>>> you can't call nc_close() on a file that's been opened for reading only
>>> (totally crashes my application if I do that - no error is returned), I
>>> don't really understand how to unlock the files. Right now I'm dealing with
>>> files where you build some set of variables and metadata in a UI editor,
>>> then save them to file. If you load them from file first, when you try to
>>> save them, it returns the error "Could not add HDF5 metadata", but that only
>>> happens when the file is locked due to being in use, because there's a call
>>> to DeleteFilename(filename) that occurs before the nc_create call.
>>>
>>> Given that it was only ever opened with nc_open(filename, NC_NOWRITE,
>>> &ncid), I don't understand why it could possibly be locked. So my overall
>>> question is, "how do I fix this?", but more specifically, I guess I'm
>>> looking for a way to either force close netcdf files that were opened by
>>> some unknown function or force close all open netcdf files.
>>>
>>> Best,
>>> Paul Ganssle
>>>
>>
>>
>> _______________________________________________
>> netcdfgroup mailing list
>> netcdfgroup@xxxxxxxxxxxxxxxx
>> For list information or to unsubscribe, visit:
>> http://www.unidata.ucar.edu/mailing_lists/
>>
>
>
