SegFaults under OGR with LIBKML and SDE drivers under Linux

[msmitherdc]

After rebuilding trunk GDAL with SDE 10.0 support, ogr will throw double free errors and others. This seems to be a conflict in XML Parse libraries between libKML and SDE.

Examples: Opening KMZ ERROR 4: ERROR Parseing kml layer doc.kml from /htdocs/dhs/marine/MarineTraffic.kmz :not well-formed on line 536591490 at offset 7374854148157758099

Program received signal SIGSEGV, Segmentation fault. 0x0000000000000000 in ?? () (gdb) bt #0 0x0000000000000000 in ?? () #1 0x00002aaaac0ed42a in XML_Parse () from /usr/local/lib/libpe.so #2 0x00002aaaab2550a1 in OGRGPXDataSource::Open (this=0x60cd30, pszFilename=0x60ca60 "/htdocs/dhs/marine/MarineTraffic.kmz", bUpdateIn=<value optimized out>) at ogrgpxdatasource.cpp:323 #3 0x00002aaaab256382 in OGRGPXDriver::Open (this=<value optimized out>, pszFilename=0x60ca60 "/htdocs/dhs/marine/MarineTraffic.kmz", bUpdate=<value optimized out>) at ogrgpxdriver.cpp:68 #4 0x00002aaaab2bb9d7 in OGRSFDriverRegistrar::Open (pszName=0x60ca60 "/htdocs/dhs/marine/MarineTraffic.kmz", bUpdate=0, ppoDriver=0x7fffffffe748) at ogrsfdriverregistrar.cpp:223 #5 0x000000000040233b in main (nArgc=<value optimized out>, papszArgv=0x60cea0) at ogrinfo.cpp:178

Opening FileGDB

Program received signal SIGABRT, Aborted. 0x00000032b2e30265 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00000032b2e30265 in raise () from /lib64/libc.so.6 #1 0x00000032b2e31d10 in abort () from /lib64/libc.so.6 #2 0x00000032b2e6a99b in libc_message () from /lib64/libc.so.6 #3 0x00000032b2e729d6 in free () from /lib64/libc.so.6 #4 0x00002aaaac0cfc0b in pe_sysmem_free () from /usr/local/lib/libpe.so #5 0x00002aaaac022727 in pe_deallocate_rtn () from /usr/local/lib/libpe.so #6 0x00002aaaac10e6bd in xml_free () from /usr/local/lib/libpe.so #7 0x00002aaaac0fe2bb in XML_ParserFree () from /usr/local/lib/libpe.so #8 0x00002aaaab199daf in KML::checkValidity (this=0x622450) at kml.cpp:198 #9 0x00002aaaab199ee9 in KML::isValid (this=0x2bda) at kml.cpp:476 #10 0x00002aaaab26fcc8 in OGRKMLDataSource::Open (this=0x618b50, pszNewName=0x618af0 "/fire/usa/hsip/2011/HSIP Gold 2011/Data/Infrastructure/Energy/Energy.gdb", bTestOpen=1)

at ogrkmldatasource.cpp:122

#11 0x00002aaaab26ffd5 in OGRKMLDriver::Open (this=<value optimized out>, pszName=0x618af0 "/fire/usa/hsip/2011/HSIP Gold 2011/Data/Infrastructure/Energy/Energy.gdb",

bUpdate=<value optimized out>) at ogrkmldriver.cpp:68

#12 0x00002aaaab2c9837 in OGRSFDriverRegistrar::Open (pszName=0x618af0 "/fire/usa/hsip/2011/HSIP Gold 2011/Data/Infrastructure/Energy/Energy.gdb", bUpdate=0, ppoDriver=0x7fffffffe718)

at ogrsfdriverregistrar.cpp:223

#13 0x000000000040235b in main (nArgc=<value optimized out>, papszArgv=0x618c60) at ogrinfo.cpp:178

[msmitherdc]

BT Formatted

[Even Rouault]

Well, from the stacktrace you provided, the conflict is more between libexpat from your system, which is used by the GPX and KML drivers (not the LIBKML one, but it also uses expat, so you'd get the same issues), and the one that seems to be embedded into this libpe.so from SDE, and that has likely a different ABI (or if they provide the headers for their embedded libexpat, you could perhaps try building against them, but I have not SDE so I am just blind guessing and I'd tend to think they wouldn't since it is likely an implementation detail...). I am not sure what you can do apart yelling at ESRI for their bad practice... Another more realistic possibility is to just disable any driver based on expat with ./configure --without-expat for a SDE specific GDAL build.

Or trying to build GDAL and/or libexpat with "versionned symbols" like Debian is going to try I think to resolve similar issues when building GDAL with internal libtiff 4.0 while allowing another app to link with GDAL and system libtiff 3, but don't ask me more on how to do that. It seems a bit involved and would likely require some patching in GDAL and/or expat.