[Gdal-dev] ECW Hanging

[Tamas Szekeres]

Steve,

As far as I remember there have been a couple of mysterius problems with the
ECW SDK interfacing with gdal and mapserver which haven't yet been solved,
and the current ms4w distribution doesn't even include ECW support because
of such reason.

I have an impression that many of these issues could be better investigated
by compiling the ECW SDK in debug mode. Once the application is hanging you
may attach a debugger and inspect the call stack for each thread which would
probably help in localizing the problem.

Compiling the SDK in debug mode is pretty straightforward which is included
as an option in the Visual Studio solution (in Source\NCSBuildQmake).
If you have this debug version then you could recompile gdal easily by using
the corresponding build package available from here:
http://vbkto.dyndns.org/sdk/

You may also inspect the precompiled packages from the location above which
all provided with the ECW plugin to test with.

Unfortunately it seems like these problems are falling pretty much out of
scope of our current activities in gdal to spend much time in debugging into
external libraries like ECW and fix their problems externally. If you feel
enough willingness to do so, we greatly accept any contribution to improve
our gdal binary distributions.


Best regards,

Tamas





2010/1/8 srweal <srweal at gmail.com>

>
> Hi,
>
> I'm experiencing intermittent problems running the FWTools 2.2.6 version of
> GDAL, including ECW support.
>
> I'm using the library to render maps (or map tiles) produced using the
> SharpMap library, an open-source mapping library written in C#.NET.
> SharpMap access the standard GDAL operations via a wrapper, but this is not
> where the problem lies.
>
> I am rendering the ECW maps/tiles out through a web application running
> under IIS6.0 and this works fine most of the time, but there are times when
> the ECW library hangs.
>
> I've identified this using Process Monitor, which shows that when all is
> going well and the ECW files are being read, the calls to GDAL run an
> IRP_MJ_CREATE operation on the system kernel to open the files
> NCSUtil_fw.dll, NCSEcw_fw.dll.  Then the process seems to read from the
> source ECW using gdal_fw.dll.
>
> However, when the rendering hangs and I investigate Process Monitor, all
> that gets listed is a 'Thread Create' which runs NCSUtil_fw.dll.  There is
> no subsequent references to NCSEcw_fw.dll, gdal_fw.dll or anything similar.
> Instead, this thread stays open and every 40 seconds there are other
> threads
> opened and then closed that just refer to main kernel files (i.e. no ECW
> references in them).  This hangs indefinitely, which in turn causes my web
> apps to hang (and because no error gets thrown or the process is completely
> inactive, automatically rebooting them is tricky).
>
> I'm trying to understand what is happening when this occurs and would
> appreciate some further guidance on what the issue might be here and a
> potential way around it.  I had thought it was an issue with using a 64bit
> operating system, but have moved all my applications onto 32bit and have
> just discovered this problem is still occurring (but not as frequently as
> on
> the 64bit system).
>
> I would love to hear from anyone who's had issues with the ECW library in a
> similar way and got around them (or avoided them somehow).  Unfortunately,
> due to file sizes, other file formats like TIF are not feasible.
>
> Thanks, Steve
> --
> View this message in context:
> http://n2.nabble.com/ECW-Hanging-tp4270724p4270724.html
> Sent from the GDAL - Dev mailing list archive at Nabble.com.
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20100108/0cc93cfb/attachment.html