Centos 6.5最终GDAL / ECW分段错误

时间:2014-01-23 08:26:31

标签: c++ segmentation-fault centos gdal

我对libgdal和ECW有一个奇怪的问题,在centos 6.5 final。当我尝试使用gdalinfo(或其他任何东西)读取ECW文件时,我收到了分段错误。

这很奇怪,因为我有很多虚拟机具有相同的centos和相同的ecw / gdal编译的lib,但这只发生在其中一个上。

尝试用gdb调试错误,我注意到ecw试图分配一个2147483647字符串,但在系统上限制为1073741820。

告诉libgdal / libecw他们必须使用哪个字符串的max_size限制是可能的?可以更改系统的max_size吗?

任何想法都将受到赞赏:)

操作系统: centos 6.5(最终) ECW lib: libecwj2-3.3 GDAL lib: gdal 1.9.2

使用gdalinfo打开ecw文件时出错:

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

1 个答案:

答案 0 :(得分:0)

我们已经找到问题所在。 libecw尝试保存prefs文件,但是,对于NCSUtil中的错误代码,它告诉tinyxml将目录作为文件打开。通常这会失败但没有很大的问题。 我们在一个系统上经历了一个奇怪的ftell()函数行为,由tinyxml使用。

请参阅:https://stackoverflow.com/questions/21307977/strange-behaviour-of-ftell-on-twin-system

来自ftell的这个错误返回值会导致tinyxml尝试分配一个(2 ^ 31)-1大小的字符串,该字符串大于系统限制。所以一切都崩溃了。

如果有人经历了ftell()的类似行为,请告诉我们,我们很有兴趣了解导致类似系统的不同结果的原因。