Hi Tom,
please file an issue at https://github.com/OSGeo/gdal/issues with your
reproducer snippet
Even
Le 17/07/2025 à 02:28, Tom Moore a écrit :
Hi Evan
I seem to still be having problems closing datasets in Java resulting
in a JVM crash, using gdal-3-13-3_x64 downloaded from the GISInternals
site. Below is the stack trace information.
--------------- T H R E A D ---------------
Current thread (0x000001ffd39932c0): JavaThread "Finalizer" daemon
[_thread_in_native, id=25140,
stack(0x000000ba6eb00000,0x000000ba6ec00000) (1024K)]
Stack: [0x000000ba6eb00000,0x000000ba6ec00000],
sp=0x000000ba6ebfed60, free space=1019k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code,
C=native code)
C [gdal.dll+0xc86927]
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
j org.gdal.gdal.gdalJNI.delete_Dataset(J)V+0
j org.gdal.gdal.Dataset.delete()V+25
j org.gdal.gdal.Dataset.finalize()V+1
j java.lang.System$2.invokeFinalize(Ljava/lang/Object;)V+1
java.base@21.0.6
j
java.lang.ref.Finalizer.runFinalizer(Ljdk/internal/access/JavaLangAccess;)V+115
java.base@21.0.6
j java.lang.ref.Finalizer$FinalizerThread.run()V+29 java.base@21.0.6
v ~StubRoutines::call_stub 0x000001ffa369100d
siginfo: EXCEPTION_ACCESS_VIOLATION (0xc0000005), reading address
0xffffffffffffffff
The crash is happening when the swig delete_Dataset method, called by
the finalizer, calls into the gdal.dll.
I tried calling Open() and Close() several times in a row to see if
this would trigger the problem, like this:
gdal./AllRegister/();
Dataset ds = gdal.Open(filename);
ds.Close();
ds.Close();
but that seemed to work ok.
I also tried open and close sequences, like this:
Dataset ds = gdal.Open(filename);
ds.Close();
ds = gdal.Open(filename);
ds.Close();
ds = gdal.Open(filename);
System.gc();
System.runFinalization();
This didn't trigger a problem either. I did a few more tests,
repeating steps of opening a dataset, reading a band, closing the
dataset, and this didn't do it either.
If I enable CPL_DEBUG then my pattern of access that causes the crash is:
GDAL:
GDALDriver::Create(GTiff,c:/tmp/test1.tif,10,10,1,Int32,000001BCB9893680)
GDAL: GDALClose(c:/tmp/test1.tif, this=000001BCB9872A90)
GDAL: GDALOpen(c:/tmp/test1.tif, this=000001BCB98784D0) succeeds as GTiff.
GDAL: GDALClose(c:/tmp/test1.tif, this=000001BCB98784D0)
GDAL: GDALOpen(c:/tmp/test1.tif, this=000001BCBE486550) succeeds as GTiff.
GDAL: GDALOpen(c:/tmp/test1.tif.vat.dbf, this=000001BCBE10D070)
succeeds as ESRI Shapefile.
GDAL: GDALClose(c:/tmp/test1.tif.vat.dbf, this=000001BCBE10D070)
GDAL: GDALClose(c:/tmp/test1.tif, this=000001BCBE486550)
Around this point the finalizer kicks in and the JVM crashes.
This is a hard one for me to track down, because I don't know the
tooling to debug native cpp code from within Java. What I could do is
insert some debugging statements in to the code to try to see what is
going on. If you have any suggestions about this I would be happy to
try it.
Tom
On Fri, May 30, 2025, at 5:53 PM, Even Rouault wrote:
Le 30/05/2025 à 23:39, Tom Moore a écrit :
> Hi Even
>
> I just wanted to update you and provide a record for posterity with
> the results of me playing around with gdal/java and resource
management.
>
> It appears to me that Dataset objects should not be closed from Java
> client code. If you do then often there will be an access violation
> (native null pointer) that will crash the JVM. From the dump file the
> following stack trace shows the Java code being executed when the
> exception occurs:
I believe this issue should be fixed in 3.11.0 per
https://github.com/OSGeo/gdal/commit/ec4ca7930b48653bb0fac27b59c6c1bf883c45f2
Actually historically this was the .delete() method that should be
called. The exposition of .Close() is quite recent and was broken (until
the above mentioned fix)
>
> Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)
> j org.gdal.gdal.gdalJNI.delete_Dataset(J)V+0
> j org.gdal.gdal.Dataset.delete()V+25
> j org.gdal.gdal.Dataset.finalize()V+1
> j java.lang.System$2.invokeFinalize(Ljava/lang/Object;)V+1
> java.base@21.0.6
> j
>
java.lang.ref.Finalizer.runFinalizer(Ljdk/internal/access/JavaLangAccess;)V+115
> java.base@21.0.6
> j java.lang.ref.Finalizer$FinalizerThread.run()V+29 java.base@21.0.6
>
> So it looks like the swig bindings implement a finalizer to dispose of
> the native object when the reference is no longer reachable (nice!).
> However it looks like there might not be any protection to prevent bad
> things from happening when the Delete method is called more than
> once. It appears that in this case that when the finalizer calls
> Delete on the Dataset the jvm crashes because the Dataset has already
> been closed manually and the resources have already been released.
>
> If I am correct in this conclusions then this is not a problem. If
> correct I suggest that either the docs be updated to indicate do not
> manually call Delete on the Dataset object, or change the Delete
> method code to gracefully handle multiple calls (better choice).
>
> By the way, something to note for the future is that finalizers have
> been deprecated since Java 9 (2017). This is described in
> https://openjdk.org/jeps/421. Although deprecated, finalizers are
> still allowed in modern jdk's and probably will be for a while yet. At
> some future time they will be removed. The suggested replacement for
> finalizers are cleaners, but they are only available in Java 9+. When
> finalizers are removed there will need to be a new set of bindings
> that use cleaners. You can probably ignore this problem for a few
> more years, but at some point you will need to provide two sets of
> Java bindings (one required for Java 8 and earlier, and one required
> for some future Java and later).
Thanks for the heads up. Seizing the opportunity to remind interesting
parties in the GDAL Java bindings that they should not be shy and are
welcome to be proactive. On my side, they are very very minimilastically
maintained.
Even
--
http://www.spatialys.com
My software is free, but my time generally not.
--
Tom Moore
Spatial Planning Systems
960 Burkes Bluff Lane
Deep River ON K0J 1P0
Canada
Phone: +1 613 584 9354
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/gdal-dev
