Fernando, > Thank you very much for your emails. > > IDL has wrappers that use the API of the NetCDF 4.1.1 libraries, and when the > customer uses the IDL routine that creates NetCDF files gets the following > errors from IDL: > > 'NCDF_CLOSE: Operation Failed.' > > and > > 'NCDF_CONTROL: Attempt to take the file out of define mode (ENDEF) failed. > (NC_ERROR=-31)' > > though, only the (NC_ERROR=-31) is directly from your library, correct? Right, the -31 is NC_SYSERR, as defined in netcdf.h, which means the netCDF library got a system error when calling a function such as fclose(). The global integer errno should be set to a system error code that indicated something more specific than "operation failed", and if IDL had called nc_strerror, to convert the error code into a string, it should have provided the more specific message. Typically, calling close with a bad file descriptor or having an uncommitted write encounter an I/O error are the kinds of things that can cause close to fail. > The key issue here is that it only happens in their version of Red Hat 6.3, > and does not happen in other flavors of Linux. And not just any version of RH > 6.3, but that with the kernel version that I sent you in my previous email. I > have tested his code with a "vanilla" version of RedHat 6.3 and I was not > able to reproduce the problem!. That's strange, we haven't seen anything like that. > That's why I was wondering if there was a know issue with that particular > kernel in RH. Nope. > I will pass on to my customer your comments and see if he can understand what > was updated in his system or try to debug the issue from inside IDL. > > Thanks again for your help. If you don't mind, if the customer has another > questoin related with NetCDF libraries, may I ask you again? Sure, feel free to send any questions to address@hidden --Russ > Cheers! > Fernando > > > > -----Original Message----- > From: Unidata netCDF Support [mailto:address@hidden > Sent: Sunday, June 09, 2013 2:59 PM > To: Fernando Santoro > Cc: address@hidden; Berangere Casson > Subject: [netCDF #INK-865870]: Quick question about NetCDF library v4.1.1 and > RH 6.3 > > Fernando, > > Oops, please ignore that last answer. I was thinking you were relying on a > customer netCDF 4.1.1 installation, but I'm sure you were really referring to > a static installation of netCDF 4.1.1 in one of your products. > > > > I'm a tech support engineer at Exelis VIS, the company that develops > > > ENVI and IDL here in Boulder. > > > > > > I have a quick question. Is there any known incompatibility between > > > the NetCDF library version 4.1.1 and Red Hat 6.3 (Linux eld467 > > > 2.6.32-279.19.1.el6.x86_64). > > I've never heard of such an incompatibility, but we actually don't test on > Red Hat Linux here, but just various versions of Fedora between 14 and 18, > and haven't encountered any differences that were due to the version of > Fedora. We also test the same source on various other versions of Linux and > Unix, including Solaris and Mac OS-X. > > > > I'm asking this because I have a customer that has created an IDL > > > code to create NetCDF files in a loop, and after some iterations the > > > code crashes when creating the NetCDF file. I have tested the same > > > code with the same NetCDF library version on a Red Hat 6.0 machine, > > > and everything works fine. > > We have fixed some memory leaks in more recent versions of netCDF since > 4.1.1, but nothing very serious. Does the code crash with insufficient > memory? Did a core dump reveal it was in the netCDF library, and if so, in > what function? > > --Russ > > Russ Rew UCAR Unidata Program > address@hidden http://www.unidata.ucar.edu > > > > Ticket Details > =================== > Ticket ID: INK-865870 > Department: Support netCDF > Priority: Normal > Status: Closed > > Russ Rew UCAR Unidata Program address@hidden http://www.unidata.ucar.edu Ticket Details =================== Ticket ID: INK-865870 Department: Support netCDF Priority: Normal Status: Closed
NOTE: All email exchanges with Unidata User Support are recorded in the Unidata inquiry tracking system and then made publicly available through the web. If you do not want to have your interactions made available in this way, you must let us know in each email you send to us.