[gdal-dev] gdalinfo error and subsequent segfault with proj-5.0.x

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[gdal-dev] gdalinfo error and subsequent segfault with proj-5.0.x

Markus Metz-3
I observed a segfault in gdalinfo (2.2.3, 2.2.4, 2.3.0dev-71e2ada881) when compiled against proj-5.0.0/proj-5.0.1

The dataset is a GeoTIFF with EPSG:25832, and I get

Corner Coordinates:
ERROR 1: illegal axis orientation combination
Upper Left  (  375000.000, 5631000.000)
ERROR 1: illegal axis orientation combination
Lower Left  (  375000.000, 5628000.000)
ERROR 1: illegal axis orientation combination
Upper Right (  379000.000, 5631000.000)
ERROR 1: illegal axis orientation combination
Lower Right (  379000.000, 5628000.000)
ERROR 1: illegal axis orientation combination
Center      (  377000.000, 5629500.000)
Segmentation fault (core dumped)

The error message is printed by GDAL and comes from PROJ. I think the segfault is a symptom of the error, therefore I would like to find out the reason of the error.

Using gdal-2.2+ with proj-4.9.3, all is fine.

Testing proj-5.0.1 with

cs2cs +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs +to +proj=latlong +ellps=GRS80

proj -I +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

cct +proj=pipeline +step +inv +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

all is fine, too.

Is this a bug in (the old API still available with) proj-5.0.x or a bug in gdal-2.2+?
Any hints where and how to dig deeper?

Markus M

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdalinfo error and subsequent segfault with proj-5.0.x

Even Rouault-2
Markus,

From a quick test generating a GeoTIFF in EPSG:25832, I can't reproduce.

I suspect you may link at runtime against different proj versions. How did you
build GDAL ? I'd strongly recommend you use --with-static-proj4 (whose name is
a bit misleading since it can actually link against a libproj.so), and then
check with "ldd libgdal.so" that you link against a single libproj.

Even

> I observed a segfault in gdalinfo (2.2.3, 2.2.4, 2.3.0dev-71e2ada881) when
> compiled against proj-5.0.0/proj-5.0.1
>
> The dataset is a GeoTIFF with EPSG:25832, and I get
>
> Corner Coordinates:
> ERROR 1: illegal axis orientation combination
> Upper Left  (  375000.000, 5631000.000)
> ERROR 1: illegal axis orientation combination
> Lower Left  (  375000.000, 5628000.000)
> ERROR 1: illegal axis orientation combination
> Upper Right (  379000.000, 5631000.000)
> ERROR 1: illegal axis orientation combination
> Lower Right (  379000.000, 5628000.000)
> ERROR 1: illegal axis orientation combination
> Center      (  377000.000, 5629500.000)
> Segmentation fault (core dumped)
>
> The error message is printed by GDAL and comes from PROJ. I think the
> segfault is a symptom of the error, therefore I would like to find out the
> reason of the error.
>
> Using gdal-2.2+ with proj-4.9.3, all is fine.
>
> Testing proj-5.0.1 with
>
> cs2cs +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
> +no_defs +to +proj=latlong +ellps=GRS80
>
> proj -I +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
> +no_defs
>
> cct +proj=pipeline +step +inv +proj=utm +zone=32 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
>
> all is fine, too.
>
> Is this a bug in (the old API still available with) proj-5.0.x or a bug in
> gdal-2.2+?
> Any hints where and how to dig deeper?
>
> Markus M


--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdalinfo error and subsequent segfault with proj-5.0.x

Markus Metz-3
Even,

On Sun, Apr 15, 2018 at 8:17 PM, Even Rouault <[hidden email]> wrote:
>
> Markus,
>
> From a quick test generating a GeoTIFF in EPSG:25832, I can't reproduce.
>
> I suspect you may link at runtime against different proj versions.

You are right. I compiled GDAL with

libproj.so -> libproj.so.13.0.1
there is no other libproj.so on my system

but gdal links against libproj.so.12

> How did you
> build GDAL ? I'd strongly recommend you use --with-static-proj4 (whose name is
> a bit misleading since it can actually link against a libproj.so), and then
> check with "ldd libgdal.so" that you link against a single libproj.

OK, I recompiled gdal-2.2.4 --with-static-proj4 and got

ldd libgdal.so | grep proj
    libproj.so.13 => /usr/local/lib64/libproj.so.13 (0x00007fe2ff181000)
    libproj.so.12 => /lib64/libproj.so.12 (0x00007fe2f31c7000)
???

gdalinfo now runs fine and produces expected results.

I'm still concerned about the output of ldd libgdal.so

Markus M
>

