crash when accessing dataset opened via the driver object

[mmomtchev]

console.log(dataset.driver.open('file.tiff', undefined));

will produce a segmentation fault which I traced to gdal_dataset.cpp:722

  if (raw->GetDriver() == nullptr  || !raw->GetDriver()->GetMetadataItem(GDAL_DCAP_RASTER)) {
    info.GetReturnValue().Set(Nan::Null());
    return;
  }

I "fixed" it by checking for nullptr, but it shouldn't happen, there must be an initialization missing somewhere

[mmomtchev]

According to the discussion on gdal-dev list (@rouault), this stems from us not being supposed to call GDALDriver->pfnOpen directly The problem is that there is no official GDAL entry point for constructing a GDALDataset at the GDALDriver level In fact, that open does not belong there at all We are supposed to construct GDALDataset by GDALOpen(ex) only which is at the main level And if we want to pass a list of drivers (or one driver as in this case), we must know its name In node-gdal a driver doesn't know his own name

There are only bad solutions to this problem

• masking the null pointer and keeping the current pfnOpen call
• carrying the driver name in some new structure
• carrying the driver name in the JS object

[rouault]

In node-gdal a driver doesn't know his own name

if you're able to do poDriver->pfnOpen, you can know the name of the driver with poDriver->GetDescription(), and that's the one to pass to the list of allowed drivers of GDALOpenEx()

[mmomtchev]

@rouault no solution for GDAL 1.x?

[rouault]

GDAL 1.x?

GDAL 1.x !!!!! Are you joking :-) ? Degraded mode: just use GDALOpen() then and ignores that the user has specified a driver.

[mmomtchev]

Ok, I swept the GDAL 1.x **** under the carpet, the nullptr is still there, but Node won't crash anymore, its just that certain fields of the dataset will be undefined when read from JS

[yocontra]

PR merged

[rouault]

actually while thinking about that later, for GDAL 1, you could manually set the poDriver member to the driver... That's just what GDALOpen() does.