CRS() segfault on windows 64 bits #75

Jean-Romain · 2020-03-03T19:42:14Z

This is a minimal reproducible example that crashes the R session on Windows 64 bits using sp 1.4.1 but also former versions

Windows 7, R 3.5.1, 32 bits ✔️
Windows 7, R 3.5.1, 64 bits ❌
Windows 7, R 3.6.1, 32 bits ✔️
Windows 7, R 3.6.1, 64 bits ❌
Windows 7, R 4.0.0, 32 bits ✔️
Windows 7, R 4.0.0, 64 bits ❌
Linux, R 3.6.2, 64 bits ✔️

wkt = "PROJCS[\"NAD83 (2011) / Conus Albers\",GEOGCS[\"GCS_NAD_1983_2011\",DATUM[\"D_NAD_1983_2011\",SPHEROID[\"GRS_1980\",6378137.0,298.257222101,AUTHORITY[\"EPSG\",7019]],AUTHORITY[\"EPSG\",1116]],PRIMEM[\"Greenwich\",0.0,AUTHORITY[\"EPSG\",8901]],UNIT[\"Degree\",0.0174532925199433,AUTHORITY[\"EPSG\",9102]],AUTHORITY[\"EPSG\",6318]],PROJECTION[\"Albers\",AUTHORITY[\"Esri\",43007]],PARAMETER[\"False_Easting\",0.0,AUTHORITY[\"Esri\",100001]],PARAMETER[\"False_Northing\",0.0,AUTHORITY[\"Esri\",100002]],PARAMETER[\"Central_Meridian\",-96.0,AUTHORITY[\"Esri\",100010]],PARAMETER[\"Standard_Parallel_1\",29.5,AUTHORITY[\"Esri\",100025]],PARAMETER[\"Standard_Parallel_2\",45.5,AUTHORITY[\"Esri\",100026]],PARAMETER[\"Latitude_Of_Origin\",23.0,AUTHORITY[\"Esri\",100021]],UNIT[\"Meter\",1.0,AUTHORITY[\"EPSG\",9001]]],VERTCS[\"NAVD_1988\",VDATUM[\"North_American_Vertical_Datum_1988\",AUTHORITY[\"EPSG\",5103]],PARAMETER[\"Vertical_Shift\",0.0,AUTHORITY[\"Esri\",100006]],PARAMETER[\"Direction\",1.0,AUTHORITY[\"Esri\",100007]],UNIT[\"Meter\",1.0,AUTHORITY[\"EPSG\",9001]],AUTHORITY[\"EPSG\",5703]]"
proj4 = rgdal::showP4(wkt)
crs = sp::CRS(proj4) # crash

This issue is related to lidR #323. For the context the WKT string was read from a LAS file format 1.4.

The bug is not always reproducible. To reproduce it with certainty I restart my virtual machine and run a fresh R session in Rstudio. If I restart an R session after a crash the code fails nicely as expected.

crs = sp::CRS(proj4)
#> Error in sp::CRS(proj4) : conic lat_1 = -lat_2

The text was updated successfully, but these errors were encountered:

edzer · 2020-03-03T20:04:45Z

with former versions, do you mean also former versions of sp? If so, also before 1.4.0? @rsbivand

Jean-Romain · 2020-03-03T20:14:47Z

Well on my Windows virtual machine my packages are not always up-to-date. In some above mentioned R versions sp was in version 1.3.x. In R 3.5.1 64 bits it is 1.3.2. In R 3.6.1 64 bits it is 1.4.1

rsbivand · 2020-03-03T21:49:48Z

Which version of rgdal, how installed? The CRAN binaries of rgdal for windows only have pre-barn workflows. With proj 6 and gdal 3, your choice of workflow will stop working. Which other packages are involved? Roger Bivand Falsensvei 32 5063 Bergen tir. 3. mar. 2020, 21.14 skrev Jean-Romain <notifications@github.com>:

…

Well on my Windows virtual machine my packages are not always up-to-date. In some above mentioned R versions sp was in version 1.3.x. In R 3.5.1 64 bits it is 1.3.2. In R 3.6.1 64 bits it is 1.4.1 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75?email_source=notifications&email_token=ACNZ3BEGHWHVEW6BTV5XZYLRFVQLRA5CNFSM4LARTCI2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENU7J7Y#issuecomment-594146559>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNZ3BA3LJFFQXZ3M75TL7LRFVQLRANCNFSM4LARTCIQ> .

Jean-Romain · 2020-03-03T23:20:14Z

I'm not a windows user. I only have a virtual machine to reproduce some windows specific issues. I'm installing the packages using install.package and I'm relying on CRAN binaries. I don't actually know how and where gdal and proj are installed. Please tell me how I can get these information on Windows.

The rgdal versions were 1.4.7 (on R 3.6.1) and 1.4.8 (on R 3.5.1 and R 4.0.0).

No other package are involved. I provided a minimal reproducible example. What do you mean by with proj 6 and gdal 3, your choice of workflow will stop working

rsbivand · 2020-03-04T09:54:28Z

First, if you are a lidR developer, read r-spatial/discuss#28 and the links there to see that your workflows need careful revision to adapt to ongoing changes in sf, sp and rgdal. Then read the output messages on attaching sf or rgdal (rgdal::rgdal_extSoftVersion() too). They display the running versions of PROJ, GDAL, etc. These may have bundled metadata files (Windows and OSX CRAN binaries do bundle metadata files).

