[gdal-dev] Kakadu 7.10 (7_A)

[Even Rouault]

Philippe,

> 
> We have been using Kakadu thanks to GDAL plugin for quite a while. A few
> weeks ago, I tried to upgrade to Kakadu V7.9.1 (from V7.7.7).
> Our development environment is :
> * Windows 8 64 bits,
> * Visual Studio 2015
> * GDAL V2.2.1
> 
> I bumped into a segmentation fault when converting a TIFF image to JP2K
> (gdal_translate). This error happens in JP2KAKDataset::~JP2KAKDataset(), on
> line :
> delete poInput. It does not occur with Kakadu V7.7.7.

Looking quickly to your message and the code, poInput is assigned from jp2_src = new 
jp2_source; and the deletion is delete poInput, so the GDAL heap is used for both 
construction and destruction, which is a good thing. So potential cross-heap issues are not 
linked to that object. But if you really use the same compiler and compiler settings to build 
GDAL and Kakadu, you shouldn't run into cross-heap issues.

> 
> I opened a discussion with Kakadu support
> (https://groups.yahoo.com/neo/groups/kakadu_jpeg2000/conversations/topics/73
> 69). I tried the different hints David Taubman gave me, without success.

You mentionned you tried with a debug build of GDAL. Are you aware that DEBUG=1 passed 
to nmake.opt still uses the /MD flag instead of /MDd which is probably more expected ? (this 
is a known issue / debate. See
https://trac.osgeo.org/gdal/ticket/6384). So in case Kakadu uses /MDd for debug builds, you 
definitely have an issue here and should modify nmake.opt line 135 to use /MDd.

Are you aware of http://www.drmemory.org/ ? It is a kind of Valgrind for Windows and can 
perhaps help narrowing the issue. I think it used to work only for 32 bit processes, but 
according to http://drmemory.org/docs/page_prep.html , it should work with 64bit processes 
with the following limitation
"Currently, Dr. Memory does not yet support uninitialized read detection for 64-bit 
applications, so we recommend compiling your target application as 32-bit."


-- 
Spatialys - Geospatial professional services
http://www.spatialys.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170821/004978f6/attachment.html>