I would like to piggyback onto this thread, and add some questions to the multi-threading.
When the README says "No multi-threading support", exactly what do you mean? This api should only ever be used in a single main thread environment, or that only a single thread should ever try to access an open FileGDB?
Our environment is a RHEL6.2 Linux installation, and locally we don't seem to have issues with a worker-thread approach to using the API calls for read access to a single open File GDB. However, a partner development group, running on the same RHEL6.1 VM environment is experiencing a core dump with a stack trace that shows up coring in the CloseGeoDatabase method.
#0 0x0557c478 in free () from /lib/libc.so.6
#1 0x036a131e in xmlResetError (err=0xac006b04) at error.c:871
#2 0x036a19e0 in xmlResetLastError () at error.c:895
#3 0x036b9379 in xmlCleanupParser () at parser.c:14074
#4 0x035a052a in UnInitializeXML() () from /h/FBCB2/cots/lib/libFileGDBAPI.so
#5 0x0346ce48 in FileGDBAPI::Geodatabase::CloseGeodatabase() ()
from /h/FBCB2/cots/lib/libFileGDBAPI.so
#6 0x034740bf in FileGDBAPI::CloseGeodatabase(FileGDBAPI::Geodatabase&) ()
from /h/FBCB2/cots/lib/libFileGDBAPI.so
#7 0x00a1dbec in vfsd::gst::vgp::tools::vfgdb::VFGDBDriver::CloseGeodatabase (
this=0xa3dfbdd8)
at ../../src/JBCDST_vgp/vfsd/gst/vgp/tools/vfgdb/VFGDBDriver.cpp:185
#8 0x00a1c9be in vfsd::gst::vgp::tools::vfgdb::VFGDBDriver::~VFGDBDriver (
this=0xa3dfbdd8, __in_chrg=<value optimized out>)
at ../../src/JBCDST_vgp/vfsd/gst/vgp/tools/vfgdb/VFGDBDriver.cpp:51
#9 0x00a117ad in vfsd::gst::vgp::tools::vnc::VncBuildMatrix::identifyManNetData (this=0xa3dfbfd0, fullPathToFGDB="/media/cdrecorder/Tiny.gdb", manNetInfo=...)
at ../../src/JBCDST_vgp/vfsd/gst/vgp/tools/vnc/VncBuildMatrix.cpp:238
#10 0x00270788 in jbcp::dst::mannet::c_DstMapDataProcessor::getMapData (path=
"/media/cdrecorder/Tiny.gdb", mapData=...)
at ../../src/JBCDST_mannet/jbcp/dst/mannet/c_DstMapDataProcessor.cpp:70
#11 0x00275c21 in jbcp::dst::mannet::c_ManeuverNetCopyAgent::doCopy (
this=0x962f530)
---Type <return> to continue, or q <return> to quit---
at ../../src/JBCDST_mannet/jbcp/dst/mannet/c_ManeuverNetCopyAgent.cpp:141
#12 0x00279305 in boost::_mfi::mf0<void, jbcp::dst::mannet::c_ManeuverNetCopyAgent>::operator() (this=0x96b18f0, p=0x962f530)
at /home/hendrixjl/alternate/builds/BUILD_core_1.1.0.31/BUILD_DIR/include/boost/bind/mem_fn_template.hpp:49
#13 0x002792a4 in boost::_bi::list1<boost::_bi::value<jbcp::dst::mannet::c_ManeuverNetCopyAgent*> >::operator()<boost::_mfi::mf0<void, jbcp::dst::mannet::c_ManeuverNetCopyAgent>, boost::_bi::list0> (this=0x96b18f8, f=..., a=...)
at /home/hendrixjl/alternate/builds/BUILD_core_1.1.0.31/BUILD_DIR/include/boost/bind/bind.hpp:246
#14 0x00279264 in boost::_bi::bind_t<void, boost::_mfi::mf0<void, jbcp::dst::mannet::c_ManeuverNetCopyAgent>, boost::_bi::list1<boost::_bi::value<jbcp::dst::mannet::c_ManeuverNetCopyAgent*> > >::operator() (this=0x96b18f0)
at /home/hendrixjl/alternate/builds/BUILD_core_1.1.0.31/BUILD_DIR/include/boost/bind/bind_template.hpp:20
#15 0x002791a8 in boost::detail::thread_data<boost::_bi::bind_t<void, boost::_mfi::mf0<void, jbcp::dst::mannet::c_ManeuverNetCopyAgent>, boost::_bi::list1<boost::_bi::value<jbcp::dst::mannet::c_ManeuverNetCopyAgent*> > > >::run (
this=0x96b1820)
at /home/hendrixjl/alternate/builds/BUILD_core_1.1.0.31/BUILD_DIR/include/boost/thread/detail/thread.hpp:56
#16 0x00840bf6 in thread_proxy () from /usr/lib/libboost_thread-mt.so.5
#17 0x00c57a09 in start_thread () from /lib/libpthread.so.0
---Type <return> to continue, or q <return> to quit---
#18 0x055e600e in clone () from /lib/libc.so.6
We are doing read access only from a single thread, so I fail to see how multi-threading could be to blame here.
Thanks
Eric