[PATCH] ECW support on Linux (std::length_error exception) with GCC 4.7

[danitool]

I'm using Arch-Linux OS, some time ago gdal stopped working after some upgrades in my system (I don't know which upgrade was the culprit). This is the error when I try to open an ECW file:

[dani@tool ~]$ gdalinfo PNOA_MR_OF_ETRS89_HU29_h50_0185.ecw 
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create
Aborted
[dani@tool ~]$

I tried several ecw files, with the same result.

Gdal was built with ECW (3.3 SDK) support using a standard procedure as suggested in http://trac.osgeo.org/gdal/wiki/ECW Tools used for compiling all stuff are the latest ones. GCC version is 4.7.2.

Any suggestion to solve this problem would be appreciated.

[Even Rouault]

You should try to run gdalinfo under gdb and show the stacktrace when it crashes. It seems very likely that it crashes in the ECW SDK itself. This might be due to using a very recent GCC such as 4.7.2 whereas the ECW SDK code base is aging...

[danitool]

Ok, since I'm not an expert I can't debug this stuff, but here is the gdb info I was able to get:

(gdb) run
Starting program: /usr/bin/gdalinfo PNOA_MR_OF_ETRS89_HU29_h50_0185.ecw
warning: Could not load shared library symbols for linux-vdso.so.1.
Do you need "set solib-search-path" or "set sysroot"?
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/usr/lib/libthread_db.so.1".
terminate called after throwing an instance of 'std::length_error'
  what():  basic_string::_S_create

Program received signal SIGABRT, Aborted.
0x00007ffff6ae2fa5 in raise () from /usr/lib/libc.so.6
(gdb) info stack
#0  0x00007ffff6ae2fa5 in raise () from /usr/lib/libc.so.6
#1  0x00007ffff6ae4428 in abort () from /usr/lib/libc.so.6
#2  0x00007ffff2847e3d in __gnu_cxx::__verbose_terminate_handler() () from /usr/lib/libstdc++.so.6
#3  0x00007ffff2845f36 in ?? () from /usr/lib/libstdc++.so.6
#4  0x00007ffff2845f63 in std::terminate() () from /usr/lib/libstdc++.so.6
#5  0x00007ffff284618e in __cxa_throw () from /usr/lib/libstdc++.so.6
#6  0x00007ffff2898d7d in std::__throw_length_error(char const*) () from /usr/lib/libstdc++.so.6
#7  0x00007ffff28a3412 in std::string::_Rep::_S_create(unsigned long, unsigned long, std::allocator<char> const&) ()
   from /usr/lib/libstdc++.so.6
#8  0x00007ffff28a4168 in std::string::_Rep::_M_clone(std::allocator<char> const&, unsigned long) () from /usr/lib/libstdc++.so.6
#9  0x00007ffff28a4250 in std::string::reserve(unsigned long) () from /usr/lib/libstdc++.so.6
#10 0x00007ffff5ca2be9 in TiXmlDocument::LoadFile(char const*, TiXmlEncoding) () from /usr/lib/libNCSEcw.so.0
#11 0x00007ffff560b085 in CNCSPrefsXML::CNCSPrefsXML(CNCSString) () from /usr/lib/libNCSUtil.so.0
#12 0x00007ffff560b2f0 in CNCSPrefsXML::Init() () from /usr/lib/libNCSUtil.so.0
#13 0x00007ffff560f675 in NCSUtilInit () from /usr/lib/libNCSUtil.so.0
#14 0x00007ffff5cf5a4f in NCSecwInitInternal () from /usr/lib/libNCSEcw.so.0
#15 0x00007ffff72e2c79 in ECWInitialize () at ecwdataset.cpp:1875
#16 0x00007ffff72e155f in ECWDataset::Open (poOpenInfo=0x7fffffff40d0, bIsJPEG2000=0) at ecwdataset.cpp:1353
#17 0x00007ffff72e1047 in ECWDataset::OpenECW (poOpenInfo=0x7fffffff40d0) at ecwdataset.cpp:1230
#18 0x00007ffff7530502 in GDALOpenInternal (oOpenInfo=..., papszAllowedDrivers=0x0) at gdaldataset.cpp:2236
#19 0x00007ffff75303b8 in GDALOpenInternal (pszFilename=0x6273f0 "PNOA_MR_OF_ETRS89_HU29_h50_0185.ecw", eAccess=GA_ReadOnly, 
    papszAllowedDrivers=0x0) at gdaldataset.cpp:2208
#20 0x00007ffff7530377 in GDALOpen (pszFilename=0x6273f0 "PNOA_MR_OF_ETRS89_HU29_h50_0185.ecw", eAccess=GA_ReadOnly)
    at gdaldataset.cpp:2199
#21 0x0000000000402bad in main (argc=2, argv=0x6273b0) at gdalinfo.c:173
(gdb)

[Even Rouault]

This is clearly a bug in the ECW SDK itself. As stated in the name of the function, ECWInitialize () is the first call done by GDAL to the ECW SDK. So I suspect there's an issue with how it has been compiled. Not denying your problem, but there's nothing to fix in GDAL itself, so I close this a "not a bug" as far as GDAL is concerned. Perhaps try to compile the ECW SDK with an older GCC version ?

[danitool]

Ok, you are right it's a problem of ECW SDK itself. I didn't notice this problem was discussed and solved some days ago in the mailing list:

​http://osgeo-org.1560.n6.nabble.com/ECW-support-on-Fedora-Linux-error-td4991388.html

This is the patch which fix the error:

--- Source/C/NCSUtil/NCSPrefsXML.cpp.ori	2012-10-17 12:40:01.000000000 +0200
+++ Source/C/NCSUtil/NCSPrefsXML.cpp	2012-10-17 12:40:30.854812252 +0200
@@ -32,7 +32,11 @@
 	} else {
 		char *pHomeDir = getenv("HOME");
 		if( pHomeDir ) {
+#ifdef NCS_BUILD_UNICODE
+			sUserPrefsFile.Format( NCS_T("%s%ls"), pHomeDir, NCS_T("/.erm/ncsuserprefs.xml") );
+#else
 			sUserPrefsFile.Format( NCS_T("%s%s"), pHomeDir, NCS_T("/.erm/ncsuserprefs.xml") );
+#endif
 		} else {
 			sUserPrefsFile = NCS_T("/etc/erm/ncsuserprefs.xml");
 		}

Thanks anyway.

[Even Rouault]

Thanks for the patch ! I had forgotten this discussion. I have referenced the patch in http://trac.osgeo.org/gdal/wiki/ECW