memLeak at ArcGISTiledLayer and Basemap

987
13
08-28-2019 12:53 AM
NorbertThoden
Occasional Contributor III

Hi!

Does ESRI know that there is a memory Leak using

ESRI::ArcGISTiledLayer, ESRI::Basemap (V100.5 and V100.6))

Creating and destroing a simple map WITHOUT terminating the application.

Valgrind (@V100.5)

class ESRI::ArcGISTiledLayer
==24614== 15,592 (1,744 direct, 13,848 indirect) bytes in 1 blocks are definitely lost in loss record 835 of 855
==24614== at 0x4C2E2AF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24614== by 0x40F5E69: operator new(unsigned long) (in /usr/lib64/libc++.so.1.0)
==24614== by 0xA877D11: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xA1FF237: RT_ImageTiledLayer_create (in /usr/lib64/libruntimecore.so)
==24614== by 0x5206BE1: ESRI::RuntimeCore::QRTImageTiledLayer::QRTImageTiledLayer() (in /usr/lib64/libEsriCommonQt.so)
==24614== by 0x525969C: ESRI::RuntimeCore::QRTArcGISTiledLayer::QRTArcGISTiledLayer(ESRI::RuntimeCore::QRTTileCache*) (in /usr/lib64/libEsriCommonQt.so)
==24614== by 0x55BCC65: QRTImpl::ArcGISTiledLayerImpl::ArcGISTiledLayerImpl(std::shared_ptr<QRTImpl::TileCacheImpl> const&) (in /usr/lib64/libEsriCommonQt.so)
==24614== by 0x49A566: Esri::ArcGISRuntime::ArcGISTiledLayer::ArcGISTiledLayer(Esri::ArcGISRuntime::TileCache*, QObject*) (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Prepared/LayerMemoryLeak/LayerMemoryLeak)
==24614== by 0x498C34: MapWindow::MapWindow() (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Prepared/LayerMemoryLeak/LayerMemoryLeak)
==24614== by 0x4971CA: main (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Prepared/LayerMemoryLeak/LayerMemoryLeak)

class ESRI::Basemap
(just the main leaks of ESRI::Basemap)
==24614== 4,288 bytes in 8 blocks are still reachable in loss record 806 of 855
==24614== at 0x4C2E2AF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24614== by 0x40F5E69: operator new(unsigned long) (in /usr/lib64/libc++.so.1.0)
==24614== by 0xC43FB01: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC43A737: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC43A2A2: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC44343C: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC442110: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xA07D9D4: RT_ArcGISRuntimeEnvironment_setInstallDirectory (in /usr/lib64/libruntimecore.so)
==24614== by 0x5255D74: ESRI::RuntimeCore::QRTArcGISRuntimeEnvironment::setInstallDirectory(QString const&, ESRI::RuntimeCore::QRTObject*) (in /usr/lib64/libEsriCommonQt.so)
==24614== by 0x56C1574: QRTImpl::ArcGISRuntimeEnvironmentImpl::initialize() (in /usr/lib64/libEsriCommonQt.so)
==24614== by 0x4A21CD: Esri::ArcGISRuntime::Basemap::Basemap(QObject*) (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Prepared/LayerMemoryLeak/LayerMemoryLeak)
==24614== by 0x4985B4: MapWindow::MapWindow() (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Prepared/LayerMemoryLeak/LayerMemoryLeak)
==24614==
==24614== 4,288 bytes in 8 blocks are still reachable in loss record 807 of 855
==24614== at 0x4C2E2AF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24614== by 0x40F5E69: operator new(unsigned long) (in /usr/lib64/libc++.so.1.0)
==24614== by 0xC43FB01: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC43A737: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC43A2DF: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC44343C: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xC442110: ??? (in /usr/lib64/libruntimecore.so)
==24614== by 0xA07D9D4: RT_ArcGISRuntimeEnvironment_setInstallDirectory (in /usr/lib64/libruntimecore.so)
==24614== by 0x5255D74: ESRI::RuntimeCore::QRTArcGISRuntimeEnvironment::setInstallDirectory(QString const&, ESRI::RuntimeCore::QRTObject*) (in /usr/lib64/libEsriCommonQt.so)
==24614== by 0x56C1574: QRTImpl::ArcGISRuntimeEnvironmentImpl::initialize() (in /usr/lib64/libEsriCommonQt.so)
==24614== by 0x4A21CD: Esri::ArcGISRuntime::Basemap::Basemap(QObject*) (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Prepared/LayerMemoryLeak/LayerMemoryLeak)
==24614== by 0x4985B4: MapWindow::MapWindow() (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Prepared/LayerMemoryLeak/LayerMemoryLeak)
and some more

I am already in contact with the support team, but no real progress ...

0 Kudos
13 Replies
LukeSmallwood
Esri Contributor

Hi Norbert - thanks for reporting this one.

Which constructor are you using for the ArcGISTiledLayer? From the stack it looks like you are supplying a TileCache directly?

Could you possibly post a code snippet (including any parent QObjects etc.) showing how you are creating these objects? 

Thanks again,

Luke

0 Kudos
NorbertThoden
Occasional Contributor III

Hi Luke!

Nice to hear from you 🙂

Of course. I will attach the sample i sent to the Support Team, okay?

The zip file contains sample code, description etc.

