Segmentation fault when closing VRT dataset

[mzmcgrat]

Calling the close() method on a VRT dataset causes the process to crash with Segmentation fault (core dumped). Interestingly, if I open an existing VRT file and close it, it works fine, but this causes the crash every time for me:

let ds= gdal.open("in.tif")
let ds_vrt= gdal.translate("out.vrt", ds)
ds.close()
ds_vrt.close()	//Segmentation fault (core dumped)

$ gdalinfo in.tif
Driver: GTiff/GeoTIFF
Files: in.tif
Size is 872, 2981
Coordinate System is:
PROJCRS["NAD83 / UTM zone 17N",
    BASEGEOGCRS["NAD83",
        DATUM["North American Datum 1983",
            ELLIPSOID["GRS 1980",6378137,298.257222101,
                LENGTHUNIT["metre",1]]],
        PRIMEM["Greenwich",0,
            ANGLEUNIT["degree",0.0174532925199433]],
        ID["EPSG",4269]],
    CONVERSION["UTM zone 17N",
        METHOD["Transverse Mercator",
            ID["EPSG",9807]],
        PARAMETER["Latitude of natural origin",0,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8801]],
        PARAMETER["Longitude of natural origin",-81,
            ANGLEUNIT["degree",0.0174532925199433],
            ID["EPSG",8802]],
        PARAMETER["Scale factor at natural origin",0.9996,
            SCALEUNIT["unity",1],
            ID["EPSG",8805]],
        PARAMETER["False easting",500000,
            LENGTHUNIT["metre",1],
            ID["EPSG",8806]],
        PARAMETER["False northing",0,
            LENGTHUNIT["metre",1],
            ID["EPSG",8807]]],
    CS[Cartesian,2],
        AXIS["(E)",east,
            ORDER[1],
            LENGTHUNIT["metre",1]],
        AXIS["(N)",north,
            ORDER[2],
            LENGTHUNIT["metre",1]],
    USAGE[
        SCOPE["Engineering survey, topographic mapping."],
        AREA["North America - between 84°W and 78°W - onshore and offshore. Canada - Nunavut; Ontario; Quebec. United States (USA) - Florida; Georgia; Kentucky; Maryland; Michigan; New York; North Carolina; Ohio; Pennsylvania; South Carolina; Tennessee; Virginia; West Virginia."],
        BBOX[23.81,-84,84,-78]],
    ID["EPSG",26917]]
Data axis to CRS axis mapping: 1,2
Origin = (509494.535999999963678,3711162.504000000189990)
Pixel Size = (3.047999999999980,-3.047999999999980)
Metadata:
  AREA_OR_POINT=Area
Image Structure Metadata:
  COMPRESSION=LZW
  INTERLEAVE=BAND
