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

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



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