Raster layer with a remote COG fails to load
wonder-sk opened this issue · 1 comments
wonder-sk commented
When using a QGIS project that contains a cloud-optimized GeoTIFF (COG) on a remote server, it fails with a runtime error:
qgis-js.wasm:0x4792c6f Uncaught (in promise) RuntimeError: memory access out of bounds
at strlen (qgis-js.wasm:0x4792c6f)
at std::__2::basic_string<char, std::__2::char_traits<char>, std::__2::allocator<char>>::basic_string[abi:v15006]<std::nullptr_t>(char const*) (qgis-js.wasm:0x932371)
at CPLString::CPLString(char const*) (qgis-js.wasm:0x23aeac1)
at cpl::VSICurlHandle::GetFileSizeOrHeaders(bool, bool) (qgis-js.wasm:0x242d5d3)
at cpl::VSICurlHandle::GetFileSize(bool) (qgis-js.wasm:0x244222a)
at cpl::VSICurlHandle::Exists(bool) (qgis-js.wasm:0x242f73e)
at cpl::VSICurlFilesystemHandlerBase::Stat(char const*, stat*, int) (qgis-js.wasm:0x243cb26)
at VSIStatExL (qgis-js.wasm:0x23e16c8)
at GDALOpenInfo::GDALOpenInfo(char const*, int, char const* const*) (qgis-js.wasm:0x3d7e2c7)
at GDALOpenEx (qgis-js.wasm:0x3db2ab9)
We are using our custom implementation of /vsicurl
that uses emscripten's fetch API to do the requests.
It is strange that it crashes on some string construction. In the gdal sandbox this works fine (https://github.com/wonder-sk/wasm-gdal-sandbox), but the whole test case there runs in a worker thread because of the blocking networking calls.
wonder-sk commented
Probably because of this call:
const char *pszEffectiveURL = fetch->url; // URL may change after redirect
where url is likely nullptr.... (when fetch is called on the main thread -> it immediately fails)