> Even
>
> > I observed a segfault in gdalinfo (2.2.3, 2.2.4, 2.3.0dev-71e2ada881) when
> > compiled against proj-5.0.0/proj-5.0.1
> >
> > The dataset is a GeoTIFF with EPSG:25832, and I get
> >
> > Corner Coordinates:
> > ERROR 1: illegal axis orientation combination
> > Upper Left  (  375000.000, 5631000.000)
> > ERROR 1: illegal axis orientation combination
> > Lower Left  (  375000.000, 5628000.000)
> > ERROR 1: illegal axis orientation combination
> > Upper Right (  379000.000, 5631000.000)
> > ERROR 1: illegal axis orientation combination
> > Lower Right (  379000.000, 5628000.000)
> > ERROR 1: illegal axis orientation combination
> > Center      (  377000.000, 5629500.000)
> > Segmentation fault (core dumped)
> >
> > The error message is printed by GDAL and comes from PROJ. I think the
> > segfault is a symptom of the error, therefore I would like to find out the
> > reason of the error.
> >
> > Using gdal-2.2+ with proj-4.9.3, all is fine.
> >
> > Testing proj-5.0.1 with
> >
> > cs2cs +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
> > +no_defs +to +proj=latlong +ellps=GRS80
> >
> > proj -I +proj=utm +zone=32 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=m
> > +no_defs
> >
> > cct +proj=pipeline +step +inv +proj=utm +zone=32 +ellps=GRS80
> > +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
> >
> > all is fine, too.
> >
> > Is this a bug in (the old API still available with) proj-5.0.x or a bug in
> > gdal-2.2+?
> > Any hints where and how to dig deeper?
> >
> > Markus M
>
>
> --
> Spatialys - Geospatial professional services
> http://www.spatialys.com


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdalinfo error and subsequent segfault with proj-5.0.x

Even Rouault-2
> OK, I recompiled gdal-2.2.4 --with-static-proj4 and got
>
> ldd libgdal.so | grep proj
>     libproj.so.13 => /usr/local/lib64/libproj.so.13 (0x00007fe2ff181000)
>     libproj.so.12 => /lib64/libproj.so.12 (0x00007fe2f31c7000)
> ???
>
> gdalinfo now runs fine and produces expected results.
>
> I'm still concerned about the output of ldd libgdal.so

Yes that's not sane. That means that GDAL links to a library that links to the
system libproj (/lib64/libproj.so.12), whereas GDAL directly links to your
custom libproj 5 build ( /usr/local/lib64/libproj.so.13) . That may crash as
well.
As proj 5.0.1 is (I believe) ABI compatible with previous releases, one
potential hack is to make
sudo ln -s /usr/local/lib64/libproj.so.13 /usr/local/lib64/libproj.so.12
and define LD_LIBRARY_PATH to point to /usr/local/lib64/
A cleaner solution would be to identify the GDAL dependenci(es) that link to  
/lib64/libproj.so.12 and rebuild them against the one in  /usr/local/lib64/
libproj.so.13

--
Spatialys - Geospatial professional services
http://www.spatialys.com
_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
Reply | Threaded
Open this post in threaded view
|

Re: gdalinfo error and subsequent segfault with proj-5.0.x

Markus Metz-3


On Sun, Apr 15, 2018 at 10:07 PM, Even Rouault <[hidden email]> wrote:

>
> > OK, I recompiled gdal-2.2.4 --with-static-proj4 and got
> >
> > ldd libgdal.so | grep proj
> >     libproj.so.13 => /usr/local/lib64/libproj.so.13 (0x00007fe2ff181000)
> >     libproj.so.12 => /lib64/libproj.so.12 (0x00007fe2f31c7000)
> > ???
> >
> > gdalinfo now runs fine and produces expected results.
> >
> > I'm still concerned about the output of ldd libgdal.so
>
> Yes that's not sane. That means that GDAL links to a library that links to the
> system libproj (/lib64/libproj.so.12), whereas GDAL directly links to your
> custom libproj 5 build ( /usr/local/lib64/libproj.so.13) . That may crash as
> well.
>
> As proj 5.0.1 is (I believe) ABI compatible with previous releases, one
> potential hack is to make
> sudo ln -s /usr/local/lib64/libproj.so.13 /usr/local/lib64/libproj.so.12
> and define LD_LIBRARY_PATH to point to /usr/local/lib64/
> A cleaner solution would be to identify the GDAL dependenci(es) that link to
> /lib64/libproj.so.12 and rebuild them against the one in  /usr/local/lib64/
> libproj.so.13

Not too many on my test system. So far, GDAL is working for me now with PROJ-5.0.x. If I encounter any problems later on, I will heed your advice.

Thanks a lot for your help!

Markus M


_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev