From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 89426 invoked by alias); 26 May 2019 14:15:38 -0000 Mailing-List: contact fortran-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: fortran-owner@gcc.gnu.org Received: (qmail 89411 invoked by uid 89); 26 May 2019 14:15:38 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-8.4 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_2,KAM_SHORT autolearn=ham version=3.3.1 spammy=2008, H*f:sk:00a4b0c, H*i:sk:00a4b0c, sigsegv X-HELO: moene.org Received: from moene.org (HELO moene.org) (80.101.130.238) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 26 May 2019 14:15:36 +0000 Received: from localhost ([127.0.0.1] helo=moene.org) by moene.org with esmtp (Exim 4.92) (envelope-from ) id 1hUtvj-0003ih-0i; Sun, 26 May 2019 16:15:19 +0200 Subject: Re: Bug in closed-source, proprietary software that I do not have access to From: Toon Moene To: Thomas Koenig Cc: "fortran@gcc.gnu.org" , gcc mailing list References: <813c3cf9-265c-b689-5130-ef7f15e11632@netcologne.de> <20190525170135.GA54621@troutmask.apl.washington.edu> <7a60f1f7-a682-ff97-ad15-0eca763646fc@moene.org> <1332af12-1488-9ac1-c0d2-c655277f67df@netcologne.de> <00a4b0c7-af27-63c5-0539-ede86c2d6b6a@moene.org> Message-ID: <932c6ada-93d0-a419-100a-3a76ecf1d16b@moene.org> Date: Sun, 26 May 2019 14:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <00a4b0c7-af27-63c5-0539-ede86c2d6b6a@moene.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-05/txt/msg00173.txt.bz2 On 5/25/19 7:43 PM, Toon Moene wrote: > On 5/25/19 7:31 PM, Thomas Koenig wrote: >> Hi Toon, >> >>> On 5/25/19 7:01 PM, Steve Kargl wrote: >>> >>>> For WRF, I suppose you or Martin could be a good citizen and >>>> contact the project to report a bug. >>> >>> I have thought about this. As a person with experience building and >>> running weather forecasting codes, I would be first in line to try >>> this. But the SPEC code could be modified and not resemble a fresh >>> WRF setup ... >> >> The current version of netcdf has, in module_netcdf_nf_interfaces.F90, >> >> !--------------------------------- nf_put_vara_double >> ---------------------- >> Interface >>   Function nf_put_vara_double(ncid, varid, start, counts, dvals) & >>                                  RESULT(status) >> >>   USE netcdf_nf_data, ONLY: RK8 >> >>   Integer,   Intent(IN) :: ncid, varid >>   Integer,   Intent(IN) :: start(*), counts(*) >>   Real(RK8), Intent(IN) :: dvals(*) >>   Integer               :: status >> >>   End Function nf_put_vara_double >> End Interface >> >> which looks good (well, it's not BIND(C)). In another file, >> it has it as a simple INTEGER declaration with EXTERNAL. >> I don't know which of the two is actually used. >> > OK. > > One thing I can do (tomorrow) is to download WRF, build it and see how > it uses netcdf. > > The trunk compiler I have at hand is revision 271618, so it includes > your update that's the subject of PR90539. > What I started with is some modern versions of the libraries needed: hdf5-1.10.5, netcdf-c-4.6.3, and netcdf-fortran-4.4.5, built with trunk revision 271618. netcdf-c-4.6.3 (the C netcdf library) passed all its own tests. netcdf-fortran-4.4.5 is the library of Fortran "glue" routines to the C library. These are the relevant C interoperability comments during configure, indicating that it will use BIND(C) declarations for interfacing with the C library: checking for Fortran flag to compile .f90 files... none checking fortran 90 modules inclusion flag... -I checking if Fortran compiler supports Fortran 2003 ISO_C_BINDING... yes checking if Fortran compiler supports Fortran 2008 ISO_FORTRAN_ENV additions... yes checking if Fortran compiler supports TS29113 standard extension... yes checking whether F03 native code is desired... yes However, there *is* a Segmentation Fault when running one of its tests: cat nf_test/tst_f90.log Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x7f915ef0d8b0 in ??? #1 0x7f915ef0cae3 in ??? #2 0x7f915eb6483f in ??? #3 0x7f915fa151cd in __netcdf_MOD_nf90_put_var_1d_fourbytereal at /home/toon/netcdf/netcdf-fortran-4.4.5/fortran/netcdf_expanded.f90:940 #4 0x402cfc in netcdftest at /home/toon/netcdf/netcdf-fortran-4.4.5/nf_test/tst_f90.f90:95 #5 0x40226c in main at /home/toon/netcdf/netcdf-fortran-4.4.5/nf_test/tst_f90.f90:7 FAIL tst_f90 (exit status: 139) This is the error location in /home/toon/netcdf/netcdf-fortran-4.4.5/fortran/netcdf_expanded.f90: 939 nf90_put_var_1D_FourByteReal = & 940 nf_put_vara_real(ncid, varid, localStart, localCount, values) 941 end if 942 end function nf90_put_var_1D_FourByteReal So at least *a* Segmentation Fault is reproducible with these freely available libraries .... Kind regards, -- Toon Moene - e-mail: toon@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/ Progress of GNU Fortran: http://gcc.gnu.org/wiki/GFortran#news