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

[netCDF #INK-865870]: Quick question about NetCDF library v4.1.1 and RH 6.3

Fernando,

> Thank you again for all your comments. I was wondering, just to confirm, 
> could it be that the NetCDF 4.1.1 dependency on:
> 
> libcurl.so.3
> libc.so.6
> libgcc_s.so.1
> 
> make a difference, if the customers version of those libraries are different 
> from the one where the code works?

By "different versions" do you mean the shared object version numbers such as 
the
"3" in "libcurl.so.3" are different?  In that case, I would expect that IDL 
would 
get a run-time error that the needed shared library couldn't be found as IDL 
was 
starting up, not after it had been running successfully for a while.

Assuming the shared object versions all match, those are supposed to guarantee
backward compatibility of the API, but sometimes developers don't follow the 
rules
for changing shared object numbers when library interfaces change in ways that
aren't backward compatible.  That seems very unlikely for libraries as widely 
used 
as the ones you list.

I assume you statically link IDL to netCDF before shipping it or do a shared 
link
to the netCDF library you build in an IDL-specific directory, so there should 
be 
no dependence on any netCDF library the customer has installed, right?

So it doesn't seem to me that the version of shared libraries should be the 
cause
of the problem you're seeing, but I may be missing something ...

--Russ

> Thanks again in advance!
> Cheers,
> Fernando
> 
> -----Original Message-----
> From: Unidata netCDF Support [mailto:address@hidden]
> Sent: Monday, June 10, 2013 10:02 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,
> 
> > 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
> >
> >
> >Yes, certainly, that's why the library should be built and tested on the 
> >platform
on which it will be used
> > -----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
> 
> 
> Dear Russ,
> 
> Thank you again for all your comments. I was wondering, just to confirm, 
> could it be that the NetCDF 4.1.1 dependency on:
> 
> libcurl.so.3
> libc.so.6
> libgcc_s.so.1
> 
> make a difference, if the customers version of those libraries are different 
> from the one where the code works?
> Thanks again in advance!
> Cheers,
> Fernando
> 
> -----Original Message-----
> From: Unidata netCDF Support [mailto:address@hidden]
> Sent: Monday, June 10, 2013 10:02 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,
> 
> > 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
> 
> 
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