Look carefully at:

> cat(strwrap(gsub(",", ", ", wkt)), sep="\n")
PROJCS["NAD83 (2011) / Conus Albers", GEOGCS["GCS_NAD_1983_2011",
DATUM["D_NAD_1983_2011", SPHEROID["GRS_1980", 6378137.0, 298.257222101,
AUTHORITY["EPSG", 7019]], AUTHORITY["EPSG", 1116]], PRIMEM["Greenwich",
0.0, AUTHORITY["EPSG", 8901]], UNIT["Degree", 0.0174532925199433,
AUTHORITY["EPSG", 9102]], AUTHORITY["EPSG", 6318]],
PROJECTION["Albers", AUTHORITY["Esri", 43007]],
PARAMETER["False_Easting", 0.0, AUTHORITY["Esri", 100001]],
PARAMETER["False_Northing", 0.0, AUTHORITY["Esri", 100002]],
PARAMETER["Central_Meridian", -96.0, AUTHORITY["Esri", 100010]],
PARAMETER["Standard_Parallel_1", 29.5, AUTHORITY["Esri", 100025]],
PARAMETER["Standard_Parallel_2", 45.5, AUTHORITY["Esri", 100026]],
PARAMETER["Latitude_Of_Origin", 23.0, AUTHORITY["Esri", 100021]],
UNIT["Meter", 1.0, AUTHORITY["EPSG", 9001]]], VERTCS["NAVD_1988",
VDATUM["North_American_Vertical_Datum_1988", AUTHORITY["EPSG", 5103]],
PARAMETER["Vertical_Shift", 0.0, AUTHORITY["Esri", 100006]],
PARAMETER["Direction", 1.0, AUTHORITY["Esri", 100007]], UNIT["Meter",
1.0, AUTHORITY["EPSG", 9001]], AUTHORITY["EPSG", 5703]]

Can you say which dialect of WKT this is?

On my rgdal, I see:

> rgdal::rgdal_extSoftVersion()
          GDAL GDAL_with_GEOS           PROJ             sp 
       "3.0.4"         "TRUE"        "6.3.1"        "1.4-0" 
> cat(rgdal::showSRID(wkt, format="PROJ", multiline="YES"), "\n")
+proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs 
Warning message:
In rgdal::showSRID(wkt, format = "PROJ", multiline = "YES") :
  Discarded datum NAD83_National_Spatial_Reference_System_2011 in CRS definition
> cat(rgdal::showSRID(wkt, format="WKT1", multiline="YES"), "\n")
PROJCS["NAD83 (2011) / Conus Albers",
    GEOGCS["NAD83(2011)",
        DATUM["NAD83_National_Spatial_Reference_System_2011",
            SPHEROID["GRS 1980",6378137,298.257222101,
                AUTHORITY["EPSG","7019"]],
            AUTHORITY["EPSG","1116"]],
        PRIMEM["Greenwich",0,
            AUTHORITY["EPSG","8901"]],
        UNIT["degree",0.0174532925199433,
            AUTHORITY["EPSG","9122"]],
        AUTHORITY["EPSG","6318"]],
    PROJECTION["Albers_Conic_Equal_Area"],
    PARAMETER["latitude_of_center",23],
    PARAMETER["longitude_of_center",-96],
    PARAMETER["standard_parallel_1",29.5],
    PARAMETER["standard_parallel_2",45.5],
    PARAMETER["false_easting",0],
    PARAMETER["false_northing",0],
    UNIT["metre",1,
        AUTHORITY["EPSG","9001"]],
    AXIS["Easting",EAST],
    AXIS["Northing",NORTH]] 
> cat(rgdal::showSRID(wkt, format="WKT2", multiline="YES"), "\n")
PROJCRS["NAD83 (2011) / Conus Albers",
    BASEGEOGCRS["NAD83(2011)",
        DATUM["NAD83 (National Spatial Reference System 2011)",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["Degree",0.0174532925199433]],
        ID["EPSG",6318]],
    CONVERSION["unnamed",
        METHOD["Albers Equal Area",
            ID["EPSG",9822]],
        PARAMETER["Latitude of false origin",23,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8821]],
        PARAMETER["Longitude of false origin",-96,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8822]],
        PARAMETER["Latitude of 1st standard parallel",29.5,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8823]],
        PARAMETER["Latitude of 2nd standard parallel",45.5,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8824]],
        PARAMETER["Easting at false origin",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8826]],
        PARAMETER["Northing at false origin",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8827]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1,
                ID["EPSG",9001]]]]

all of which drop the VERTCS[] node. It was always dropped in PROJ anyway, I think.

I can reproduce the crash on Windows 10, R 3.6.2, sp 1.4-1 and rgdal 1.4-8 (CRAN binaries), which has PROJ 4.9.3 and GDAL 2.2.3, . A work-around is to avoid going back to rgdal in sp::CRS(proj4, doCheckCRSArgs=FALSE), as the string is by default checked in PROJ. The failure occurs in compiled code in rgdal in RGDAL_checkCRSArgs(), but will take time to debug.

To just put the trusted PROJ string into the CRS object, use the work-around. We need active collaboration to find out the dialect of your WKT string, so that our current PROJ >= 6 and GDAL >= 3 workflows do not discard VERTCS[], which your data really do need.

