[gdal-dev] GDAL 1.7.3 java bindings on Centos 5 (64 bit)

[Even Rouault]

Le lundi 23 janvier 2012 18:12:14, Daniele Romagnoli a écrit :
> Hi list,
> Does anyone have any experience about the reported topic?
> 
> I have downloaded GDAL 1.7.3 on my Centos 5.7 (64) machine and built it
> (with only base drivers and with threads support).
> Utilities are working fine (gdalinfo, gdal_translate, ...)
> 
> Then, I have installed SWIG 1.3.36 (I know, it's quite old but testing
> 1.3.4X or 2.x in the past, I got several JVM crashes or other types of
> issues) and I have created java bindings for it.
> Once I have configured LD_LIBRARY_PATH to use all SOs it needs, I have
> started running some ImageIO-Ext tests with maven and JVM is crashing.
> 
> In case someone don't know it, ImageIO-Ext mainly allows to bridge Java's
> ImageIO (ImageReaders/writers/SPI) to GDAL format drivers.
> On several Ubuntu (8, 9, 10, 11) I never had similar problems. We regularly
> use ImageIO-Ext 1.1.2 built on top of GDAL 1.7.3 on projects like GeoTools,
> GeoServer, Udig, ... Therefore I guess it's not a problem on the
> ImageIO-Ext caller side. I think it could be related to the SWIG-JNI
> counterpart which isn't working properly or something odd with the memory
> usage.
> 
> Does anyone have any feedback on this? (supported/never tested/won't
> work/need some CXX flags/... anything)
> I'm pasting the hs_err_pid Log in case you find anything interesting.
> [1]: http://pastebin.com/WQkfnutJ

Hi Daniele,

I've never used ImageIO-Ext myself. Looking at the traces, the problem arise 
in GetMetadata_List() (but this may be just a consequence of an issue 
elsewhere). Do you have a simple code and associate data that could be used to 
reproduce the problem ?

I've tested the following code :

import org.gdal.gdal.*;

public class testgetmetadatalist
{
    public static void main(String[] args)
    {
        gdal.AllRegister();
        Dataset ds = gdal.Open(args[0]);
        for(int i=0;i<1000;i++)
        {
            System.out.println(ds.GetMetadata_List());
            System.out.println(ds.GetMetadata_List("IMAGE_STRUCTURE"));
            System.out.println(ds.GetRasterBand(1).GetMetadata_List());
        }
    }
}

with 
http://trac.osgeo.org/gdal/export/23788/trunk/autotest/gcore/data/byte.tif and 
http://trac.osgeo.org/gdal/export/23788/trunk/autotest/gcore/data/byte.img

and it runs without any problem on my system (Ubuntu 10.04 64bit). I've only 
tested with GDAL trunk, but I'm not aware of significant fixes in the Java 
bindings since 1.7.3 that could explain a difference in behaviour.

I've run it under Valgrind too ( valgrind --trace-children=yes java -
Djava.library.path=. -cp gdal.jar:. testgetmetadatalist byte.tif), and didn't 
see anything alarming (you can see a bunch of warnings due to the JVM inner 
working, but nothing from GDAL code). You need Valgrind 3.6.1 at least AFAIR 
so that valgrind works correctly with a 64bit JVM.

Could you test that on your end ?

As far as swig version is concerned, I believe we have used 1.3.36 in the past 
so that shouldn't be a problem. Perhaps you could retry with 1.3.40 that is 
the one I use currently ?

Another track: perhaps you could try to recompile the lib*jni.so without the -
O2 flag and see if it makes a difference. There was at a time a problem with the 
swig generated code that has caused the  -fno-strict-aliasing to be added in 
swig/java/GNUmakefile and that has solved the problem (I've checked that the fix 
is well in 1.7.3), but perhaps there's something else with the compiler 
version you are using.

Best regards,

Even