bug#39204: r-rgdal: Reading of vector GIS data causes segfault

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 1070 bytes --]

Hi list,

The same behaviour on two machines.

To reproduce:

guix environment --container --ad-hoc r r-rgdal
Rscript -e 'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; ogrInfo(dsn=dsn, layer="cities")'

   Loading required package: sp
   rgdal: version: 1.4-8, (SVN revision 845)
   Geospatial Data Abstraction Library extensions to R successfully loaded
   Loaded GDAL runtime: GDAL 3.0.2, released 2019/10/28
   Path to GDAL shared files:
   GDAL binary built with GEOS: TRUE
   Loaded PROJ.4 runtime: Rel. 4.9.3, 15 August 2016, [PJ_VERSION: 493]
   Path to PROJ.4 shared files: (autodetected)
   Linking to sp version: 1.3-2

   *** caught segfault ***
   address 0x30, cause 'memory not mapped'

   Traceback:
   1: ogrFIDs(dsn = dsn, layer = layer)
   2: ogrInfo(dsn = dsn, layer = "cities")
   An irrecoverable exception occurred. R is aborting now ...
   sh: rm: command not found
   Segmentation fault

Opening with QGIS, which also depends on GDAL (it uses PROJ.6 instead of
PROJ.4, though), works.

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi,

Thank you for reporting.


The issue is that the error is not catched at build time. It is not
expected. This package should fail and not say "successfully built".

Well, this needs more investigation.


--8<---------------cut here---------------start------------->8---
$ guix build r-rgdal --check --no-grafts -K
[...]
phase `install' succeeded after 19.0 seconds
starting phase `check'
Testing examples for package ‘rgdal’
/gnu/store/dnb6fzp5295fcda66dnjk2y51mcva20f-r-minimal-3.6.2/lib/R/bin/BATCH:
line 60:   598 Segmentation fault      ${R_HOME}/bin/R -f ${in}
${opts} ${R_BATCH_OPTIONS} > ${out} 2>&1
[...]
successfully built /gnu/store/7spmagnk5fycwxsigdypwkmk4kazbw7a-r-rgdal-1.4-8.drv
note: keeping build directory `/tmp/guix-build-r-rgdal-1.4-8.drv-0'
/gnu/store/dgkyzlasbqsxcsfk3n3bgmhrpg447f55-r-rgdal-1.4-8
--8<---------------cut here---------------end--------------->8---

Good catch! :-)


All the best,
simon

--

$ guix describe
Generation 68   Jan 16 2020 15:57:09    (current)
  guix d14e474
    repository URL: https://git.savannah.gnu.org/git/guix.git
    branch: master
    commit: d14e4745b36a835c6babd5b5f5562e12294cd9cf

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

There is 2 issues in this bug report:

 1. the `check' phase is failing but the build ends with "success".
 2. a regression of r-rgdal introduced by your commit
f9d328833fc1f5d0fb76b61b12d1a3cb013932e6


About the point 1., here is what happens:

> --8<---------------cut here---------------start------------->8---
> $ guix build r-rgdal --check --no-grafts -K
> [...]
> phase `install' succeeded after 19.0 seconds
> starting phase `check'
> Testing examples for package ‘rgdal’
> /gnu/store/dnb6fzp5295fcda66dnjk2y51mcva20f-r-minimal-3.6.2/lib/R/bin/BATCH:
> line 60:   598 Segmentation fault      ${R_HOME}/bin/R -f ${in}
> ${opts} ${R_BATCH_OPTIONS} > ${out} 2>&1
> [...]
> successfully built /gnu/store/7spmagnk5fycwxsigdypwkmk4kazbw7a-r-rgdal-1.4-8.drv
> note: keeping build directory `/tmp/guix-build-r-rgdal-1.4-8.drv-0'
> /gnu/store/dgkyzlasbqsxcsfk3n3bgmhrpg447f55-r-rgdal-1.4-8
> --8<---------------cut here---------------end--------------->8---

Therefore, more investigations are required to see why the upstream
test suite does not report correctly the failure.


However, the Segmentation Fault is the point 2. and introduced by the commit:

--8<---------------cut here---------------start------------->8---
commit f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
Author: Arun Isaac <arunisaac@systemreboot.net>
Date:   Thu Dec 5 01:47:47 2019 +0530

    gnu: libgeotiff: Update to 1.5.1.

    * gnu/packages/patches/libgeotiff-adapt-test-script-for-proj-6.2.patch:
    New file.
    * gnu/local.mk (dist_patch_DATA): Register it.
    * gnu/packages/geo.scm (libgeotiff): Update to 1.5.1.
    [inputs]: Replace proj.4 with proj.
    [sources]: Add libgeotiff-adapt-test-script-for-proj-6.2.patch
    to patches.

 gnu/local.mk                                       |  1 +
 gnu/packages/geo.scm                               | 17 +++---
 ...libgeotiff-adapt-test-script-for-proj-6.2.patch | 63 ++++++++++++++++++++++
 3 files changed, 72 insertions(+), 9 deletions(-)
 create mode 100644
gnu/packages/patches/libgeotiff-adapt-test-script-for-proj-6.2.patch
--8<---------------cut here---------------end--------------->8---

I have bisected this way:

git bisect start
git bisect bad ba7ead2b507d94397481be014d6ac0c41c7ddbfa
git bisect good 28d940961cfa1ae6dc574053aec8d03095677df8

# ba7ead2b507d94397481be014d6ac0c41c7ddbfa => bad
# 28d940961cfa1ae6dc574053aec8d03095677df8 => good
# fe0686864dc57ecdda7ecbb318d2618ac46169ae => bad
# 85c945aa97d89fdc17ec5d64c3ffa7f99ba1184b => good
# 885424bf7f6e0bc0ad5dd9353690aa82d17dd8b8 => bad
# 6f5d849a83c44ffb39c3a976aea10b7b31c24063 => good
# ce5b71f98ce39c92637876120f44868ec7ad391f => good
# 96211e3f33d1f1c35fd6377db1d8a4c6ec1a9c22 => bad
# 6cde07379f2a049b8c7f0eca90959f6c170c4102 => bad
# 87a028100c665814c3b5d622701abc6d77144faf => good
# 00d81f9866726f85241f08e444ba3932fcb38842 => good
# e72557c08f4f2fdd545106a9f4f0fc0bc9496249 => bad
# 3500d7addc2f9b2067ffd239383eb0e546be4f43 => good
# f9d328833fc1f5d0fb76b61b12d1a3cb013932e6 => bad


Please could you confirm?
If 'libgeotiff' is really the culprit, then we can try to fix it.



All the best,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 367 bytes --]


> There is 2 issues in this bug report:
>
>  1. the `check' phase is failing but the build ends with "success".

I haven't investigated why this is happening.

>  2. a regression of r-rgdal introduced by your commit
> f9d328833fc1f5d0fb76b61b12d1a3cb013932e6

Replacing proj.4 with proj in the r-rgdal package seems to fix this
regression. Can you confirm?

Thanks!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

On Thu, 20 Feb 2020 at 18:11, Arun Isaac <arunisaac@systemreboot.net> wrote:

> >  2. a regression of r-rgdal introduced by your commit
> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>
> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> regression. Can you confirm?

Maybe, but it is not what the user expects. Upstream explicitly
mentions proj.4, see [1].

[1] https://cloud.r-project.org/web/packages/rgdal/index.html

which is reflected by:

--8<---------------cut here---------------start------------->8---
$ guix show r-rgdal
name: r-rgdal
version: 1.4-8
outputs: out
systems: x86_64-linux i686-linux
dependencies: gdal@3.0.2 pkg-config@0.29.2 proj.4@4.9.3 r-sp@1.3-2 zlib@1.2.11
location: gnu/packages/cran.scm:15897:2
homepage: http://rgdal.r-forge.r-project.org
license: GPL 2+
synopsis: Bindings for the Geospatial Data Abstraction Library
description: This package provides bindings to the Geospatial Data
+ Abstraction Library (GDAL) and access to projection/transformation
+ operations from the PROJ.4 library.
--8<---------------cut here---------------end--------------->8---



The question is: why proj instead of proj.4 in libgeotiff?
The bug [1] cannot be solved using proj.4, why?


[2] https://github.com/OSGeo/libgeotiff/issues/22