Additional:

An VisualStudioAnalyzer output (created by my colleague)

TransferId: CnwFDNO7Yg
Pwd: ESRI1234

Note: In the meantime i was able to verifiy this using V100.6.

The memleak is still there for  the ArcGISTiledLayer and Basemap.

Hope that you can verify this.

Thanks in advance and greetings from Bremen

Norbert

0 Kudos
LukeSmallwood
Esri Contributor

Thanks Norbert,

I'll take a look.

0 Kudos
LukeSmallwood
Esri Contributor

Hi Norbert,

I'm having trouble with that download link that you supplied but I believe I can reproduce the same thing with my own code. We will try and look into that and also any information that comes through via the support issue you logged.

Here's a snippet of the repro code I'm using - let me know if that looks substantially different to what you are doing:

void TestMemoryLeakQuick::recreateMap()
{
  emit usedMemoryBytesChanged();
  qDebug() << usedMemoryBytes();
  if (m_parent)
  {
    delete m_parent;
    m_parent = nullptr;
    m_mapView->setMap(nullptr);
    m_map = nullptr;
  }
  m_parent = new QObject(this);
  const QString tpkPath{".../tpk/SanFrancisco.tpk"};
  auto tileCache = new TileCache(tpkPath, m_parent);
  auto tiledLayer = new ArcGISTiledLayer(tileCache, m_parent);
  auto basemap = new Basemap(tiledLayer, m_parent);
  m_map = new Map(basemap, m_parent);
  if (m_mapView)
  {
    m_mapView->setMap(m_map);
  }
}
0 Kudos
NorbertThoden
Occasional Contributor III

Hi Luke!

The sample code ist attached to this thread, see top of the page.

The link (https://cryptshare.rheinmetall.com/download1.php?2&id=CnwFDNO7Yg) contains just the VisualStudioAnalyzer output, since it has a size of ~330Mb. Don´t know if it´s helpful...

The problem regarding the support  that nor my german neither the US support enineer seems to have no experience with any memcheck tool...

But i am trying to find a way to convince them 🙂

Jepp, the code snippet seems to fine.

Which tool do you use and can you see memleaks?

Thx in advance

Norbert

0 Kudos
LukeSmallwood
Esri Contributor

Hi Norbert, 

The sample code is attached to this thread, see top of the page.

Got it thanks! I'll give the code sample a try and see if I can repro the links. In my testing yesterday I was just doing a quick check of the process memory info but we can use ValGrind to look at what is going on.

I did notice this line in your sample code:

      m_tiledLayer = new Esri::ArcGISRuntime::ArcGISTiledLayer(tpkCache);

That tiled layer is missing a parent object and so won't get cleared up when you call 

delete this;

That would certainly leak - but I'm not sure if there is something else going on as well. Could you try with a parent added for that allocation and see if your results are affected?

Thanks,

Luke

0 Kudos
NorbertThoden
Occasional Contributor III

Hi Luke!

You´re right, that is wrong in my sample (but correct at our original code)

The memleak is still alive:

based on V100.6 i got:

==23411== 6,952 (1,456 direct, 5,496 indirect) bytes in 1 blocks are definitely lost in loss record 465 of 490
==23411== at 0x4C2E2AF: malloc (in /usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==23411== by 0x40F5E69: operator new(unsigned long) (in /usr/lib64/libc++.so.1.0)
==23411== by 0xA77BC61: ??? (in /usr/lib64/libruntimecore.so)
==23411== by 0xA0E6ED7: RT_ImageTiledLayer_create (in /usr/lib64/libruntimecore.so)
==23411== by 0x52470F1: ESRI::RuntimeCore::QRTImageTiledLayer::QRTImageTiledLayer() (in /usr/lib64/libEsriCommonQt.so)
==23411== by 0x52C4308: ESRI::RuntimeCore::QRTArcGISTiledLayer::QRTArcGISTiledLayer(ESRI::RuntimeCore::QRTTileCache*) (in /usr/lib64/libEsriCommonQt.so)
==23411== by 0x55D5E0B: QRTImpl::ArcGISTiledLayerImpl::ArcGISTiledLayerImpl(std::shared_ptr<QRTImpl::TileCacheImpl> const&) (in /usr/lib64/libEsriCommonQt.so)
==23411== by 0x49E946: Esri::ArcGISRuntime::ArcGISTiledLayer::ArcGISTiledLayer(Esri::ArcGISRuntime::TileCache*, QObject*) (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Reported/2019-08-21_LayerMemoryLeak_case#02386995/LayerMemoryLeak)
==23411== by 0x49D175: MapWindow::MapWindow() (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Reported/2019-08-21_LayerMemoryLeak_case#02386995/LayerMemoryLeak)
==23411== by 0x49B0F1: main (in /shd/CTC/TOOLS/LTS-Esri-SupportDir/LTS-Esri/Reported/2019-08-21_LayerMemoryLeak_case#02386995/LayerMemoryLeak)

Valgind has some more notes regarding ArcGISTiledLayer, but this is the biggest thing...

Thx

0 Kudos
LukeSmallwood
Esri Contributor

Thanks for the update Norbert

0 Kudos
NorbertThoden
Occasional Contributor III

Hi!

Could you verify the memleak using V100.5, V100.6 or V100.7?

Thx

0 Kudos