From mboxrd@z Thu Jan 1 00:00:00 1970 From: zimoun Subject: bug#39204: r-rgdal: Reading of vector GIS data causes segfault Date: Thu, 20 Feb 2020 11:35:12 +0100 Message-ID: References: <20200120154302.ijni47ou4fk4wd77@wzguix> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:33906) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j4jBd-0007zk-1K for bug-guix@gnu.org; Thu, 20 Feb 2020 05:36:06 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j4jBa-0001ct-5N for bug-guix@gnu.org; Thu, 20 Feb 2020 05:36:04 -0500 Received: from debbugs.gnu.org ([209.51.188.43]:37924) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j4jBa-0001cl-1H for bug-guix@gnu.org; Thu, 20 Feb 2020 05:36:02 -0500 Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1j4jBZ-0008Vm-U4 for bug-guix@gnu.org; Thu, 20 Feb 2020 05:36:01 -0500 Sender: "Debbugs-submit" Resent-Message-ID: In-Reply-To: List-Id: Bug reports for GNU Guix List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guix-bounces+gcggb-bug-guix=m.gmane-mx.org@gnu.org Sender: "bug-Guix" To: wz@freeshell.de, Arun Isaac Cc: 39204@debbugs.gnu.org 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 =E2=80=98rgdal=E2=80=99 > /gnu/store/dnb6fzp5295fcda66dnjk2y51mcva20f-r-minimal-3.6.2/lib/R/bin/BAT= CH: > 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 commi= t: --8<---------------cut here---------------start------------->8--- commit f9d328833fc1f5d0fb76b61b12d1a3cb013932e6 Author: Arun Isaac 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 =3D> bad # 28d940961cfa1ae6dc574053aec8d03095677df8 =3D> good # fe0686864dc57ecdda7ecbb318d2618ac46169ae =3D> bad # 85c945aa97d89fdc17ec5d64c3ffa7f99ba1184b =3D> good # 885424bf7f6e0bc0ad5dd9353690aa82d17dd8b8 =3D> bad # 6f5d849a83c44ffb39c3a976aea10b7b31c24063 =3D> good # ce5b71f98ce39c92637876120f44868ec7ad391f =3D> good # 96211e3f33d1f1c35fd6377db1d8a4c6ec1a9c22 =3D> bad # 6cde07379f2a049b8c7f0eca90959f6c170c4102 =3D> bad # 87a028100c665814c3b5d622701abc6d77144faf =3D> good # 00d81f9866726f85241f08e444ba3932fcb38842 =3D> good # e72557c08f4f2fdd545106a9f4f0fc0bc9496249 =3D> bad # 3500d7addc2f9b2067ffd239383eb0e546be4f43 =3D> good # f9d328833fc1f5d0fb76b61b12d1a3cb013932e6 =3D> bad Please could you confirm? If 'libgeotiff' is really the culprit, then we can try to fix it. All the best, simon