* bug#39204: r-rgdal: Reading of vector GIS data causes segfault
@ 2020-01-20 15:43 Wiktor Żelazny
2020-01-20 19:50 ` zimoun
0 siblings, 1 reply; 20+ messages in thread
From: Wiktor Żelazny @ 2020-01-20 15:43 UTC (permalink / raw)
To: 39204
[-- 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 --]
^ permalink raw reply [flat|nested] 20+ messages in thread* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-01-20 15:43 bug#39204: r-rgdal: Reading of vector GIS data causes segfault Wiktor Żelazny @ 2020-01-20 19:50 ` zimoun 2020-02-20 10:35 ` zimoun 0 siblings, 1 reply; 20+ messages in thread From: zimoun @ 2020-01-20 19:50 UTC (permalink / raw) To: wz; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-01-20 19:50 ` zimoun @ 2020-02-20 10:35 ` zimoun 2020-02-20 17:10 ` Arun Isaac 0 siblings, 1 reply; 20+ messages in thread From: zimoun @ 2020-02-20 10:35 UTC (permalink / raw) To: wz, Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-20 10:35 ` zimoun @ 2020-02-20 17:10 ` Arun Isaac 2020-02-21 11:19 ` zimoun 2020-02-21 18:53 ` zimoun 0 siblings, 2 replies; 20+ messages in thread From: Arun Isaac @ 2020-02-20 17:10 UTC (permalink / raw) To: zimoun, wz; +Cc: 39204 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-20 17:10 ` Arun Isaac @ 2020-02-21 11:19 ` zimoun 2020-02-21 12:12 ` Arun Isaac 2020-02-21 18:53 ` zimoun 1 sibling, 1 reply; 20+ messages in thread From: zimoun @ 2020-02-21 11:19 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 11:19 ` zimoun @ 2020-02-21 12:12 ` Arun Isaac 2020-02-21 12:30 ` zimoun 2020-02-21 18:54 ` zimoun 0 siblings, 2 replies; 20+ messages in thread From: Arun Isaac @ 2020-02-21 12:12 UTC (permalink / raw) To: zimoun; +Cc: 39204 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 12:12 ` Arun Isaac @ 2020-02-21 12:30 ` zimoun 2020-02-21 18:54 ` zimoun 1 sibling, 0 replies; 20+ messages in thread From: zimoun @ 2020-02-21 12:30 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 12:12 ` Arun Isaac 2020-02-21 12:30 ` zimoun @ 2020-02-21 18:54 ` zimoun 2020-02-21 21:35 ` Arun Isaac 1 sibling, 1 reply; 20+ messages in thread From: zimoun @ 2020-02-21 18:54 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 18:54 ` zimoun @ 2020-02-21 21:35 ` Arun Isaac 2020-02-21 22:14 ` zimoun 0 siblings, 1 reply; 20+ messages in thread From: Arun Isaac @ 2020-02-21 21:35 UTC (permalink / raw) To: zimoun; +Cc: 39204 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 21:35 ` Arun Isaac @ 2020-02-21 22:14 ` zimoun 0 siblings, 0 replies; 20+ messages in thread From: zimoun @ 2020-02-21 22:14 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-20 17:10 ` Arun Isaac 2020-02-21 11:19 ` zimoun @ 2020-02-21 18:53 ` zimoun 2020-02-21 21:40 ` Arun Isaac 1 sibling, 1 reply; 20+ messages in thread From: zimoun @ 2020-02-21 18:53 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 18:53 ` zimoun @ 2020-02-21 21:40 ` Arun Isaac 2020-02-21 22:19 ` zimoun 0 siblings, 1 reply; 20+ messages in thread From: Arun Isaac @ 2020-02-21 21:40 UTC (permalink / raw) To: zimoun; +Cc: 39204 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 21:40 ` Arun Isaac @ 2020-02-21 22:19 ` zimoun 2020-02-22 19:42 ` Arun Isaac 0 siblings, 1 reply; 20+ messages in thread From: zimoun @ 2020-02-21 22:19 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-21 22:19 ` zimoun @ 2020-02-22 19:42 ` Arun Isaac 2020-02-24 11:33 ` zimoun 0 siblings, 1 reply; 20+ messages in thread From: Arun Isaac @ 2020-02-22 19:42 UTC (permalink / raw) To: zimoun; +Cc: 39204 [-- 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 --] ^ permalink raw reply related [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-22 19:42 ` Arun Isaac @ 2020-02-24 11:33 ` zimoun 2020-02-24 19:09 ` Arun Isaac 0 siblings, 1 reply; 20+ messages in thread From: zimoun @ 2020-02-24 11:33 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-24 11:33 ` zimoun @ 2020-02-24 19:09 ` Arun Isaac 2020-02-25 15:49 ` zimoun 0 siblings, 1 reply; 20+ messages in thread From: Arun Isaac @ 2020-02-24 19:09 UTC (permalink / raw) To: zimoun; +Cc: 39204 [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-24 19:09 ` Arun Isaac @ 2020-02-25 15:49 ` zimoun 2020-10-12 10:22 ` Arun Isaac 0 siblings, 1 reply; 20+ messages in thread From: zimoun @ 2020-02-25 15:49 UTC (permalink / raw) To: Arun Isaac; +Cc: 39204 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 ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-02-25 15:49 ` zimoun @ 2020-10-12 10:22 ` Arun Isaac 2020-10-12 16:23 ` Wiktor Żelazny 0 siblings, 1 reply; 20+ messages in thread From: Arun Isaac @ 2020-10-12 10:22 UTC (permalink / raw) To: zimoun; +Cc: wz, 39204-done 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! ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-10-12 10:22 ` Arun Isaac @ 2020-10-12 16:23 ` Wiktor Żelazny 2020-10-13 4:21 ` Arun Isaac 0 siblings, 1 reply; 20+ messages in thread From: Wiktor Żelazny @ 2020-10-12 16:23 UTC (permalink / raw) To: 39204-done [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#39204: r-rgdal: Reading of vector GIS data causes segfault 2020-10-12 16:23 ` Wiktor Żelazny @ 2020-10-13 4:21 ` Arun Isaac 0 siblings, 0 replies; 20+ messages in thread From: Arun Isaac @ 2020-10-13 4:21 UTC (permalink / raw) To: Wiktor Żelazny, 39204-done [-- 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 --] ^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2020-10-13 4:22 UTC | newest] Thread overview: 20+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2020-01-20 15:43 bug#39204: r-rgdal: Reading of vector GIS data causes segfault Wiktor Żelazny 2020-01-20 19:50 ` zimoun 2020-02-20 10:35 ` zimoun 2020-02-20 17:10 ` Arun Isaac 2020-02-21 11:19 ` zimoun 2020-02-21 12:12 ` Arun Isaac 2020-02-21 12:30 ` zimoun 2020-02-21 18:54 ` zimoun 2020-02-21 21:35 ` Arun Isaac 2020-02-21 22:14 ` zimoun 2020-02-21 18:53 ` zimoun 2020-02-21 21:40 ` Arun Isaac 2020-02-21 22:19 ` zimoun 2020-02-22 19:42 ` Arun Isaac 2020-02-24 11:33 ` zimoun 2020-02-24 19:09 ` Arun Isaac 2020-02-25 15:49 ` zimoun 2020-10-12 10:22 ` Arun Isaac 2020-10-12 16:23 ` Wiktor Żelazny 2020-10-13 4:21 ` Arun Isaac
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/guix.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).