All the best,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 899 bytes --]


>> >  2. a regression of r-rgdal introduced by your commit
>> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>>
>> Replacing proj.4 with proj in the r-rgdal package seems to fix this
>> regression. Can you confirm?
>
> Maybe, but it is not what the user expects. Upstream explicitly
> mentions proj.4, see [1].

> [1] https://cloud.r-project.org/web/packages/rgdal/index.html

No, upstream says that both proj (aka proj6) and proj.4 are
supported. Quoting [1],

"From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..."

> The question is: why proj instead of proj.4 in libgeotiff?
> The bug [1] cannot be solved using proj.4, why?

proj and proj.4 are different versions of the same software, with proj
being the newer version. See
https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
deprecate our proj.4 package and replace all occurrences of proj.4 with
proj.

WDYT?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

On Fri, 21 Feb 2020 at 13:13, Arun Isaac <arunisaac@systemreboot.net> wrote:

> >> >  2. a regression of r-rgdal introduced by your commit
> >> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
> >>
> >> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> >> regression. Can you confirm?
> >
> > Maybe, but it is not what the user expects. Upstream explicitly
> > mentions proj.4, see [1].
>
> > [1] https://cloud.r-project.org/web/packages/rgdal/index.html
>
> No, upstream says that both proj (aka proj6) and proj.4 are
> supported. Quoting [1],
>
> "From 'rgdal' 1.4.1, provision is made for 'PROJ6' accommodation, ..."

I agree, but I was referring to "access to projection/transformation
operations from the 'PROJ.4' library." or "Windows and Mac Intel OS X
binaries (including 'GDAL', 'PROJ.4' and 'Expat') are provided on
'CRAN'."

Well, your comment below says my remark here is irrelevant. :-)


> > The question is: why proj instead of proj.4 in libgeotiff?
> > The bug [1] cannot be solved using proj.4, why?
>
> proj and proj.4 are different versions of the same software, with proj
> being the newer version. See
> https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
> deprecate our proj.4 package and replace all occurrences of proj.4 with
> proj.

Thank you for the pointer, I was not aware.
Well, I agree. Let replace all the dependencies of proj.4 by proj and
deprecate our proj.4 package.


--8<---------------cut here---------------start------------->8---
$ guix graph -t reverse-package proj.4 \
    | grep label | cut -d'=' -f2 | cut -d',' -f1
 "proj.4@4.9.3"
 "r-sf@0.8-0"
 "r-spdep@1.1-3"
 "r-monocle3@0.1.2"
 "r-cicero-monocle3@1.3.2-1.fa2fb65"
 "r-adegenet@2.1.2"
 "r-rmetasim@3.1.7"
 "r-hierfstat@0.04-22"
 "r-pegas@0.12"
 "r-rgdal@1.4-8"
 "libosmium@2.14.2"
 "osm2pgsql@0.96.0"
 "mapnik@3.0.18"
 "python2-mapnik@3.0.16"
 "xygrib@1.2.6.1"
 "spatialite-gui@1.7.1"
 "libspatialite@4.3.0a"
 "libgaiagraphics@0.5"
--8<---------------cut here---------------end--------------->8---


Thanks,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

On Thu, 20 Feb 2020 at 18:11, Arun Isaac <arunisaac@systemreboot.net> wrote:

> >  2. a regression of r-rgdal introduced by your commit
> > f9d328833fc1f5d0fb76b61b12d1a3cb013932e6
>
> Replacing proj.4 with proj in the r-rgdal package seems to fix this
> regression. Can you confirm?

You mean:

  guix build --with-input=proj.4=proj r-rgdal

then it compiles a lot... and I do not understand why gdal is
recompiled. Anyway!
So after some CPU burning, I get:

--8<---------------cut here---------------start------------->8---
Testing examples for package ‘rgdal’
Running specific tests for package ‘rgdal’
  Running ‘srs_rendering.R’
  comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
