[gdal-dev] GDAL 1.10 JP2000 Problem/Crash

[Johan Hedin]

Hi everyone,

I have seen crashes in libecwj2 when reading certain JPG2000 files as
well (on Linux). I have tracked it down to the bundled XML-handling
code in libecwj2 but have not had time to fully investigate.

But what I found was that if I turn off optimization when compiling
libecwj2 this bug can be avoided. Basically you just pass -O0 and you
are all set. Assuming that you are on Linux.

I have written a small note about this in the ECW wikipage on
osgeo.org: http://trac.osgeo.org/gdal/wiki/ECW.

If I get time to dig more into this I will update the wiki and post my
findings on the list.

I'm dependent on the 3.3 SDK as well and with all the fixes that are
mentioned on the wiki page above I think the the 3.3 SDK is working
quite well on Linux and that it should be possible to maintain it at
least for the foreseeable future.

Regards
Johan


2013/5/23 John Daniel <jdaniel at usgs.gov>:
> On May 23, 2013, at 12:37 PM, Frank Warmerdam <warmerdam at pobox.com> wrote:
>
> John,
>
> In my experience the crashes with the ECW 3.3 library are not specific to
> recent versions of GDAL.  I've run into them over the years.
>
>
> Frank,
> I was just curious about potential future problems with GDAL 1.10. If ECW
> runs as well, or as poorly, as it does with GDAL 1.9.2, then I'm happy.
>
> Why does the direct use of the app directory object files concern you?  I
> can't recall exactly why it is setup that way.  It seems to me I once tried
> to use the library for the apps area but it was missing something I needed.
> It seems the current arrangement is just a bit ackward but hopefully not a
> serious barrier for Kakadu licensees.
>
>
> Because changing the interface to the shared library is a big deal. Kakadu
> isn't going to do that without good reason and clear documentation on how to
> handle it. Our relatively recent Kakadu 7.1 library does just that and
> requires a minor patch to GDAL 1.9.2. However, Kakadu can change its
> internal code at any time and would be under no expectation to tell anyone
> or explain the changes.
>
> We are experiencing this exact problem with libXML. Our old version was
> using undocumented internals of libz. When the sysadmins updated libz for
> someone else's requirements, any application that used libXML, including
> GDAL, ceased to function. We still don't have all of our servers
> operational. We move slowly around here.
>
> We also had trouble building Kakadu so that its object files were compatible
> with GDAL. Now we also have a patch for Kakadu to add -fPIC for apps.
>
> I have no expectation that ECW 3.3 will continue to function in the future.
> It already doesn't work on our Solaris machines and needs patches for my
> Mac. Kakadu is well supported so I'm not worried about that. But I am a bit
> worried about direct linking to object files in a proprietary and very
> expensive library. There is potential for a future problem there.
>
> John Daniel
> Software Engineer
> Stinger Ghaffarian Technologies (SGT, Inc.)
> Contractor to the U.S. Geological Survey (USGS)
> Earth Resources Observation and Science (EROS) Center
> 47914 252nd Street
> Sioux Falls, South Dakota 57198
> Phone: 905.240.2953
> Mobile: 905.442.9385
> Skype: 303.586.1987
> Email: jdaniel at usgs.gov
>
>
>
>
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev