Gdal Java - GetDefaultHistogram causing core dump

[Vlad]

Trying to get the histogram from a sample NITF.  Running from the command line, gdalinfo -hist, I get this...

Band 1 Block=512x512 Type=Byte, ColorInterp=Undefined
0ERROR 1: COMRAT=4.50 ARIDPCM is not supported.
Currently only 0.75 is supported.
ERROR 1: U_0001A.NTF, band 1: IReadBlock failed at X offset 0, Y offset 0

In Java code (Gdal 2.1 from Maven against a Windows Gdal installation), this line...

 int status = band.GetDefaultHistogram(dfMin, dfMax, panHistogram, true);

causes a dump...

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  EXCEPTION_ACCESS_VIOLATION (0xc0000005) at pc=0x0000000078f7c1b0, pid=2240, tid=3296
#
# JRE version: Java(TM) SE Runtime Environment (8.0_71-b15) (build 1.8.0_71-b15)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.71-b15 mixed mode windows-amd64 compressed oops)
# Problematic frame:
# C  [msvcr100.dll+0x3c1b0]ERROR 1: COMRAT=4.50 ARIDPCM is not supported.
Currently only 0.75 is supported.
ERROR 1: B:\data\raster\NITF\U_0001A.NTF, band 1: IReadBlock failed at X offset 0, Y offset 0

#
# Failed to write core dump. Minidumps are not enabled by default on client versions of Windows

With exceptions enabled, I get the same thing without the ERROR string and no exception is caught.

Culprit file is http://download.osgeo.org/gdal/data/nitf/nitf1.1/U_0001a.ntf 

So, I can't check the status return from GetDefaultHistogram, I can't catch an exception, and I think ARIDPCM is valid for NITF prior to 2.1, so I can't really exclude ARIDPCM compression.

Workarounds or bug?

[Even Rouault-2]

On vendredi 10 février 2017 07:32:34 CET Vlad wrote:

> Trying to get the histogram from a sample NITF. Running from the command

> line, gdalinfo -hist, I get this...

>

> Band 1 Block=512x512 Type=Byte, ColorInterp=Undefined

> 0ERROR 1: COMRAT=4.50 ARIDPCM is not supported.

> Currently only 0.75 is supported.

> ERROR 1: U_0001A.NTF, band 1: IReadBlock failed at X offset 0, Y offset 0

>

> In Java code (Gdal 2.1 from Maven against a Windows Gdal installation), this

> line...

>

> int status = band.GetDefaultHistogram(dfMin, dfMax, panHistogram, true);

>

> causes a dump...

 

Fixed per https://trac.osgeo.org/gdal/ticket/6811

 

You could workaround the issue by issuing first GetStatistics() and if an error is returned then don't call GetDefaultHistogram().

 

Regarding the 'COMRAT=4.50 ARIDPCM is not supported.' error, this is an implementation limitation. I'm curious to know if you need this for real datasets, or if you just tried on the NITF test files ?

 

Even

 

--

Spatialys - Geospatial professional services

http://www.spatialys.com

_______________________________________________
gdal-dev mailing list
[hidden email]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[Vlad]

Hi Even:
As always thanks for your prompt reply.

I don't "think" we'll ever encounter one of these in our production datasets, this one was in my test suite, that is how I ran into it.  

Though unlikely on the production system, I can't afford a core dump, so I'll put in the statistics test in the meantime.

Thanks again.