Corner Coordinates:
Upper Left  (  509494.536, 3711162.504) ( 80d53'51.85"W, 33d32'24.12"N)
Lower Left  (  509494.536, 3702076.416) ( 80d53'52.19"W, 33d27'29.09"N)
Upper Right (  512152.392, 3711162.504) ( 80d52' 8.79"W, 33d32'24.03"N)
Lower Right (  512152.392, 3702076.416) ( 80d52' 9.23"W, 33d27'29.00"N)
Center      (  510823.464, 3706619.460) ( 80d53' 0.51"W, 33d29'56.56"N)
Band 1 Block=256x256 Type=Float64, ColorInterp=Gray
  NoData Value=-9999

The VRT file is created seemingly correctly:

<VRTDataset rasterXSize="872" rasterYSize="2981">
  <SRS dataAxisToSRSAxisMapping="1,2">PROJCS["NAD83 / UTM zone 17N",GEOGCS["NAD83",DATUM["North_American_Datum_1983",SPHEROID["GRS 1980",6378137,298.257222101,AUTHORITY["EPSG","7019"]],AUTHORITY["EPSG","6269"]],PRIMEM["Greenwich",0,AUTHORITY["EPSG","8901"]],UNIT["degree",0.0174532925199433,AUTHORITY["EPSG","9122"]],AUTHORITY["EPSG","4269"]],PROJECTION["Transverse_Mercator"],PARAMETER["latitude_of_origin",0],PARAMETER["central_meridian",-81],PARAMETER["scale_factor",0.9996],PARAMETER["false_easting",500000],PARAMETER["false_northing",0],UNIT["metre",1,AUTHORITY["EPSG","9001"]],AXIS["Easting",EAST],AXIS["Northing",NORTH],AUTHORITY["EPSG","26917"]]</SRS>
  <GeoTransform>  5.0949453599999996e+05,  3.0479999999999796e+00,  0.0000000000000000e+00,  3.7111625040000002e+06,  0.0000000000000000e+00, -3.0479999999999796e+00</GeoTransform>
  <Metadata>
    <MDI key="AREA_OR_POINT">Area</MDI>
  </Metadata>
  <Metadata domain="IMAGE_STRUCTURE">
    <MDI key="INTERLEAVE">BAND</MDI>
    <MDI key="COMPRESSION">LZW</MDI>
  </Metadata>
  <VRTRasterBand dataType="Float64" band="1" blockXSize="256" blockYSize="256">
    <NoDataValue>-9999</NoDataValue>
    <ColorInterp>Gray</ColorInterp>
    <SimpleSource>
      <SourceFilename relativeToVRT="1">in.tif</SourceFilename>
      <SourceBand>1</SourceBand>
      <SourceProperties RasterXSize="872" RasterYSize="2981" DataType="Float64" BlockXSize="256" BlockYSize="256" />
      <SrcRect xOff="0" yOff="0" xSize="872" ySize="2981" />
      <DstRect xOff="0" yOff="0" xSize="872" ySize="2981" />
    </SimpleSource>
  </VRTRasterBand>
</VRTDataset>

I am running the latest version of this library (3.11.3) and I can reproduce the error running on Debian 13.3.0 with node 20.19.2 and Ubuntu 24.04 with node 23.11.1. Running gdb node core.##### file and running a backtrace, I get:

(gdb) bt
#0  0x0000000000000000 in ?? ()
#1  0x00007f1abe8ae6c4 in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#2  0x00007f1abde60a4c in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#3  0x00007f1abe8ca86a in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#4  0x00007f1abe8c7916 in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#5  0x00007f1abe8c7c82 in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#6  0x00007f1abde63f42 in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#7  0x00007f1abdb51f3e in void node_gdal::ObjectStore::dispose<GDALDataset*>(std::shared_ptr<node_gdal::ObjectStoreItem<GDALDataset*> >, bool) ()
   from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#8  0x00007f1abdb4fead in node_gdal::ObjectStore::do_dispose(long, bool) () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#9  0x00007f1abdb521fd in node_gdal::ObjectStore::dispose(long, bool) () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#10 0x00007f1abdb7d167 in node_gdal::Dataset::dispose(bool) () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#11 0x00007f1abdb5f3c6 in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node

When I install this library using npm install gdal-async --build-from-source --shared_gdal with libgdal-dev and gdal-bin version 3.11.3 installed, I receive the following backtrace, which may be more helpful:

(gdb) bt
#0  0x00007f9300004e82 in ?? ()
#1  0x00007f93b2af3934 in VRTSourcedRasterBand::FlushCache(bool) () from /lib/x86_64-linux-gnu/libgdal.so.37
#2  0x00007f93b34bea34 in GDALDataset::FlushCache(bool) () from /lib/x86_64-linux-gnu/libgdal.so.37
#3  0x00007f93b2b1fc3c in VRTDataset::FlushCache(bool) () from /lib/x86_64-linux-gnu/libgdal.so.37
#4  0x00007f93b2b2da89 in VRTDataset::~VRTDataset() () from /lib/x86_64-linux-gnu/libgdal.so.37
#5  0x00007f93b2b2dd9d in VRTDataset::~VRTDataset() () from /lib/x86_64-linux-gnu/libgdal.so.37
#6  0x00007f93b34aa0bf in GDALClose () from /lib/x86_64-linux-gnu/libgdal.so.37
#7  0x00007f93b92b7cf7 in void node_gdal::ObjectStore::dispose<GDALDataset*>(std::shared_ptr<node_gdal::ObjectStoreItem<GDALDataset*> >, bool) () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#8  0x00007f93b92b598f in node_gdal::ObjectStore::do_dispose(long, bool) () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#9  0x00007f93b92b8001 in node_gdal::ObjectStore::dispose(long, bool) () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#10 0x00007f93b92e77eb in node_gdal::Dataset::dispose(bool) () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#11 0x00007f93b92c747d in ?? () from /app/node_modules/gdal-async/lib/binding/node-v131-linux-x64/gdal.node
#12 0x00007f93dbc0f186 in ?? ()
#13 0x0000000000000022 in ?? ()
#14 0x00007ffd7eb04ea0 in ?? ()
#15 0x00007ffd7eb04ed8 in ?? ()
#16 0x0000000000000000 in ?? ()

I am not familiar with the GNU Debugger tool, so my investigation stopped there. Any insight would be appreciated.

[mmomtchev]

Can you upload the TIFF file somewhere?

[mzmcgrat]

The content and georeferencing of the original TIFF file could be considered sensitive, but I encounter the crash with every one I've tried. Here's a different simple file that I tested:

in.tif

[mmomtchev]

I do not reproduce the crash with the builtin GDAL. Do you get it with the builtin GDAL or only with the external GDAL?

Tried both macOS and Linux.

[mzmcgrat]

I experience the crash using both the builtin GDAL and external GDAL. Additionally, I am able to reproduce the crash in a fresh Docker container running Ubuntu 22.04 with node 22.18.0 as well as on a separate Windows 10 machine running node 22.11.0, both using the builtin GDAL that comes from the default npm i gdal-async.

[mmomtchev]

Can you make a Dockerfile that reproduces the crash?

[mzmcgrat]

Dockerfile

FROM ubuntu:22.04

RUN apt-get update && apt-get install -y curl

RUN curl -fsSL https://deb.nodesource.com/setup_22.x | bash - && apt-get install -y nodejs

WORKDIR /app

COPY package.json .

RUN npm install

COPY index.mjs in.tif .

# Change to this to run a terminal instead
#  CMD ["/bin/bash"]
CMD ["node", "index.mjs"]

package.json

{
  "name": "test_vrt_segfault",
  "version": "1.0.0",
  "main": "index.js",
  "scripts": {
    "test": "echo \"Error: no test specified\" && exit 1"
  },
  "author": "",
  "license": "ISC",
  "description": "",
  "dependencies": {
    "gdal-async": "^3.11.3"
  }
}

index.mjs

import gdal from 'gdal-async'

console.log(gdal.version)

let ds= gdal.open("in.tif")
let ds_vrt= gdal.translate("out.vrt", ds)
ds.close()
ds_vrt.close()	//Segmentation fault (core dumped)

console.log("Doesn't get to here")

Build Docker image in directory with Dockerfile, in.tif, package.json, and index.mjs

sudo docker build -t gdal-async-vrt-test .

Run container

sudo docker run --rm --workdir /app gdal-async-vrt-test

Run container with shell with modified Dockerfile

sudo docker run --rm -it --workdir /app gdal-async-vrt-test

It produces a core dump file inside the container, so if you want it written to your local directory, run

sudo docker run --rm -it -v $PWD:/app --workdir /app gdal-async-vrt-test

[mmomtchev]

As you may have seen from my profile, I am currently at the center of a huge sexually motivated extortion, involving the French police, judiciary, at the national and EU level, and the GIS sector. People are regularly posting simultaneously issues on my project in order to intimidate me. Yours is one of these.

[mmomtchev]

You close the parent dataset before closing the VRT dataset. As the VRT dataset is constructed around the parent dataset, they share the same underlying cache and this cache is no longer valid.

AFAIK, GDAL does not provide any mechanism for informing me that these datasets are related.

In theory, there is an API for these situations, consisting of GDALDataset::Reference and GDALDataset::Dereference but GDAL does not use it in this particular case.

This problem is present in all GDAL bindings for languages with automatic memory management.
It should be solved in GDAL first, but this is unlikely to happen because the C++ API of GDAL is not safe and it is not meant to be.

The only recommendation that I can make is to not close datasets that do not have to be flushed and to leave the JS GC to close them.