rsbivand · 2020-03-04T11:50:16Z

On Windows 32-bit, I see:

32-bit
> proj4 = rgdal::showP4(wkt)
> proj4
[1] "+proj=aea +lat_1=0 +lat_2=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs "
> crs = sp::CRS(proj4) # crash
Error in sp::CRS(proj4) : conic lat_1 = -lat_2
>

which is what you see sometimes (PROJ error).

64-bit
> proj4 = rgdal::showP4(wkt)
> proj4
[1] "+proj=aea +lat_1=0 +lat_2=0 +lat_0=0 +lon_0=0 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs "
>

and

> proj4 = rgdal::showP4(wkt, morphFromESRI=FALSE)
> proj4
""

On Linux, with recent PROJ/GDAL:

> proj4
[1] "+proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0 +ellps=GRS80 +units=m +no_defs"

rsbivand · 2020-03-04T12:01:41Z

My best guess is that you are feeding a very modern WKT representation into an old version of GDAL/PROJ. Turning off morphFromESRI= returns an empty string on Win 64-bits predictably. So probably the logic in PROJ (4.9.3) fails if asked to morph from ESRI (the shapefile .prj WKT1 representation) when the WKT isn't 1 but newer. PROJ never returns, so the error is not trapped. PROJ 4.9.3 is not going to be patched, so no point filing a bug there; 7.0.0 was released 1 March. I'll turn all the morph*ESRI to FALSE in rgdal, but lidR and others needs to check WKT strings very carefully.

rsbivand · 2020-03-04T12:33:13Z

Roll-my-own Windows rgdal binary at http://spatial.nhh.no/R/rgdal/rgdal_1.5-6.zip (PROJ 4.9.3, GDAL 2.2.3), source at http://spatial.nhh.no/R/rgdal/rgdal_1.5-6.tar.gz. The CRS will be trashed, but it should stop crashes. Report back, please.

Jean-Romain · 2020-03-04T14:52:35Z

Can you say which dialect of WKT this is?

No. Actually I have only few knowledge about projections. I didn't even know there was some dialects of WTK. My rlas package provides the ability to read the raw content of .las and .laz files used to store laser point clouds. My lidR package provides tools to process such point clouds and it tries to transform the raw CRS read 'as is' by rlas into something that fits with the R spatial ecosystem.

In a las file, depending on the format, the CRS is either an EPSG code or a WKT string. When it is an EPSG code I'm doing

tryCatch(sp::CRS(paste0("+init=epsg:", epsg_code)), error = function(e) sp::CRS())

when it is a WTK string I'm doing

tryCatch(sp::CRS(rgdal::showP4(wkt_string)), error = function(e) sp::CRS())

This is (almost) all the CRS related jobs done by lidR. It belongs in those 2 lines of code. The other parts being only the transfer of the CRS from the input (a point cloud) to the outputs (raster, sp, sf objects).

My best guess is that you are feeding a very modern WKT representation into an old version of GDAL/PROJ

The .las file format 1.4 (with a WTK string) is still pretty rare but are going to be more represented. This is the second file I actually encounter. In the first one the WKT was

wkt = "COMPD_CS[\"Projected\", PROJCS[\"UTM_10N\", GEOGCS [ \"WGS84\", DATUM [ \"WGS84\", SPHEROID [\"WGS 84\", 6378137.000, 298.257223563 ], TOWGS84 [ 0.000, 0.000, 0.000, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000 ] ], PRIMEM [ \"Greenwich\", 0.000000 ], UNIT [ \"metres\", 1.00000000] ], PROJECTION[\"Transverse_Mercator\"], PARAMETER[\"Latitude_of_Origin\",0.0000000000], PARAMETER[\"Central_Meridian\",-123.0000000000], PARAMETER[\"Scale_Factor\",0.9996000000], PARAMETER[\"False_Easting\",500000.000], PARAMETER[\"False_Northing\",0.000], UNIT [ \"metres\", 1.00000000]] ], VERT_CS[\"NAVD88 (Geoid03) ContUS\", VERT_DATUM[\"./Resources/CoordSysData/navd88_geo03_contus.bin\", 1 ], UNIT [ \"metres\", 1.00000000] ] ]"
proj4 = rgdal::showP4(wkt)
crs = sp::CRS(proj4)
crs
#> CRS arguments:
#> +proj=tmerc +lat_0=0 +lon_0=-7047.38088010913 +k=0.9996 +x_0=500000 +y_0=0 +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +units=m +no_defs

First, if you are a lidR developer, read r-spatial/discuss#28 and the links there to see that your workflows need careful revision to adapt to ongoing changes in sf, sp and rgdal.

