Community

Good news: was able to keep Qt map app up for several days. Bad news: memory leaks

584
1
03-29-2019 06:35 AM
TroyFoster
by
Occasional Contributor
‎03-29-2019 06:35 AM

So another developer was able to keep our map app up for several days of operation without restarting it or it dying for other reasons.  They observed a lot of swap being used and eventually this seemed like it used up all the memory on their machine and the VM froze up requiring a restart.  This prompted me to go through the Runtime Qt documentation to check for those functions that have the "See also Returned QObjects Parenting" footnote since those are functions where our code needs to manually manage memory.

Here is the list of all those signal functions so they can easily be grepped out and manually analyzed for memory leaks:

grep -iIrs identifyGraphicsOverlayCompleted *
grep -iIrs identifyGraphicsOverlays *
grep -iIrs identifyLayerCompleted *
grep -iIrs layerViewStateChanged *
grep -iIrs addAttachmentCompleted *
grep -iIrs fetchAttachmentsCompleted *
grep -iIrs fetchSymbolCompleted *
grep -iIrs searchSymbolsCompleted *
grep -iIrs addedFeaturesCompleted *
grep -iIrs deletedFeaturesCompleted *
grep -iIrs queryRelatedFeaturesCompleted *
grep -iIrs updatedFeaturesCompleted *
grep -iIrs contentItemsCompleted *
grep -iIrs selectFeaturesCompleted *
grep -iIrs selectedFeaturesCompleted *
grep -iIrs applyEditsCompleted *
grep -iIrs populateFromServiceCompleted *
grep -iIrs authenticationChallenge *
grep -iIrs findGroupsCompleted *
grep -iIrs findItemsCompleted *
grep -iIrs queryFeaturesCompleted *
grep -iIrs queryStatisticsCompleted *
grep -iIrs basemapChanged *
grep -iIrs createGenerateOfflineMapParameterOverrides *
grep -iIrs importGeodatabaseDeltaCompleted *
‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍‍

Esri folk, did I miss any?

0 Kudos
1 Reply
JamesBallard1
by Esri Regular Contributor
Esri Regular Contributor
‎03-29-2019 07:58 AM

Hi Troy Foster‌,

   Thanks for pointing this out. I think our doc in this area can be improved.

In all the cases you pointed out, the object that has the signal is the one that will "own" (be the QObject parent of) any pointer objects that come back on those signals. You are free to change the parent or manage the lifetime of those objects however you want.

For example, the portal object will be the parent of the PortalQueryResultSetForItems object that comes back on the findItemsCompleted signal.

This avoids leaks but it's not ideal for long running applications where the portal object will probably never be deleted until app shutdown. To avoid that scenario you can employ RAII to clean up the memory sooner.  For example, you can wrap our pointers in a QScopedPointer, or even a std::unique_ptr if they don't need to live longer than the callback/slot code.

Please let us know if this clears things up.

Thanks

0 Kudos