gdalinfo returns std::bad_alloc on ECW

Timmarh commented 5 years ago

Expected behavior and actual behavior.

gdalinfo returns an error when called on the ECW.

Steps to reproduce the problem.

For reproduction this is the ECW we are using. gdalinfo 2017_totaalmozaiek_RGB_lrl.ecw returns:

terminate called after throwing an instance of 'std::bad_alloc'
what():  std::bad_alloc
Aborted (core dumped)

output from gdb:

gdb --args gdalinfo /var/data/arnot/lufos/2017_totaalmozaiek_RGB_lrl.ecw
(gdb) run
Starting program: /usr/local/bin/gdalinfo /var/data/arnot/lufos/2017_totaalmozaiek_RGB_lrl.ecw
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc

Program received signal SIGABRT, Aborted.
__GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
51      ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
(gdb) bt
#0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
#1  0x00007ffff64fc801 in __GI_abort () at abort.c:79
#2  0x00007ffff1c16957 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#3  0x00007ffff1c1cab6 in ?? () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#4  0x00007ffff1c1caf1 in std::terminate() () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#5  0x00007ffff1c1cd24 in __cxa_throw () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#6  0x00007ffff1c1d29c in operator new(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#7  0x00007ffff1caf17d in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned long) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
#8  0x00007ffff2982438 in TiXmlDocument::LoadFile (this=this@entry=0x555555808888, filename=<optimized out>,
    encoding=encoding@entry=TIXML_ENCODING_UNKNOWN) at ../C/NCSEcw/NCSJP2/../../tinyxml/tinyxml.cpp:995
#9  0x00007ffff22e86da in CNCSPrefsXML::CNCSPrefsXML (this=0x555555808800, sFilename=...)
    at ../C/NCSUtil/NCSPrefsXML.cpp:78
#10 0x00007ffff22e8b9e in CNCSPrefsXML::Init () at ../C/NCSUtil/NCSPrefsXML.cpp:40
#11 0x00007ffff22ed020 in NCSUtilInit () at ../C/NCSUtil/util.c:81
#12 0x00007ffff29d180e in NCSecwInitInternal () at ../C/NCSEcw/NCSEcw/NCSEcw.cpp:335
#13 0x00007ffff6f55562 in ECWInitialize () at ecwdataset.cpp:3390
#14 0x00007ffff6f59830 in ECWDataset::Open (poOpenInfo=0x7fffffffd810, bIsJPEG2000=0) at ecwdataset.cpp:2613
#15 0x00007ffff72dd001 in GDALOpenEx (
    pszFilename=0x555555806410 "/var/data/arnot/lufos/2017_totaalmozaiek_RGB_lrl.ecw", nOpenFlags=66,
    papszAllowedDrivers=0x0, papszOpenOptions=0x0, papszSiblingFiles=<optimized out>) at gdaldataset.cpp:3327
#16 0x000055555555519a in main (argc=<optimized out>, argv=<optimized out>) at gdalinfo_bin.cpp:133
(gdb)

Operating system

We are using: Ubuntu 18.04

GDAL version and provenance

GDAL 3.0.1 build from github release

mloskot commented 5 years ago

Try if this is related https://stackoverflow.com/questions/21302930/centos-6-5-final-gdal-ecw-segmentation-fault , and there is a (interesting?) workaround mentioned in the answer's comment

We came across this problem as well. Libecw trys to save the prefs file in the $HOME directory. Unsetting $HOME in our GDAL environment worked around the issue

Alternative, point NCS_USER_PREFS environment variable to some dummy .xml file - it may help.

Unfortunately, the NCSUtil code is quite buggy (just look at the CNCSPrefsXML ctor :-))

rouault commented 5 years ago

https://trac.osgeo.org/gdal/wiki/ECW contains a cumulative patch https://trac.osgeo.org/gdal/attachment/wiki/ECW/libecwj2-3.3.patch that should solve that issue

mloskot commented 5 years ago

FYI, I did minor update to the wiki page mentioning std::length_error and std::bad_alloc in case it will make it bubble up in web search results.

OSGeo / gdal