I already read those links (you reported an issue I fixed in lidR r-lidar/lidR#299) but to be honest I hardly understand a third of the problem and I'm lost with all the forthcoming changes ; the current state of the art being already confusing (as I said I'm not enough knowledgeable about CRS)

The CRS will be trashed, but it should stop crashes. Report back, please.

I tried in R 3.6.1 x64 and it returned NA without crash.

rsbivand · 2020-03-04T17:41:04Z

Thanks for checking. I'll be some time before rgdal is released. The problem with the current workflows (after just glancing) is that with LAS 1.4 you will have a WKT representation with VERTCS[], but by converting to PROJ and instantiating an sp::CRS, you lose most of the important information. In principle, using development sf SetFromUserInput branch, becoming master soon, you input the WKT. For sp and PROJ >=6, GDAL >= 3, the WKT can be fed through the new SRS_string= argument to sp::CRS(), which is then used in rgdal.

Unfortunately, passing both of the WKT strings you've provided to the PROJ command line application projinfo leads to errors. There seem to be either unmatched square brackets or other issues. Are the raw LAS files available anywhere for download, with a script to read them? It feels as though either here the copies are incomplete, or that the dialect of WKT used by LAS is not for now compatible with PROJ. If the latter, I'll raise this on the PROJ developers list.

edzer · 2020-03-04T17:47:28Z

FYI, branch SetFromUserInput has just been merged in master, to be released within 2 weeks.

Jean-Romain · 2020-03-04T18:54:31Z

The las file is available here. You can read the header of the file in R with

h = rlas::read.lasheader("e1054n0839.las")
h[["Variable Length Records"]][["WKT OGC CS"]][["WKT OGC COORDINATE SYSTEM"]]
#> [1] "PROJCS[\"NAD83 (2011) / Conus Albers\",GEOGCS[\"GCS_NAD_1983_2011\",DATUM[\"D_NAD_1983_2011\",SPHEROID[\"GRS_1980\",6378137.0,298.257222101,AUTHORITY[\"EPSG\",7019]],AUTHORITY[\"EPSG\",1116]],PRIMEM[\"Greenwich\",0.0,AUTHORITY[\"EPSG\",8901]],UNIT[\"Degree\",0.0174532925199433,AUTHORITY[\"EPSG\",9102]],AUTHORITY[\"EPSG\",6318]],PROJECTION[\"Albers\",AUTHORITY[\"Esri\",43007]],PARAMETER[\"False_Easting\",0.0,AUTHORITY[\"Esri\",100001]],PARAMETER[\"False_Northing\",0.0,AUTHORITY[\"Esri\",100002]],PARAMETER[\"Central_Meridian\",-96.0,AUTHORITY[\"Esri\",100010]],PARAMETER[\"Standard_Parallel_1\",29.5,AUTHORITY[\"Esri\",100025]],PARAMETER[\"Standard_Parallel_2\",45.5,AUTHORITY[\"Esri\",100026]],PARAMETER[\"Latitude_Of_Origin\",23.0,AUTHORITY[\"Esri\",100021]],UNIT[\"Meter\",1.0,AUTHORITY[\"EPSG\",9001]]],VERTCS[\"NAVD_1988\",VDATUM[\"North_American_Vertical_Datum_1988\",AUTHORITY[\"EPSG\",5103]],PARAMETER[\"Vertical_Shift\",0.0,AUTHORITY[\"Esri\",100006]],PARAMETER[\"Direction\",1.0,AUTHORITY[\"Esri\",100007]],UNIT[\"Meter\",1.0,AUTHORITY[\"EPSG\",9001]],AUTHORITY[\"EPSG\",5703]]"

I also checked the file with lasinfo from LAStools a command line software to process las files. It prints the same string so no issue from rlas itself.

PROJCS["NAD83 (2011) / Conus Albers",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101,AUTHORITY["EPSG",7019]],AUTHORITY["EPSG",1116]],PRIMEM["Greenwich",0.0,AUTHORITY["EPSG",8901]],UNIT["Degree",0.0174532925199433,AUTHORITY["EPSG",9102]],AUTHORITY["EPSG",6318]],PROJECTION["Albers",AUTHORITY["Esri",43007]],PARAMETER["False_Easting",0.0,AUTHORITY["Esri",100001]],PARAMETER["False_Northing",0.0,AUTHORITY["Esri",100002]],PARAMETER["Central_Meridian",-96.0,AUTHORITY["Esri",100010]],PARAMETER["Standard_Parallel_1",29.5,AUTHORITY["Esri",100025]],PARAMETER["Standard_Parallel_2",45.5,AUTHORITY["Esri",100026]],PARAMETER["Latitude_Of_Origin",23.0,AUTHORITY["Esri",100021]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]]],VERTCS["NAVD_1988",VDATUM["North_American_Vertical_Datum_1988",AUTHORITY["EPSG",5103]],PARAMETER["Vertical_Shift",0.0,AUTHORITY["Esri",100006]],PARAMETER["Direction",1.0,AUTHORITY["Esri",100007]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]],AUTHORITY["EPSG",5703]]

As a conclusion your advice is to use crs = sp::CRS(SRS_string = wkt). However it returns NA on my computer (Linux, R 3.6.3, PROJ6, GDAL3, sp 1.4.0, rgdal 1.4.8)

wkt = "PROJCS[\"NAD83 (2011) / Conus Albers\" [...]"

proj4 = rgdal::showP4(wkt)
crs = sp::CRS(proj4, doCheckCRSArgs = FALSE)
crs
#> CRS arguments:
#>  +proj=aea +lat_0=23 +lon_0=-96 +lat_1=29.5 +lat_2=45.5 +x_0=0 +y_0=0
#> +ellps=GRS80 +units=m +no_defs

crs = sp::CRS(SRS_string = wkt)
crs
#> CRS arguments: NA

LAS 1.4 you will have a WKT representation with VERTCS[], but by converting to PROJ and instantiating an sp::CRS, you lose most of the important information.

