Created attachment 1003723 [details] Valgrind run with "--leak-check full" Description of problem: gdalinfo can't read temperature data from grib2 -file. Result is immediate segmentation fault. Version-Release number of selected component (if applicable): gdal-1.11.2-1 How reproducible: gdalinfo temperature.grib2 Steps to Reproduce: 1. Install Fedora 21 x86_64 2. yum update 3. gdalinfo temperature.grib2 Actual results: Segmentation fault Expected results: Information about contents of grib2 file containing temperature forecast. Additional info: Using another program for grib2 handling, wgrib2, information about file contents is printed as expected, no segmentation fault. I previously filed a bug in osgeo (gdal maintainer), but they were not able to produce the problem in GDAL, but suggested to file a bug in Fedora. osgeo ticket about this exact problem: https://trac.osgeo.org/gdal/ticket/5876
Created attachment 1003724 [details] Forecast data of temperatures causing gdalinfo segfault. Use this input file to check bug existence.
I confirm that removing the gdal-g2clib.patch and rebuilding the rpm fixes the issue.
Okay, I think I've finally figured out at least part of the issue. g2clib's grib2.h uses: #ifdef __64BIT__ typedef int g2int; typedef unsigned int g2intu; #define PRIg2int "d" #else typedef long g2int; typedef unsigned long g2intu; #define PRIg2int "ld" #endif The problem is that nothing else defines __64BIT__ automatically. So it means that all g2clib users must define __64BIT__ on 64 bit platforms as well. I think we need a better patch for g2clib to make this check work automatically. This could explain some other issues seen with g2clib users as well.
Hopefully there will be some new gdal builds to test here soon: https://copr.fedoraproject.org/coprs/orion/g2clib/
I've built F22 and F23 updates for gdal. I'm going to let the normal gdal maintainers build/submit and F21/F20 update as there are some differences in the branches.
We have same problen in CentOS 7.1.1503 Using g2clib gdal builds, problem is corrected.
The g2clib update is in EPEL7 now, so it should just be a matter of rebuilding gdal, which I'll leave to the gdal maintainers.
*** Bug 1203927 has been marked as a duplicate of this bug. ***
*** Bug 1204091 has been marked as a duplicate of this bug. ***
*** Bug 1204398 has been marked as a duplicate of this bug. ***
*** Bug 1210979 has been marked as a duplicate of this bug. ***
*** Bug 1210980 has been marked as a duplicate of this bug. ***
*** Bug 1211087 has been marked as a duplicate of this bug. ***
*** Bug 1212529 has been marked as a duplicate of this bug. ***
*** Bug 1212692 has been marked as a duplicate of this bug. ***
*** Bug 1212908 has been marked as a duplicate of this bug. ***
*** Bug 1212997 has been marked as a duplicate of this bug. ***
*** Bug 1213551 has been marked as a duplicate of this bug. ***
*** Bug 1214488 has been marked as a duplicate of this bug. ***
*** Bug 1214974 has been marked as a duplicate of this bug. ***
*** Bug 1217040 has been marked as a duplicate of this bug. ***
*** Bug 1217213 has been marked as a duplicate of this bug. ***
*** Bug 1217230 has been marked as a duplicate of this bug. ***
*** Bug 1222400 has been marked as a duplicate of this bug. ***
gdal-1.11.2-1.el7 has been submitted as an update for Fedora EPEL 7. https://admin.fedoraproject.org/updates/gdal-1.11.2-1.el7
Package gdal-1.11.2-1.el7: * should fix your issue, * was pushed to the Fedora EPEL 7 testing repository, * should be available at your local mirror within two days. Update it with: # su -c 'yum update --enablerepo=epel-testing gdal-1.11.2-1.el7' as soon as you are able to. Please go to the following url: https://admin.fedoraproject.org/updates/FEDORA-EPEL-2015-7068/gdal-1.11.2-1.el7 then log in and leave karma (feedback).
gdal-1.11.2-1.el7 has been pushed to the Fedora EPEL 7 stable repository. If problems still persist, please make note of it in this bug report.