[jira] [Assigned] (SIS-627) JVM crash if two or more `GDALStoreProvider` are created with explicit path to GDAL native library

["Martin Desruisseaux (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/SIS-627?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Martin Desruisseaux reassigned SIS-627:
---------------------------------------


> JVM crash if two or more `GDALStoreProvider` are created with explicit path to GDAL native library
> --------------------------------------------------------------------------------------------------
>
>                 Key: SIS-627
>                 URL: https://issues.apache.org/jira/browse/SIS-627
>             Project: Spatial Information Systems
>          Issue Type: Bug
>          Components: Storage
>    Affects Versions: 1.6
>            Reporter: Martin Desruisseaux
>            Assignee: Martin Desruisseaux
>            Priority: Major
>             Fix For: 1.7
>
>
> {{GDALStoreProvider}} has two constructors: a default constructor using the GDAL library found by the Operating System, and another constructor where the user can specify explicitly the path to the GDAL native library. Usually, only one {{GDALStoreProvier}} should be created in a JVM. But we do not forbid the creation of more instances. However, if two {{GDALStoreProvider}} are created for the same GDAL library, the C function {{GDALDestroy(void)}} is invoked when the first provider is garbage-collected, which causes a JVM crash when the second provider, which is still alive, invokes a GDAL function.
> The easiest fix is to ensure that we never have two instances of {{GDALStoreProvider}} for the same GDAL native library, where the library is identified by the inode of the {{libgdal.so}} file (or equivalent file on non-POSIX systems). If a second request is made for the same file, the existing provider shall be returned instead of returning a new one.
> This strategy requires that we remove the {{GDALStoreProvider(Path)}} constructor, replaced by a static method. This is an incompatible change, but avoiding a JVM crash is a reason good enough.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)