To me it is not a big problem:

Most files actually record a CRS without vertical coordinate system (or without CRS at all)
The main goal is to know where were are on earth.
When propagated to the outputs (e.g. a RasterLayer or SpatialPoints*), the PROJ format is the way and the vertical CS rarely makes sense.
The full WKT remains accessible because it is stored in the header loaded in R. The PROJ only intends to make my formal class LAS compatible with the R spatial ecosystem.

rsbivand · 2020-03-05T11:40:11Z

None of these raw strings from LAS files (1.4, WKT specified) seem to render as expected in projinfo:

COMPD_CS["Projected", PROJCS["UTM_10N", GEOGCS [ "WGS84", DATUM [ "WGS84", SPHEROID ["WGS 84", 6378137.000, 298.257223563 ], TOWGS84 [ 0.000, 0.000, 0.000, 0.0000000000, 0.0000000000, 0.0000000000, 0.0000000000 ] ], PRIMEM [ "Greenwich", 0.000000 ], UNIT [ "metres", 1.00000000] ], PROJECTION["Transverse_Mercator"], PARAMETER["Latitude_of_Origin",0.0000000000], PARAMETER["Central_Meridian",-123.0000000000], PARAMETER["Scale_Factor",0.9996000000], PARAMETER["False_Easting",500000.000], PARAMETER["False_Northing",0.000], UNIT [ "metres", 1.00000000]] ], VERT_CS["NAVD88 (Geoid03) ContUS", VERT_DATUM["./Resources/CoordSysData/navd88_geo03_contus.bin", 1 ], UNIT [ "metres", 1.00000000] ] ]

PROJCS["NAD83 (2011) / Conus Albers",GEOGCS["GCS_NAD_1983_2011",DATUM["D_NAD_1983_2011",SPHEROID["GRS_1980",6378137.0,298.257222101,AUTHORITY["EPSG",7019]],AUTHORITY["EPSG",1116]],PRIMEM["Greenwich",0.0,AUTHORITY["EPSG",8901]],UNIT["Degree",0.0174532925199433,AUTHORITY["EPSG",9102]],AUTHORITY["EPSG",6318]],PROJECTION["Albers",AUTHORITY["Esri",43007]],PARAMETER["False_Easting",0.0,AUTHORITY["Esri",100001]],PARAMETER["False_Northing",0.0,AUTHORITY["Esri",100002]],PARAMETER["Central_Meridian",-96.0,AUTHORITY["Esri",100010]],PARAMETER["Standard_Parallel_1",29.5,AUTHORITY["Esri",100025]],PARAMETER["Standard_Parallel_2",45.5,AUTHORITY["Esri",100026]],PARAMETER["Latitude_Of_Origin",23.0,AUTHORITY["Esri",100021]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]]],VERTCS["NAVD_1988",VDATUM["North_American_Vertical_Datum_1988",AUTHORITY["EPSG",5103]],PARAMETER["Vertical_Shift",0.0,AUTHORITY["Esri",100006]],PARAMETER["Direction",1.0,AUTHORITY["Esri",100007]],UNIT["Meter",1.0,AUTHORITY["EPSG",9001]],AUTHORITY["EPSG",5703]]

eliocamp · 2020-03-24T22:02:39Z

I'm having a perhaps related issue. Using sp::CRS() crashes with strange errors (probably at the C level, but I don't know enough to be sure) but only when knitting!

This is running with reprex:

proj <- sp::CRS("+proj=longlat +datum=WGS84")
proj
#> CRS arguments:
#>  +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0

^{Created on 2020-03-24 by the reprex package (v0.3.0)}

But if I try to knit this document

---
title: "Untitled"
output: html_document
---

```{r}
proj <- sp::CRS("+proj=longlat +datum=WGS84")
proj
```

I get. munmap_chunk(): invalid pointer.

Strangely, if I remove the last line ("proj"), then I get a different error: double free or corruption (out). Another error I get is free(): invalid pointer. It seems that adding or removing valid R code around proj <- sp::CRS("+proj=longlat +datum=WGS84") changes the error slightly, but it always fails.

I'm on Ubuntu 64bits and using the latest sp package from CRAN (version 1.4-1)

Session info

