Crash when using FileGDBAPI and Qt together on Linux

3437
5
05-31-2011 02:20 PM
ChrisScrimgeour
New Contributor
Hi,

I get a crash when I try to use FileGDBAPI together with Qt on Linux. The crash reveals itself to be an infinite recursion between QObject and QThread when creating a QObject.

Given the following code:

   DeleteGeodatabase(L"test.gdb");

   Geodatabase geodb;
   CreateGeodatabase(L"test.gdb", geodb); // Replace this with OpenGeodatabase(...) to make the crash go away

   std::ifstream states_file("states.xml");
   std::string states_xml;
   getline(states_file, states_xml, '\0');

   QObject q1; // Comment out this line to make the crash go away

   Table table_states;
   geodb.CreateTable(states_xml, L"", table_states);

   QObject q2; // <-- Crash occurs Here

   geodb.CloseTable(table_states);

   CloseGeodatabase(geodb);


The crash occurs on the line 'QObject q2;', and the following conditions need to be met in order for the crash to occur:
1) Call 'CreateGeodatabase(...)' (The crash does not occur if you open an existing Geodatabase.)
2) Create a QObject BEFORE the call to Geodatabase::CreateTable(...), AND
2) Create a QObject AFTER the call to Geodatabase::CreateTable(...).

I suspect that something is happening in the FileGDBAPI to cause threading to get into a bad state (due to the fact the crash involves QThread).

Chris Scrimgeour
0 Kudos
5 Replies
LanceShipman
Esri Regular Contributor
As noted in the readme under Notes, #3, the API does not support multi-threading. That said, the infinite loop is strange. We have investigated this an it has to do with our use of libXML internally. We continue to investigate this and will post any results on the blog.
0 Kudos
MartynasKulvietis
New Contributor
Hi, I also get the crash on windows, simple call crashes (1.2):

    Geodatabase* pGeodatabase = new Geodatabase;
    HRESULT hr = CreateGeodatabase(L"C:\\mydb.gdb", *pGeodatabase);

In call stack I saw somethging about ExtendedCatalog, BaseXMLxxxxx::GetString or smlr. stack is gone and I cannot reproduce callstack in debugger (ends up in ntdll.dll now). It is clearly reproducable and is a showstopper on windows 7 64bit.

Please help!
0 Kudos
LanceShipman
Esri Regular Contributor
Can you describe what you are attempting and provide some sample code that reproduces your problem. We tested locally and can not reproduce the crash.
0 Kudos
MartynasKulvietis
New Contributor
Can you describe what you are attempting and provide some sample code that reproduces your problem. We tested locally and can not reproduce the crash.


The call was made from a worker thread, I made a separate post on this (http://forums.arcgis.com/threads/59134-FileGDB-crash-windows-7-from-worker-thread?highlight=filegdb+...). I didn't understand it at the begining - we have an isolated worker thread which handles FileGDB connection - no concurrent DB access, though. I didn't think this could cause problems, because FileGDB links to multi-threaded CRT, so I could not deduce it immediately.
0 Kudos
LanceShipman
Esri Regular Contributor
Check your runtime library settings for the project. For Release, it should be /MD and for debug it should be /MDd. Mixing those up or adding /MT or /MTd into the mix can cause a crash.
0 Kudos