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

[netCDF #BWM-148079]: NetCDF4 FORTRAN90 interfaces



Hi Guntram,

> since a few months we use the netcdf4-libraries with hdf5 on an
> ALTIX-XE Cluster. It worked well for a while but now possibly a bug
> has been detected inside the FORTRAN90-Interfaces, which might occur
> also on other platforms, which use the INTEL FORTRAN compiler:
> 
> A lot of routines use variables with Attribute INTENT(OUT), but they
> transfer these variables further to the C-/F77-layer external
> procedures. This is dangerous on platforms, which use the INTEL
> ifort compiler, when some higher optimization flags are swiched on.
> 
> This fact can cause a SEGMENTATION VIOLATION on Open MP parallel
> runs.
> We found this problem on one of our NetCDF-outputs and the same
> occurred on an other computer of our hardware vendor.
> 
> There are two opportunities to fix the bug:
> 1. use INTENT (INOUT) instead (which would be the natural way). My
> experience is, that one should use INTENT(OUT) only in very limited
> situations, where the data will not be changed inside al called
> procedure. 
> 2. work with a local variable inside the procedure and give its
> value back to the parameter list variable on leaving the
> procedure. This is more expensive to program, but the interfaces
> remain as you defined them. 
> 
> I choose the second way for the attached sources (part of the f90
> directory). 
> 
> May be, you will include the Bugfixes into the official distribution.

Thanks for contributing these.  I've researched some problems with
using INTENT(OUT) for arguments of derived type, but haven't seen any
such problems reported for arguments of simple primitive types or
arrays of such types.  So it seems to me this problem is a bug in the
Intel compiler rather than a bug in the F90 source code.

Nevertheless, I think it would be good to avoid such bugs, when
workarounds such as you have provided are available.  I appreciate the
work you have contributed providing fixes, and will incorporate them
into the next release of the netCDF-fortran software.  If you want to
follow the status of this bug fix, you can see it here:

  https://www.unidata.ucar.edu/jira/browse/NCFORTRAN-15

Also, I saw a few comments such as the following:

    function nf90_inq_typeids(ncid, ntypes, typeids)
      integer, intent(in) :: ncid
  ! Why are the request variables  OPTIONAL  ?
      integer, optional, intent(out) :: ntypes
      integer, dimension(:), optional, intent(out) :: typeids
      integer :: nf90_inq_typeids

The reason these were made optional was to permit requesting just one
of the requested variables returned, rather than all of them.  For
example, in the above, if you just request "ntypes", then you know how
large an array is needed for typeids, so you could allocate it and
make another call to get all the typeids, without having to pass an
array that's larger than needed.  At least I think that's why they
were made optional, I'm not the author of the F90 API.  But a similar
pattern is often used in C calls, where "NULL" arguments are provided
on a first call to an inquire function until the size of the argument
is determined and allocated, then the correclty sized argument is
provided on a subsequent call.

Thanks again for your contributed code fixes!  The hard part of this
problem will be finding a way to reproduce the problem locally, so we
can verify that the fixes are effective ...

--Russ

Russ Rew                                         UCAR Unidata Program
address@hidden                      http://www.unidata.ucar.edu



Ticket Details
===================
Ticket ID: BWM-148079
Department: Support netCDF
Priority: Normal
Status: Closed