devtools::session_info()
#> ─ Session info ───────────────────────────────────────────────────────────────
#>  setting  value                         
#>  version  R version 3.6.3 (2020-02-29)  
#>  os       elementary OS 5.1.2 Hera      
#>  system   x86_64, linux-gnu             
#>  ui       X11                           
#>  language en_US                         
#>  collate  en_US.UTF-8                   
#>  ctype    en_US.UTF-8                   
#>  tz       America/Argentina/Buenos_Aires
#>  date     2020-03-24                    
#> 
#> ─ Packages ───────────────────────────────────────────────────────────────────
#>  package     * version    date       lib source                   
#>  assertthat    0.2.1      2019-03-21 [1] CRAN (R 3.6.0)           
#>  backports     1.1.5      2019-10-02 [1] CRAN (R 3.6.1)           
#>  callr         3.4.2      2020-02-12 [1] CRAN (R 3.6.2)           
#>  cli           2.0.2      2020-02-28 [1] CRAN (R 3.6.3)           
#>  crayon        1.3.4      2017-09-16 [1] CRAN (R 3.6.2)           
#>  desc          1.2.0      2018-05-01 [1] CRAN (R 3.6.0)           
#>  devtools      2.2.2      2020-02-17 [1] CRAN (R 3.6.3)           
#>  digest        0.6.25     2020-02-23 [1] CRAN (R 3.6.3)           
#>  ellipsis      0.3.0      2019-09-20 [1] CRAN (R 3.6.1)           
#>  evaluate      0.14       2019-05-28 [1] CRAN (R 3.6.0)           
#>  fansi         0.4.1      2020-01-08 [1] CRAN (R 3.6.2)           
#>  fs            1.3.2      2020-03-05 [1] CRAN (R 3.6.3)           
#>  glue          1.3.2      2020-03-12 [1] CRAN (R 3.6.3)           
#>  highr         0.8        2019-03-20 [1] CRAN (R 3.6.0)           
#>  htmltools     0.4.0      2019-10-04 [1] CRAN (R 3.6.1)           
#>  knitr         1.28       2020-02-06 [1] CRAN (R 3.6.2)           
#>  lattice       0.20-40    2020-02-19 [4] CRAN (R 3.6.2)           
#>  magrittr      1.5        2014-11-22 [1] CRAN (R 3.6.0)           
#>  memoise       1.1.0      2017-04-21 [1] CRAN (R 3.6.0)           
#>  pkgbuild      1.0.6      2019-10-09 [1] CRAN (R 3.6.2)           
#>  pkgload       1.0.2      2018-10-29 [1] CRAN (R 3.6.0)           
#>  prettyunits   1.1.1      2020-01-24 [1] CRAN (R 3.6.2)           
#>  processx      3.4.2      2020-02-09 [1] CRAN (R 3.6.2)           
#>  ps            1.3.2      2020-02-13 [1] CRAN (R 3.6.2)           
#>  R6            2.4.1.9000 2020-01-21 [1] Github (r-lib/R6@8e0b318)
#>  Rcpp          1.0.4      2020-03-17 [1] CRAN (R 3.6.3)           
#>  remotes       2.1.1      2020-02-15 [1] CRAN (R 3.6.3)           
#>  rgdal         1.4-8      2019-11-27 [1] CRAN (R 3.6.2)           
#>  rlang         0.4.5      2020-03-01 [1] CRAN (R 3.6.3)           
#>  rmarkdown     2.1        2020-01-20 [1] CRAN (R 3.6.2)           
#>  rprojroot     1.3-2      2018-01-03 [1] CRAN (R 3.6.0)           
#>  sessioninfo   1.1.1      2018-11-05 [1] CRAN (R 3.6.0)           
#>  sp            1.4-1      2020-02-28 [1] CRAN (R 3.6.3)           
#>  stringi       1.4.6      2020-02-17 [1] CRAN (R 3.6.3)           
#>  stringr       1.4.0      2019-02-10 [1] CRAN (R 3.6.0)           
#>  testthat      2.3.2      2020-03-02 [1] CRAN (R 3.6.3)           
#>  usethis       1.5.1      2019-07-04 [1] CRAN (R 3.6.1)           
#>  withr         2.1.2      2018-03-15 [1] CRAN (R 3.6.0)           
#>  xfun          0.12       2020-01-13 [1] CRAN (R 3.6.2)           
#>  yaml          2.2.1      2020-02-01 [1] CRAN (R 3.6.2)           
#> 
#> [1] /home/elio/R/x86_64-pc-linux-gnu-library/3.6
#> [2] /usr/local/lib/R/site-library
#> [3] /usr/lib/R/site-library
#> [4] /usr/lib/R/library

rsbivand · 2020-03-24T22:16:25Z

Windows!= Ubuntu. Please report the output of the startup messages when you execute library(rgdal). The specific versions of PROJ and GDAL matter, and how you installed them and rgdal itself. Please run debug(sp::CRS) and see where the branches go, and report back. Most combinations of versions of sp, rgdal, PROJ and GDAL have been tested without error, but not GDAL 3 and PROJ 5 which is not sensible. Roger Bivand Falsensvei 32 5063 Bergen tir. 24. mar. 2020, 23.02 skrev Elio Campitelli <notifications@github.com>:

…

