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

[netCDF #QYP-982325]: NetCDF fortran enddef crashing program

Joel,

> I attempted to add the LD_LIBRARY_PATH command to include the hdf5,
> netcdf4, zlib, and szip libraries. However, ldd still indicated that the
> shared hdf libraries were being linked. The program also still crashed at
> nf90_enddef. So I used yum to remove the shared hdf and netcdf libraries
> completely and began building everything again from source.
> 
> I rebuilt and installed zlib, szip, hdf5, and netcdf again, this time
> setting the prefix to: /usr/local, the default. I was able to successfully
> build everything up through netcdf-4.3.1, however nc-config --all indicates
> that f90 was not installed.

nc-config just calls nf-config to find out whether a netCDF Fortran library
is installed, so it's expected that it won't show any netCDF Fortran flags
until after nf-config is installed by building and installing the netCDF
Fortran libraries.

> I tried then to configure and build netcdf-fortran-4.2. However, it errors
> out at the ./configure stage. I've attached the config.log from the
> netcdf-fortran build. (Side note: I've also tried using the older
> netcdf-4.2 package, this also gives the same error at the netcdf-fortran
> configure stage).

The error from config.log is:

  configure:19638: gcc -o conftest -g -O2 -I/usr/local/include -L/usr/local/lib 
conftest.c -lnetcdf  >&5
  configure:19638: $? = 0
  configure:19638: ./conftest
  ./conftest: error while loading shared libraries: libnetcdf.so.7: cannot open 
shared object file:   No such file or directory

I think this just means it can't link with the shared library in
/usr/local/lib/libnetcdf.so.7, probably because $LD_LIBRARY_PATH
doesn't include /usr/local/lib.  Rather than set this environment
variable before each invocation of configure or make, you could
instead export it to your environment.  Note also that using "sudo"
when running configure can fail because environment variables are not
all inherited by shells running as root, so you shouldn't use sudo for
any step except "make install" when building netCDF.  See the note
about that here:

  http://www.unidata.ucar.edu/netcdf/docs/netcdf-fortran-install.html

--Russ

> address@hidden> wrote:
> 
> > Hi Joel,
> >
> > > I have successfully removed the errors resulting from uninitialized
> > > variables. However I am still getting the same problem with nf90_enddef
> > >
> > > I am running on CentOS 6.5 64-bit. I've attached the build commands and
> > > relevant output for installs of zlib, szip, hdf5, and netcdf4, as well as
> > > the nf-config output, my gfortran compile and link command and the ldd
> > > output from the executable, and the lastest valgrind output.
> > >
> > > I don't still have the netcdf config.log from when I built the library,
> > > however, I can rebuild from source as I still have the tar.gz archive.
> > >
> > > Let me know how to proceed.
> >
> > Thanks for the additional information.
> >
> > The flags you're using to compile specify using the netcdf4 libraries
> > in /usr/local/netcdf4/lib and the associated include files in
> > /usr/local/netcdf4/include.
> >
> > However, the output from the ldd command shows you are actually
> > linking to the shared libraries in /usr/lib64/libnetcdff.so.5 and
> > /usr/lib64/libnetcdf.so.6, which may be inconsistent with the header
> > files installed in /usr/local/netcdf4/include.
> >
> > It seems possible that the shared libraries in /usr/lib64/ may be
> > older versions installed before you built and installed newer versions
> > in /usr/local/netcdf4, unless you have made symbolic links that make
> > /usr/local/lib a link to /usr/lib64.  Unless you explicitly set your
> > LD_LIBRARY_PATH to begin with /usr/local/netcdf4/lib, the shared
> > libraries in /usr/lib64 would take preference and would be used
> > instead.  But the include files you specified when compiling, such as
> > /usr/local/netcdf4/include/netcdf.h, would still be used to define
> > interfaces and global macros.
> >
> > I'm not sure this is what's going on to cause the crash, but the
> > inconsistency in header file versions and library versions can lead to
> > subtle problems like you are seeing.  Probably the easiest way to
> > check would be to set
> > LD_LIBRARY_PATH=/usr/local/netcdf4/lib:$LD_LIBRARY_PATH before running
> > your program with valgrind, to see if that makes any difference.
> >
> > If not, I'm not sure what's causing the crash other than what valgrind
> > says,
> > that a null pointer is being dereferenced.  That typically results from
> > passing
> > a pointer to unallocated memory or an address of "0" to a library function.
> >
> > You could try following the call to NF90_enddef in a debugger to see which
> > argument to a function that should be a valid address is actually 0.
> >
> > If you can simplify the code to a self-contained program that demonstrates
> > the crash, we could reproduce the problem here and determine the cause.
> >
> > --Russ
> >
> > > Cheers,
> > > Joel
> > >
> > >
> > > ****************************************************
> > >
> > > Joel Scott, Research Scientist
> > >
> > > Email: address@hidden
> > >
> > > Phone: (707) 545-2904, Ext. 13
> > >
> > > Fax: (707) 545-2906
> > >
> > >
> > >
> > > Remote Sensing Systems
> > >
> > > 444 10th Street, Suite 200
> > >
> > > Santa Rosa, CA 95401 USA
> > >
> > > http://www.remss.com
> > >
> > > ****************************************************
> > >
> > >
> > >
> > >
> > > address@hidden> wrote:
> > >
> > > > Hi Joel,
> > > >
> > > > > The code I'm working on for a time-sensitive program release, so I
> > > > greatly
> > > > > appreciate any and all help you can offer.
> > > > >
> > > > > Any thoughts on what I might be doing wrong with the netcdf library
> > that
> > > > is
> > > > > causing it to crash? Let me know if you need any additional
> > information
> > > > > from me or if you need me to take any debugging steps.
> > > >
> > > > The valgrind output you sent indicates possible problems with the
> > calling
> > > > program, before NF90_enddef is called, and that may be the source of
> > the
> > > > later null pointer problem valgrind is showing.  That's about as much
> > as
> > > > can be gleaned from valgrind output, without knowing any other
> > information
> > > > about your platform, the version of netCDF and HDF5 used, how the
> > library
> > > > was built, or whether you ran "make check" before installing.
> > > >
> > > > My advice is to first correct the use of uninitialized variables
> > indicated
> > > > by valgrind, looking especially for something that might result in an
> > > > unitialized pointer or unallocated memory in the calling program.  It's
> > > > likely that the later null pointer error from the NF90_enddef call will
> > > > disappear after the earlier errors are addressed.
> > > >
> > > > If you're still seeing the same problem, make sure you have run "make
> > > > check"
> > > > on the netCDF Fortran library after building from source, because it
> > tests
> > > > all the F90 functions, including NF90_enddef.  If that works OK, try to
> > > > construct a small program that demonstrates the error you are seeing
> > and
> > > > would
> > > > allow us to reproduce it here.  We would also need information on the
> > > > versions
> > > > of libraries used and the config.log generated when the netCDF Fortran
> > > > library
> > > > was built.
> > > >
> > > > --Russ
> > > >
> > > > > address@hidden> wrote:
> > > > >
> > > > > >
> > > > > > Joel Scott,
> > > > > >
> > > > > > Your Ticket has been received, and a Unidata staff member will
> > review
> > > > it
> > > > > > and reply accordingly. Listed below are details of this new Ticket.
> > > > Please
> > > > > > make sure the Ticket ID remains in the Subject: line on all
> > > > correspondence
> > > > > > related to this Ticket.
> > > > > >
> > > > > >     Ticket ID: QYP-982325
> > > > > >     Subject: NetCDF fortran enddef crashing program
> > > > > >     Department: Support netCDF
> > > > > >     Priority: Normal
> > > > > >     Status: Open
> > > > > >
> > > > > >
> > > > > >
> > > > > > The NetCDF libraries are developed at the Unidata Program Center,
> > > > > > in Boulder, Colorado, funded primarily by the National Science
> > > > Foundation.
> > > > > >
> > > > > > All support requests are handled by the development team. No
> > dedicated
> > > > > > support staff are funded at this time. For this reason we cannot
> > > > guarantee
> > > > > > response times, nor that we can resolve every support issue,
> > although
> > > > we
> > > > > > do our best to respond within 72 hours.
> > > > > >
> > > > > > It is in the nature of support requests that the same question is
> > asked
> > > > > > many
> > > > > > times. We urge you to search the support archives for material
> > > > relating to
> > > > > > your support request:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/search.jsp?support&netcdf
> > > > > >
> > > > > > If you are having trouble building netCDF, please take a look at
> > the
> > > > > > "Building NetCDF" page:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/software/netcdf/docs/building.html
> > > > > >
> > > > > > or the (unfortunately somewhat out-of-date) NetCDF Build
> > Troubleshooter
> > > > > > page:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/software/netcdf/docs/troubleshoot.html
> > > > > >
> > > > > > Windows users should see the FAQ list:
> > > > > >
> > > > > >
> > > >
> > http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#windows_netcdf4_2
> > > > > >
> > > > > > Complete documentation (including a tutorial, and sample programs
> > in C,
> > > > > > Fortran,
> > > > > > Java, and other programming languages) can be found on the netCDF
> > > > > > Documentation page:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/software/netcdf/docs/
> > > > > > http://www.unidata.ucar.edu/software/netcdf/examples/programs/
> > > > > >
> > > > > > If you resolve your issue through one of these methods, please
> > send a
> > > > > > reply to
> > > > > > this email, letting us know that you no longer need support. This
> > will
> > > > help
> > > > > > us spend more time on netCDF development.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Unidata User Support
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > Russ Rew                                         UCAR Unidata Program
> > > > address@hidden                      http://www.unidata.ucar.edu
> > > >
> > > >
> > > >
> > > > Ticket Details
> > > > ===================
> > > > Ticket ID: QYP-982325
> > > > Department: Support netCDF
> > > > Priority: Normal
> > > > Status: Closed
> > > >
> > > >
> > >
> > >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: QYP-982325
> > Department: Support netCDF
> > Priority: Normal
> > Status: Closed
> >
> >
> 
> 
> Hi Russ,
> 
> I attempted to add the LD_LIBRARY_PATH command to include the hdf5,
> netcdf4, zlib, and szip libraries. However, ldd still indicated that the
> shared hdf libraries were being linked. The program also still crashed at
> nf90_enddef. So I used yum to remove the shared hdf and netcdf libraries
> completely and began building everything again from source.
> 
> I rebuilt and installed zlib, szip, hdf5, and netcdf again, this time
> setting the prefix to: /usr/local, the default. I was able to successfully
> build everything up through netcdf-4.3.1, however nc-config --all indicates
> that f90 was not installed.
> 
> I tried then to configure and build netcdf-fortran-4.2. However, it errors
> out at the ./configure stage. I've attached the config.log from the
> netcdf-fortran build. (Side note: I've also tried using the older
> netcdf-4.2 package, this also gives the same error at the netcdf-fortran
> configure stage).
> 
> Cheers,
> Joel
> 
> 
> ****************************************************
> 
> Joel Scott, Research Scientist
> 
> Email: address@hidden
> 
> Phone: (707) 545-2904, Ext. 13
> 
> Fax: (707) 545-2906
> 
> 
> 
> Remote Sensing Systems
> 
> 444 10th Street, Suite 200
> 
> Santa Rosa, CA 95401 USA
> 
> http://www.remss.com
> 
> ****************************************************
> 
> 
> 
> 
> address@hidden> wrote:
> 
> > Hi Joel,
> >
> > > I have successfully removed the errors resulting from uninitialized
> > > variables. However I am still getting the same problem with nf90_enddef
> > >
> > > I am running on CentOS 6.5 64-bit. I've attached the build commands and
> > > relevant output for installs of zlib, szip, hdf5, and netcdf4, as well as
> > > the nf-config output, my gfortran compile and link command and the ldd
> > > output from the executable, and the lastest valgrind output.
> > >
> > > I don't still have the netcdf config.log from when I built the library,
> > > however, I can rebuild from source as I still have the tar.gz archive.
> > >
> > > Let me know how to proceed.
> >
> > Thanks for the additional information.
> >
> > The flags you're using to compile specify using the netcdf4 libraries
> > in /usr/local/netcdf4/lib and the associated include files in
> > /usr/local/netcdf4/include.
> >
> > However, the output from the ldd command shows you are actually
> > linking to the shared libraries in /usr/lib64/libnetcdff.so.5 and
> > /usr/lib64/libnetcdf.so.6, which may be inconsistent with the header
> > files installed in /usr/local/netcdf4/include.
> >
> > It seems possible that the shared libraries in /usr/lib64/ may be
> > older versions installed before you built and installed newer versions
> > in /usr/local/netcdf4, unless you have made symbolic links that make
> > /usr/local/lib a link to /usr/lib64.  Unless you explicitly set your
> > LD_LIBRARY_PATH to begin with /usr/local/netcdf4/lib, the shared
> > libraries in /usr/lib64 would take preference and would be used
> > instead.  But the include files you specified when compiling, such as
> > /usr/local/netcdf4/include/netcdf.h, would still be used to define
> > interfaces and global macros.
> >
> > I'm not sure this is what's going on to cause the crash, but the
> > inconsistency in header file versions and library versions can lead to
> > subtle problems like you are seeing.  Probably the easiest way to
> > check would be to set
> > LD_LIBRARY_PATH=/usr/local/netcdf4/lib:$LD_LIBRARY_PATH before running
> > your program with valgrind, to see if that makes any difference.
> >
> > If not, I'm not sure what's causing the crash other than what valgrind
> > says,
> > that a null pointer is being dereferenced.  That typically results from
> > passing
> > a pointer to unallocated memory or an address of "0" to a library function.
> >
> > You could try following the call to NF90_enddef in a debugger to see which
> > argument to a function that should be a valid address is actually 0.
> >
> > If you can simplify the code to a self-contained program that demonstrates
> > the crash, we could reproduce the problem here and determine the cause.
> >
> > --Russ
> >
> > > Cheers,
> > > Joel
> > >
> > >
> > > ****************************************************
> > >
> > > Joel Scott, Research Scientist
> > >
> > > Email: address@hidden
> > >
> > > Phone: (707) 545-2904, Ext. 13
> > >
> > > Fax: (707) 545-2906
> > >
> > >
> > >
> > > Remote Sensing Systems
> > >
> > > 444 10th Street, Suite 200
> > >
> > > Santa Rosa, CA 95401 USA
> > >
> > > http://www.remss.com
> > >
> > > ****************************************************
> > >
> > >
> > >
> > >
> > > address@hidden> wrote:
> > >
> > > > Hi Joel,
> > > >
> > > > > The code I'm working on for a time-sensitive program release, so I
> > > > greatly
> > > > > appreciate any and all help you can offer.
> > > > >
> > > > > Any thoughts on what I might be doing wrong with the netcdf library
> > that
> > > > is
> > > > > causing it to crash? Let me know if you need any additional
> > information
> > > > > from me or if you need me to take any debugging steps.
> > > >
> > > > The valgrind output you sent indicates possible problems with the
> > calling
> > > > program, before NF90_enddef is called, and that may be the source of
> > the
> > > > later null pointer problem valgrind is showing.  That's about as much
> > as
> > > > can be gleaned from valgrind output, without knowing any other
> > information
> > > > about your platform, the version of netCDF and HDF5 used, how the
> > library
> > > > was built, or whether you ran "make check" before installing.
> > > >
> > > > My advice is to first correct the use of uninitialized variables
> > indicated
> > > > by valgrind, looking especially for something that might result in an
> > > > unitialized pointer or unallocated memory in the calling program.  It's
> > > > likely that the later null pointer error from the NF90_enddef call will
> > > > disappear after the earlier errors are addressed.
> > > >
> > > > If you're still seeing the same problem, make sure you have run "make
> > > > check"
> > > > on the netCDF Fortran library after building from source, because it
> > tests
> > > > all the F90 functions, including NF90_enddef.  If that works OK, try to
> > > > construct a small program that demonstrates the error you are seeing
> > and
> > > > would
> > > > allow us to reproduce it here.  We would also need information on the
> > > > versions
> > > > of libraries used and the config.log generated when the netCDF Fortran
> > > > library
> > > > was built.
> > > >
> > > > --Russ
> > > >
> > > > > address@hidden> wrote:
> > > > >
> > > > > >
> > > > > > Joel Scott,
> > > > > >
> > > > > > Your Ticket has been received, and a Unidata staff member will
> > review
> > > > it
> > > > > > and reply accordingly. Listed below are details of this new Ticket.
> > > > Please
> > > > > > make sure the Ticket ID remains in the Subject: line on all
> > > > correspondence
> > > > > > related to this Ticket.
> > > > > >
> > > > > >     Ticket ID: QYP-982325
> > > > > >     Subject: NetCDF fortran enddef crashing program
> > > > > >     Department: Support netCDF
> > > > > >     Priority: Normal
> > > > > >     Status: Open
> > > > > >
> > > > > >
> > > > > >
> > > > > > The NetCDF libraries are developed at the Unidata Program Center,
> > > > > > in Boulder, Colorado, funded primarily by the National Science
> > > > Foundation.
> > > > > >
> > > > > > All support requests are handled by the development team. No
> > dedicated
> > > > > > support staff are funded at this time. For this reason we cannot
> > > > guarantee
> > > > > > response times, nor that we can resolve every support issue,
> > although
> > > > we
> > > > > > do our best to respond within 72 hours.
> > > > > >
> > > > > > It is in the nature of support requests that the same question is
> > asked
> > > > > > many
> > > > > > times. We urge you to search the support archives for material
> > > > relating to
> > > > > > your support request:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/search.jsp?support&netcdf
> > > > > >
> > > > > > If you are having trouble building netCDF, please take a look at
> > the
> > > > > > "Building NetCDF" page:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/software/netcdf/docs/building.html
> > > > > >
> > > > > > or the (unfortunately somewhat out-of-date) NetCDF Build
> > Troubleshooter
> > > > > > page:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/software/netcdf/docs/troubleshoot.html
> > > > > >
> > > > > > Windows users should see the FAQ list:
> > > > > >
> > > > > >
> > > >
> > http://www.unidata.ucar.edu/software/netcdf/docs/faq.html#windows_netcdf4_2
> > > > > >
> > > > > > Complete documentation (including a tutorial, and sample programs
> > in C,
> > > > > > Fortran,
> > > > > > Java, and other programming languages) can be found on the netCDF
> > > > > > Documentation page:
> > > > > >
> > > > > > http://www.unidata.ucar.edu/software/netcdf/docs/
> > > > > > http://www.unidata.ucar.edu/software/netcdf/examples/programs/
> > > > > >
> > > > > > If you resolve your issue through one of these methods, please
> > send a
> > > > > > reply to
> > > > > > this email, letting us know that you no longer need support. This
> > will
> > > > help
> > > > > > us spend more time on netCDF development.
> > > > > >
> > > > > > Best regards,
> > > > > >
> > > > > > Unidata User Support
> > > > > >
> > > > > >
> > > > >
> > > > >
> > > > Russ Rew                                         UCAR Unidata Program
> > > > address@hidden                      http://www.unidata.ucar.edu
> > > >
> > > >
> > > >
> > > > Ticket Details
> > > > ===================
> > > > Ticket ID: QYP-982325
> > > > Department: Support netCDF
> > > > Priority: Normal
> > > > Status: Closed
> > > >
> > > >
> > >
> > >
> > Russ Rew                                         UCAR Unidata Program
> > address@hidden                      http://www.unidata.ucar.edu
> >
> >
> >
> > Ticket Details
> > ===================
> > Ticket ID: QYP-982325
> > Department: Support netCDF
> > Priority: Normal
> > Status: Closed
> >
> >
> 
> 
Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: QYP-982325
Department: Support netCDF
Priority: Normal
Status: Closed