5c5
< [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
---
> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
7c7
< [1] "GDAL 3.0.2, released 2019/10/28"
---
> [1] "GDAL 2.4.0, released 2018/12/14"
11c11
<
                           scot_BNG
---
>                                                                                                                                                      trin_inca_pl03
12c12
< "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
+y_0=-100000 +ellps=airy +units=m +no_defs"
---
>                                                                                                                                                                  NA
13c13
<
                     trin_inca_pl03
---
>                                                                                                                                            kiritimati_primary_roads
14c14
<
                                 NA
---
>                                                                                                                 "+proj=utm +zone=4 +datum=WGS84 +units=m +no_defs "
16c16
<
"+proj=longlat +datum=WGS84 +no_defs"
---
<
           kiritimati_primary_roads
---
>                                                                                                                                                            scot_BNG
18c18
<                                                       "+proj=utm
+zone=4 +datum=WGS84 +units=m +no_defs"
---
> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs "
22c22
< [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
+towgs84=0,0,0,0,0,0,0 +no_defs"
---
> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
24c24
< [1] "+proj=utm +zone=23 +south +ellps=aust_SA
+towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
---
> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs "
26c26
< [1] "+proj=longlat +datum=WGS84 +no_defs"
---
> [1] "+proj=longlat +datum=WGS84 +no_defs "
28c28
< [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
+k_0=0.999877420000019 +x_0=600000 +y_0=2200000.00000032
+ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
+no_defs"
---
> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.9998774200000193 +x_0=600000 +y_0=2200000.000000325 +a=6378249.2 +b=6356515.000000472 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
40c40
< file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.6666666666667
+lon_0=-88.3333333333333 +k=0.999975 +x_0=152400.30480061 +y_0=0
+ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
---
> file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.66666666666666 +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0 +datum=NAD27 +units=us-ft +no_defs
41c41
< file:  cea.tif , SRS:  +proj=cea +lat_ts=33.75
+lon_0=-117.333333333333 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
---
> file:  cea.tif , SRS:  +proj=cea +lon_0=-117.333333333333 +lat_ts=33.75 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
42c42
< file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30
+lon_0=-82.1666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80
+towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
---
> file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30 +lon_0=-82.16666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
43c43
< file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +ellps=WGS84
+towgs84=0,0,0,0,0,0,0 +units=m +no_defs
---
> file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +datum=WGS84 +units=m +no_defs
  Running ‘test_proj.R’
  comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
   Running ‘tests.R’
  comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
  Running ‘tripup.R’
  comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
266c266
<  coords FALSE
---
>  coords TRUE
267c267
<  holes FALSE
---
>  holes TRUE
273c273
<  coords FALSE
---
>  coords TRUE
274c274
<  holes FALSE
---
>  holes TRUE
Running vignettes for package ‘rgdal’
  Running ‘OGR_shape_encoding.Rnw’
phase `check' succeeded after 18.7 seconds
--8<---------------cut here---------------end--------------->8---


Therefore, I do not confirm, I guess.

All the best,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

On Fri, 21 Feb 2020 at 13:13, Arun Isaac <arunisaac@systemreboot.net> wrote:

> proj and proj.4 are different versions of the same software, with proj
> being the newer version. See
> https://proj.org/faq.html#what-happend-to-proj-4 . I say we completely
> deprecate our proj.4 package and replace all occurrences of proj.4 with
> proj.

For other packages than r-rgdal depending on proj.4:
 - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
 - not ok: libspatialite and libosmium

And some packages do not build at all with the default (proj.4):
mapnik and spatialite-gui. Well, it is more than on my machine. ;-)

http://data.guix.gnu.org/revision/e40d6c4c7a74fca3572991c55706a787b19d4d90/package/mapnik/3.0.18
http://data.guix.gnu.org/revision/e40d6c4c7a74fca3572991c55706a787b19d4d90/package/spatialite-gui/1.7.1


All the best,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]


> For other packages than r-rgdal depending on proj.4:
>  - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
>  - not ok: libspatialite and libosmium

Indeed, all packages don't yet support proj. We'll have to keep proj.4
around until their upstreams adds support for proj.

> And some packages do not build at all with the default (proj.4):
> mapnik and spatialite-gui. Well, it is more than on my machine. ;-)

These will have to be fixed too. Do open separate bug reports for
those. Please provide patches if possible.

Thanks!

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 5443 bytes --]


> You mean:
>
>   guix build --with-input=proj.4=proj r-rgdal
>
> then it compiles a lot... and I do not understand why gdal is
> recompiled. Anyway!

Your command recursively replaces proj.4 with proj. So, some dependency
of gdal might have been modified resulting in a rebuild of gdal.

> So after some CPU burning, I get:
>
> --8<---------------cut here---------------start------------->8---
> Testing examples for package ‘rgdal’
> Running specific tests for package ‘rgdal’
>   Running ‘srs_rendering.R’
>   comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
> 5c5
> < [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
> ---
>> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
> 7c7
> < [1] "GDAL 3.0.2, released 2019/10/28"
> ---
>> [1] "GDAL 2.4.0, released 2018/12/14"
> 11c11
> <
>                            scot_BNG
> ---
>>                                                                                                                                                      trin_inca_pl03
> 12c12
> < "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
> +y_0=-100000 +ellps=airy +units=m +no_defs"
> ---
>>                                                                                                                                                                  NA
> 13c13
> <
>                      trin_inca_pl03
> ---
>>                                                                                                                                            kiritimati_primary_roads
> 14c14
> <
>                                  NA
> ---
>>                                                                                                                 "+proj=utm +zone=4 +datum=WGS84 +units=m +no_defs "
> 16c16
> <
> "+proj=longlat +datum=WGS84 +no_defs"
> ---
> <
>            kiritimati_primary_roads
> ---
>>                                                                                                                                                            scot_BNG
> 18c18
> <                                                       "+proj=utm
> +zone=4 +datum=WGS84 +units=m +no_defs"
> ---
>> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 +units=m +no_defs "
> 22c22
> < [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
> +towgs84=0,0,0,0,0,0,0 +no_defs"
> ---
>> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
> 24c24
> < [1] "+proj=utm +zone=23 +south +ellps=aust_SA
> +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
> ---
>> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs "
> 26c26
> < [1] "+proj=longlat +datum=WGS84 +no_defs"
> ---
>> [1] "+proj=longlat +datum=WGS84 +no_defs "
> 28c28
> < [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
> +k_0=0.999877420000019 +x_0=600000 +y_0=2200000.00000032
> +ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
> +no_defs"
> ---
>> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.9998774200000193 +x_0=600000 +y_0=2200000.000000325 +a=6378249.2 +b=6356515.000000472 +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
> 40c40
> < file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.6666666666667
> +lon_0=-88.3333333333333 +k=0.999975 +x_0=152400.30480061 +y_0=0
> +ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.66666666666666 +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 +y_0=0 +datum=NAD27 +units=us-ft +no_defs
> 41c41
> < file:  cea.tif , SRS:  +proj=cea +lat_ts=33.75
> +lon_0=-117.333333333333 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> ---
>> file:  cea.tif , SRS:  +proj=cea +lon_0=-117.333333333333 +lat_ts=33.75 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> 42c42
> < file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30
> +lon_0=-82.1666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30 +lon_0=-82.16666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80 +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> 43c43
> < file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +ellps=WGS84
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
> ---
>> file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +datum=WGS84 +units=m +no_defs
>   Running ‘test_proj.R’
>   comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
>    Running ‘tests.R’
>   comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
>   Running ‘tripup.R’
>   comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
> 266c266
> <  coords FALSE
> ---
>>  coords TRUE
> 267c267
> <  holes FALSE
> ---
>>  holes TRUE
> 273c273
> <  coords FALSE
> ---
>>  coords TRUE
> 274c274
> <  holes FALSE
> ---
>>  holes TRUE
> Running vignettes for package ‘rgdal’
>   Running ‘OGR_shape_encoding.Rnw’
> phase `check' succeeded after 18.7 seconds
> --8<---------------cut here---------------end--------------->8---
>
>
> Therefore, I do not confirm, I guess.

I don't understand. With proj instead of proj.4, it does work, doesn't
it? There are no errors and the check phase succeeds.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

On Fri, 21 Feb 2020 at 22:36, Arun Isaac <arunisaac@systemreboot.net> wrote:

> > For other packages than r-rgdal depending on proj.4:
> >  - ok with proj instead of proj.4: osm2pgsql, xygrib and libgaiagraphics.
> >  - not ok: libspatialite and libosmium
>
> Indeed, all packages don't yet support proj. We'll have to keep proj.4
> around until their upstreams adds support for proj.

So it is difficult to deprecate proj.4, IMHO.

> > And some packages do not build at all with the default (proj.4):
> > mapnik and spatialite-gui. Well, it is more than on my machine. ;-)
>
> These will have to be fixed too. Do open separate bug reports for
> those. Please provide patches if possible.

I will do.


Thanks,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

On Fri, 21 Feb 2020 at 22:40, Arun Isaac <arunisaac@systemreboot.net> wrote:

> > You mean:
> >
> >   guix build --with-input=proj.4=proj r-rgdal
> >
> > then it compiles a lot... and I do not understand why gdal is
> > recompiled. Anyway!
>
> Your command recursively replaces proj.4 with proj. So, some dependency
> of gdal might have been modified resulting in a rebuild of gdal.

Yes, but gdal already depends on proj and not proj.4.
Then I examined the graph and did not find the offending package.
That's why I do not understand why gdal is recompiled.
I mean, let find the intersection between "guix graph gdal" and "guix
graph -t reverse-package proj.4", and I do not understand because I
find it empty.


> > Therefore, I do not confirm, I guess.
>
> I don't understand. With proj instead of proj.4, it does work, doesn't
> it? There are no errors and the check phase succeeds.

I have try to replace proj.4 by proj in the inputs field and I get the
same error.
Well, it does not work for me. Maybe I am doing a mistake.


Cheers,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

[-- Attachment #1.1: Type: text/plain, Size: 481 bytes --]


Let's try to debug the problem you are facing. After applying the
attached patch, please provide the complete outputs of the following
commands. If the output is too long, feel free to send it as an email
attachment.

$ ./pre-inst-env guix build r-gdal

$ ./pre-inst-env guix environment --container --ad-hoc r r-rgdal -- Rscript -e 'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; ogrInfo(dsn=dsn, layer="cities")'

Thank you for your patience! Cheers! :-)


[-- Attachment #1.2: 0001-gnu-r-rgdal-Replace-proj.4-with-proj.patch --]
[-- Type: text/x-patch, Size: 1105 bytes --]

From 7b2430788c2d168bd2a8a848e488a0e03140057b Mon Sep 17 00:00:00 2001
From: Arun Isaac <arunisaac@systemreboot.net>
Date: Sun, 23 Feb 2020 00:46:32 +0530
Subject: [PATCH] gnu: r-rgdal: Replace proj.4 with proj.

* gnu/packages/cran.scm (r-rgdal)[inputs]: Replace proj.4 with proj.
---
 gnu/packages/cran.scm | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/gnu/packages/cran.scm b/gnu/packages/cran.scm
index b731ddc29e..05759459af 100644
--- a/gnu/packages/cran.scm
+++ b/gnu/packages/cran.scm
@@ -18,6 +18,7 @@
 ;;; Copyright © 2018, 2019 Brett Gilio <brettg@gnu.org>
 ;;; Copyright © 2019 Nicolò Balzarotti <anothersms@gmail.com>
 ;;; Copyright © 2019 Wiktor Żelazny <wzelazny@vurv.cz>
+;;; Copyright © 2020 Arun Isaac <arunisaac@systemreboot.net>
 ;;;
 ;;; This file is part of GNU Guix.
 ;;;
@@ -15907,7 +15908,7 @@ effect size.")
     (build-system r-build-system)
     (inputs
      `(("gdal" ,gdal)
-       ("proj.4" ,proj.4)
+       ("proj" ,proj)
        ("zlib" ,zlib)))
     (propagated-inputs
      `(("r-sp" ,r-sp)))
-- 
2.23.0


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

First, your patch does not apply. Because it should be line 21 and not
18 for the addition of your Copyright.


On Sat, 22 Feb 2020 at 20:42, Arun Isaac <arunisaac@systemreboot.net> wrote:

> $ ./pre-inst-env guix build r-rgdal

I get the same message than I previously sent:

https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39204#26


> $ ./pre-inst-env guix environment --container --ad-hoc r r-rgdal -- Rscript -e 'library(rgdal); dsn <- system.file("vectors", package = "rgdal")[1]; ogrInfo(dsn=dsn, layer="cities")'

--8<---------------cut here---------------start------------->8---
Loading required package: sp
rgdal: version: 1.4-8, (SVN revision 845)
 Geospatial Data Abstraction Library extensions to R successfully loaded
 Loaded GDAL runtime: GDAL 3.0.2, released 2019/10/28
 Path to GDAL shared files:
 GDAL binary built with GEOS: TRUE
 Loaded PROJ.4 runtime: Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]
 Path to PROJ.4 shared files: (autodetected)
 Linking to sp version: 1.4-0
Source: "/gnu/store/m4rd975j3979zqqqfwg3b7s070i3n3h3-r-rgdal-1.4-8/site-library/rgdal/vectors",
layer: "cities"
Driver: ESRI Shapefile; number of rows: 606
Feature type: wkbPoint with 2 dimensions
Extent: (-165.27 -53.15) - (177.1302 78.2)
CRS: +proj=longlat +datum=WGS84 +no_defs
LDID: 0
Number of fields: 4
        name type length  typeName
1       NAME    4     40    String
2    COUNTRY    4     12    String
3 POPULATION   12     11 Integer64
4    CAPITAL    4      1    String
--8<---------------cut here---------------end--------------->8---


But as we have talked before, there is an issue about the upstream
test suite of the package (point 1. of [1]). So I am investigating...


[1]  https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39204#26


All the best,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 561 bytes --]


> First, your patch does not apply. Because it should be line 21 and not
> 18 for the addition of your Copyright.

Sorry, I should have rebased with master.

> But as we have talked before, there is an issue about the upstream
> test suite of the package (point 1. of [1]). So I am investigating...

Ah, I understand our miscommunication now. You have been talking about
point 1 (bug in upstream test suite) and I've been talking about point 2
(segmentation fault when loading vector data). Yes, replacing proj.4
with proj only addresses point 2, not point 1.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[zimoun]

Hi Arun,

On Mon, 24 Feb 2020 at 20:10, Arun Isaac <arunisaac@systemreboot.net> wrote:

> > But as we have talked before, there is an issue about the upstream
> > test suite of the package (point 1. of [1]). So I am investigating...
>
> Ah, I understand our miscommunication now. You have been talking about
> point 1 (bug in upstream test suite) and I've been talking about point 2
> (segmentation fault when loading vector data). Yes, replacing proj.4
> with proj only addresses point 2, not point 1.

It is not segfaulting anymore, I agree.
But is it enough to know that everything is ok and the package is not broken?

I am mean looking at the output of the 'check' phase (see [1]), it
displays a diff and I am not confident if it is good or not. That's
why I did not confirm that changing from proj.4 to proj works. Maybe I
mispelled "error" in my previous answer and the correct words seem "I
get an lengthy message and I do not know if it is ok." :-)


[1] https://debbugs.gnu.org/cgi/bugreport.cgi?bug=39204#26


Cheers,
simon

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

Hi,

I pushed to master, my commit replacing proj.4 with proj. This fixes the
segfault issue. I also updated the package. If the issue with the check
phase still persists, please open a separate issue.

Cheers!

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Wiktor Żelazny]

[-- Attachment #1: Type: text/plain, Size: 590 bytes --]

On Mon, Oct 12, 2020 at 03:52:30PM +0530, Arun Isaac wrote:

> I pushed to master, my commit replacing proj.4 with proj.

Hi Arun,

Believe it or not, but on Friday I tried the same thing. First,
replacing proj with proj.4 in GDAL, which declined to compile, demanding
version 6, then replacing proj.4 with proj in r-rgdal.

It kept spitting the error during the check phase, but I was
time-machined some months into the past. Maybe with current Guix version
the issue does not occur. I will check it out this or the next week.

Thank you for your work on this issue.

WŻ

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 963 bytes --]

bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

[-- Attachment #1: Type: text/plain, Size: 307 bytes --]


> It kept spitting the error during the check phase, but I was
> time-machined some months into the past. Maybe with current Guix version
> the issue does not occur. I will check it out this or the next week.

Sure, check it out and let me know.

> Thank you for your work on this issue.

My pleasure! :-)

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 524 bytes --]