I'm having a perhaps related issue. Using sp::CRS() crashes with strange errors (probably at the C level, but I don't know enough to be sure) but only when knitting! This is running with reprex: proj <- sp::CRS("+proj=longlat +datum=WGS84") proj #> CRS arguments: #> +proj=longlat +datum=WGS84 +ellps=WGS84 +towgs84=0,0,0 Created on 2020-03-24 by the reprex package <https://reprex.tidyverse.org> (v0.3.0) But if I try to knit this document --- title: "Untitled" output: html_document --- ```{r} proj <- sp::CRS("+proj=longlat +datum=WGS84") proj ``` I get. munmap_chunk(): invalid pointer. Strangely, if I remove the last line ("proj"), then I get a different error: double free or corruption (out). Another error I get is free(): invalid pointer. It seems that adding or removing valid R code around proj <- sp::CRS("+proj=longlat +datum=WGS84") changes the error slightly, but it always fails. I'm on Ubuntu 64bits and using the latest sp package from CRAN (version 1.4-1) Session info devtools::session_info() #> ─ Session info ─────────────────────────────────────────────────────────────── #> setting value #> version R version 3.6.3 (2020-02-29) #> os elementary OS 5.1.2 Hera #> system x86_64, linux-gnu #> ui X11 #> language en_US #> collate en_US.UTF-8 #> ctype en_US.UTF-8 #> tz America/Argentina/Buenos_Aires #> date 2020-03-24 #> #> ─ Packages ─────────────────────────────────────────────────────────────────── #> package * version date lib source #> assertthat 0.2.1 2019-03-21 [1] CRAN (R 3.6.0) #> backports 1.1.5 2019-10-02 [1] CRAN (R 3.6.1) #> callr 3.4.2 2020-02-12 [1] CRAN (R 3.6.2) #> cli 2.0.2 2020-02-28 [1] CRAN (R 3.6.3) #> crayon 1.3.4 2017-09-16 [1] CRAN (R 3.6.2) #> desc 1.2.0 2018-05-01 [1] CRAN (R 3.6.0) #> devtools 2.2.2 2020-02-17 [1] CRAN (R 3.6.3) #> digest 0.6.25 2020-02-23 [1] CRAN (R 3.6.3) #> ellipsis 0.3.0 2019-09-20 [1] CRAN (R 3.6.1) #> evaluate 0.14 2019-05-28 [1] CRAN (R 3.6.0) #> fansi 0.4.1 2020-01-08 [1] CRAN (R 3.6.2) #> fs 1.3.2 2020-03-05 [1] CRAN (R 3.6.3) #> glue 1.3.2 2020-03-12 [1] CRAN (R 3.6.3) #> highr 0.8 2019-03-20 [1] CRAN (R 3.6.0) #> htmltools 0.4.0 2019-10-04 [1] CRAN (R 3.6.1) #> knitr 1.28 2020-02-06 [1] CRAN (R 3.6.2) #> lattice 0.20-40 2020-02-19 [4] CRAN (R 3.6.2) #> magrittr 1.5 2014-11-22 [1] CRAN (R 3.6.0) #> memoise 1.1.0 2017-04-21 [1] CRAN (R 3.6.0) #> pkgbuild 1.0.6 2019-10-09 [1] CRAN (R 3.6.2) #> pkgload 1.0.2 2018-10-29 [1] CRAN (R 3.6.0) #> prettyunits 1.1.1 2020-01-24 [1] CRAN (R 3.6.2) #> processx 3.4.2 2020-02-09 [1] CRAN (R 3.6.2) #> ps 1.3.2 2020-02-13 [1] CRAN (R 3.6.2) #> R6 2.4.1.9000 2020-01-21 [1] Github ***@***.***) #> Rcpp 1.0.4 2020-03-17 [1] CRAN (R 3.6.3) #> remotes 2.1.1 2020-02-15 [1] CRAN (R 3.6.3) #> rgdal 1.4-8 2019-11-27 [1] CRAN (R 3.6.2) #> rlang 0.4.5 2020-03-01 [1] CRAN (R 3.6.3) #> rmarkdown 2.1 2020-01-20 [1] CRAN (R 3.6.2) #> rprojroot 1.3-2 2018-01-03 [1] CRAN (R 3.6.0) #> sessioninfo 1.1.1 2018-11-05 [1] CRAN (R 3.6.0) #> sp 1.4-1 2020-02-28 [1] CRAN (R 3.6.3) #> stringi 1.4.6 2020-02-17 [1] CRAN (R 3.6.3) #> stringr 1.4.0 2019-02-10 [1] CRAN (R 3.6.0) #> testthat 2.3.2 2020-03-02 [1] CRAN (R 3.6.3) #> usethis 1.5.1 2019-07-04 [1] CRAN (R 3.6.1) #> withr 2.1.2 2018-03-15 [1] CRAN (R 3.6.0) #> xfun 0.12 2020-01-13 [1] CRAN (R 3.6.2) #> yaml 2.2.1 2020-02-01 [1] CRAN (R 3.6.2) #> #> [1] /home/elio/R/x86_64-pc-linux-gnu-library/3.6 #> [2] /usr/local/lib/R/site-library #> [3] /usr/lib/R/site-library #> [4] /usr/lib/R/library — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNZ3BF4FTQAUMVZNBYISGDRJEUY3ANCNFSM4LARTCIQ> .

Jean-Romain · 2020-03-24T22:22:04Z

I believed it was to an update of either rmarkdown itself or a lib it depends on. But @eliocamp is right rmarkdown works well. The fails is somehow related to sp or rgdal. You should open a new issue.

library(rgdal)
rgdal: version: 1.4-8, (SVN revision 845)
 Geospatial Data Abstraction Library extensions to R successfully loaded
 Loaded GDAL runtime: GDAL 3.0.4, released 2020/01/28
 Path to GDAL shared files: 
 GDAL binary built with GEOS: TRUE 
 Loaded PROJ.4 runtime: Rel. 6.2.1, November 1st, 2019, [PJ_VERSION: 621]
 Path to PROJ.4 shared files: (autodetected)
 Linking to sp version: 1.3-2

Jean-Romain · 2020-03-24T22:25:55Z

It affects roxygen as well.

eliocamp · 2020-03-24T22:26:06Z

Here's the result from library(rgdal)

> library(rgdal)
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.4, released 2020/01/28
 Path to GDAL shared files: 
 GDAL binary built with GEOS: TRUE 
 Loaded PROJ.4 runtime: Rel. 6.2.1, November 1st, 2019, [PJ_VERSION: 621]
 Path to PROJ.4 shared files: (autodetected)
 Linking to sp version: 1.3-2

