Centos 6.5 Финальная ошибка сегментации GDAL/ECW

Question

У меня есть странная проблема с libgdal и ECW, на финале centos 6.5. Когда я пытаюсь прочитать файл ECW с gdalinfo (или что-то еще), я получаю ошибку сегментации.

Это очень странно, потому что у меня много виртуальной машины с одинаковыми центрами и с тем же ecw/gdal скомпилированным lib, но это происходит только на одном из них.

Попытка отладки ошибки с помощью GDB, я заметил, что ECW пытается выделить строку 2147483647 символов, а на системе предел 1073741820.

возможно, этот сказать libgdal/libecw который max_size предел для строки они должны использовать? Можно изменить max_size для системы?

Любые идеи будут оценены :)

OS:CentOS 6.5 (Final) ECW Lib:libecwj2-3.3 GDAL Lib:GDAL 1.9.2

Ошибка открытия файла ecw с помощью gdalinfo:

terminate called after throwing an instance of 'std::length_error' 
    what(): basic_string::_S_create 
Aborted 

стек GDB след

#0 0x00130424 in __kernel_vsyscall() 
#1 0x00e1ab11 in raise() from /lib/libc.so.6 
#2 0x00e1c3ea in abort() from /lib/libc.so.6 
#3 0x00d6db87 in __gnu_cxx::__verbose_terminate_handler()() from /usr/lib/libstdc++.so.6 
#4 0x00d6b9e6 in ??() from /usr/lib/libstdc++.so.6 
#5 0x00d6ba23 in std::terminate()() from /usr/lib/libstdc++.so.6 
#6 0x00d6bb62 in __cxa_throw() from /usr/lib/libstdc++.so.6 
#7 0x00d0c960 in std::__throw_length_error(char const*)() from /usr/lib/libstdc++.so.6 
#8 0x00d48ef6 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_S_create(unsigned int, unsigned int, std::allocator<char> const&)() from /usr/lib/libstdc++.so.6 
#9 0x00d4a029 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::_Rep::_M_clone(std::allocator<char> const&, unsigned int)() from /usr/lib/libstdc++.so.6 
#10 0x00d4a578 in std::basic_string<char, std::char_traits<char>, std::allocator<char> >::reserve(unsigned int)() from /usr/lib/libstdc++.so.6 
#11 0x00a699f3 in TiXmlDocument::LoadFile (this=0x80642e4, filename=0x8064374 "/root/", encoding=TIXML_ENCODING_UNKNOWN) at ../C/NCSEcw/NCSJP2/../../tinyxml/tinyxml.cpp:995 
#12 0x00b4ae6b in CNCSPrefsXML::CNCSPrefsXML (this=0x8064280, sFilename=...) at ../C/NCSUtil/NCSPrefsXML.cpp:78 
#13 0x00b4b0f0 in CNCSPrefsXML::Init() at ../C/NCSUtil/NCSPrefsXML.cpp:40 
#14 0x00b46dd7 in NCSPrefInit() at ../C/NCSUtil/NCSPrefs.cpp:84 
#15 0x00b4fcf5 in NCSUtilInit() at ../C/NCSUtil/util.c:81 
#16 0x00ac5e90 in NCSecwInitInternal() at ../C/NCSEcw/NCSEcw/NCSEcw.cpp:335 
#17 0x00ac6aa7 in NCSecwInit() at ../C/NCSEcw/NCSEcw/NCSEcw.cpp:355 
#18 0x003321b7 in ECWInitialize() at ecwdataset.cpp:1891 
#19 0x00335fa4 in ECWDataset::Open (poOpenInfo=0xbfff5540, bIsJPEG2000=0) at ecwdataset.cpp:1369 
#20 0x0033652a in ECWDataset::OpenECW (poOpenInfo=0xbfff5540) at ecwdataset.cpp:1246 
#21 0x00550163 in GDALOpenInternal (oOpenInfo=..., papszAllowedDrivers=0x0) at gdaldataset.cpp:2251 
#22 0x0055077a in GDALOpenInternal (pszFilename=0x8063480 "/mnt/sdb1/mapguide_data/sienaprovincia/ortofoto_1954/1954.ecw", eAccess=GA_ReadOnly, papszAllowedDrivers=0x0) at gdaldataset.cpp:2209 
#23 0x005507dc in GDALOpen (pszFilename=0x8063480 "/mnt/sdb1/mapguide_data/sienaprovincia/ortofoto_1954/1954.ecw", eAccess=GA_ReadOnly) at gdaldataset.cpp:2200 
#24 0x08049eed in main (argc=2, argv=0x8063450) at gdalinfo.c:173 

Answer 1

Мы нашли, где проблема. libecw попытается сохранить файл prefs, но для кода с ошибкой в ​​NCSUtil он сообщает tinyxml открыть каталог в виде файла. Обычно это терпит неудачу, но без больших проблем. В какой-то степени мы испытываем странное поведение функции ftell(), используемой tinyxml, в одной системе.

См: https://stackoverflow.com/questions/21307977/strange-behaviour-of-ftell-on-twin-system

Это плохое возвращаемое значение из ftell причины TinyXML пытается выделить (2^31) -1 размер строки, которая больше, чем предел системы. Так что все разбилось.

Если кто-то испытал подобное поведение ftell(), пожалуйста, сообщите нам, нам интересно понять, что вызывает разные результаты в подобных системах.