Running with debug didn't shine much light into the issue because when run outside markdown, it all works well.

rsbivand · 2020-03-24T22:32:48Z

Try reinstalling rgdal, it was built against an earlier sp (should not help). Then try *install.packages("rgdal", repos="http://R-Forge.R-project.org <http://R-Forge.R-project.org>")* *to try the development version. This will upset your work just like sf 0.9-0, just on CRAN, and also using PROJ 6.* Roger Bivand Falsensvei 32 5063 Bergen tir. 24. mar. 2020, 23.26 skrev Elio Campitelli <notifications@github.com>:

…

Here's the result from library(rgdal) > library(rgdal) 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.4, released 2020/01/28 Path to GDAL shared files: GDAL binary built with GEOS: TRUE Loaded PROJ.4 runtime: Rel. 6.2.1, November 1st, 2019, [PJ_VERSION: 621] Path to PROJ.4 shared files: (autodetected) Linking to sp version: 1.3-2 Running with debug didn't shine much light into the issue because when run outside markdown, it all works well. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNZ3BFRGFFDO6UDC2I3MGDRJEXQZANCNFSM4LARTCIQ> .

eliocamp · 2020-03-24T22:35:55Z

Reinstalling rgdal (with the usual install.packages from CRAN) fixed it!
That was very weird.

rsbivand · 2020-03-24T22:48:45Z

Thanks. I think you've found a(nother) logic bug in sp 1.4-*, that of rgdal being stale, I'll check tomorrow. Good that re-installing helped. Roger Bivand Falsensvei 32 5063 Bergen tir. 24. mar. 2020, 23.36 skrev Elio Campitelli <notifications@github.com>:

…

Reinstalling rgdal (with the usual install.packages from CRAN) fixed it! That was very weird. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#75 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACNZ3BDHQM5ZE6KWOUJJAYLRJEYVRANCNFSM4LARTCIQ> .

Jean-Romain · 2020-03-24T23:37:01Z

Everything looks good on my side as well. Thank you it was a very annoying trouble.

rsbivand mentioned this issue Mar 5, 2020

Raw LAS WKT seem not to render with projinfo OSGeo/PROJ#2022

Open

Jean-Romain mentioned this issue Mar 5, 2020

readLAS crashes when reading ALS las files, after previously working r-lidar/lidR#323

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

CRS() segfault on windows 64 bits #75

CRS() segfault on windows 64 bits #75

Jean-Romain commented Mar 3, 2020 •

edited

Loading

edzer commented Mar 3, 2020

Jean-Romain commented Mar 3, 2020

rsbivand commented Mar 3, 2020 via email

Jean-Romain commented Mar 3, 2020

rsbivand commented Mar 4, 2020

rsbivand commented Mar 4, 2020 •

edited

Loading

rsbivand commented Mar 4, 2020 •

edited

Loading

rsbivand commented Mar 4, 2020

Jean-Romain commented Mar 4, 2020 •

edited

Loading

rsbivand commented Mar 4, 2020

edzer commented Mar 4, 2020

Jean-Romain commented Mar 4, 2020 •

edited

Loading

rsbivand commented Mar 5, 2020 •

edited

Loading

eliocamp commented Mar 24, 2020

rsbivand commented Mar 24, 2020 via email

Jean-Romain commented Mar 24, 2020

Jean-Romain commented Mar 24, 2020

eliocamp commented Mar 24, 2020

rsbivand commented Mar 24, 2020 via email

eliocamp commented Mar 24, 2020

rsbivand commented Mar 24, 2020 via email

Jean-Romain commented Mar 24, 2020

CRS() segfault on windows 64 bits #75

CRS() segfault on windows 64 bits #75

Comments

Jean-Romain commented Mar 3, 2020 • edited Loading

edzer commented Mar 3, 2020

Jean-Romain commented Mar 3, 2020

rsbivand commented Mar 3, 2020 via email

Jean-Romain commented Mar 3, 2020

rsbivand commented Mar 4, 2020

rsbivand commented Mar 4, 2020 • edited Loading

rsbivand commented Mar 4, 2020 • edited Loading

rsbivand commented Mar 4, 2020

Jean-Romain commented Mar 4, 2020 • edited Loading

rsbivand commented Mar 4, 2020

edzer commented Mar 4, 2020

Jean-Romain commented Mar 4, 2020 • edited Loading

rsbivand commented Mar 5, 2020 • edited Loading

eliocamp commented Mar 24, 2020

rsbivand commented Mar 24, 2020 via email

Jean-Romain commented Mar 24, 2020

Jean-Romain commented Mar 24, 2020

eliocamp commented Mar 24, 2020

rsbivand commented Mar 24, 2020 via email

eliocamp commented Mar 24, 2020

rsbivand commented Mar 24, 2020 via email

Jean-Romain commented Mar 24, 2020

Jean-Romain commented Mar 3, 2020 •

edited

Loading

rsbivand commented Mar 4, 2020 •

edited

Loading

rsbivand commented Mar 4, 2020 •

edited

Loading

Jean-Romain commented Mar 4, 2020 •

edited

Loading

Jean-Romain commented Mar 4, 2020 •

edited

Loading

rsbivand commented Mar 5, 2020 •

edited

Loading