topic Re: memLeak at ArcGISTiledLayer and Basemap in Qt Maps SDK Questions

memLeak at ArcGISTiledLayer and Basemap

NorbertThoden — Wed, 28 Aug 2019 07:53:02 GMT

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 ...

Re: memLeak at ArcGISTiledLayer and Basemap

LukeSmallwood — Wed, 28 Aug 2019 11:35:58 GMT

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

Re: memLeak at ArcGISTiledLayer and Basemap

NorbertThoden — Wed, 28 Aug 2019 12:00:14 GMT

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)

https://cryptshare.rheinmetall.com/download1.php?2&id=CnwFDNO7Yg

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

Re: memLeak at ArcGISTiledLayer and Basemap

LukeSmallwood — Wed, 28 Aug 2019 12:03:35 GMT

Thanks Norbert,

I'll take a look.

Re: memLeak at ArcGISTiledLayer and Basemap

LukeSmallwood — Wed, 28 Aug 2019 15:11:00 GMT

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);

Re: memLeak at ArcGISTiledLayer and Basemap

NorbertThoden — Thu, 29 Aug 2019 06:42:43 GMT

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

Re: memLeak at ArcGISTiledLayer and Basemap

LukeSmallwood — Thu, 29 Aug 2019 09:20:18 GMT

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

Re: memLeak at ArcGISTiledLayer and Basemap

NorbertThoden — Thu, 29 Aug 2019 11:32:11 GMT

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

Re: memLeak at ArcGISTiledLayer and Basemap

LukeSmallwood — Thu, 29 Aug 2019 12:57:56 GMT

Thanks for the update Norbert

Re: memLeak at ArcGISTiledLayer and Basemap

NorbertThoden — Tue, 03 Sep 2019 12:10:19 GMT

Hi!

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

Thx

Re: memLeak at ArcGISTiledLayer and Basemap

LucasDanzinger — Tue, 03 Sep 2019 14:13:28 GMT

Hi Norbert-

Luke was able to reproduce the issue you are seeing. We are still investigating the cause and will need to do an analysis on the affected versions. We've logged a work item internally to do this work, but please continue to work with support to get a bug logged through that system, so that we can properly link up the work items to your account. Updates to the status of the bug will then be made through the bug attached to your account.

Thanks,

Lucas

Re: memLeak at ArcGISTiledLayer and Basemap

NorbertThoden — Fri, 06 Sep 2019 10:34:10 GMT

So, the ESRI Inc Support was finally able to create log a bug:

[BUG-000125025 : Creating and destroying a map created with ESRI::ArcGISTIledLayer and ESRI::Basemap shows memory leak]

But i am wondering abot the Support:

sometimes the operating system is not available and causes a delay of days/weeks,
I assume that, they don´t tell, which OS they use...
the attached files do not reach the ESRI Inc engineer
the message does not reach the ESRI Inc engineer
The please me to sent a video to verify the intensity of an effects, but do not delievery a video what they see....

And this time they are not able to verify a memory leak due to missing skills

This forum is very often the last chance to get an issue solved!!

So, many thanks to Luke and Lucas to support me in getting a BUG-ID!!!

Greetings from Bremen

Re: memLeak at ArcGISTiledLayer and Basemap

LucasDanzinger — Fri, 06 Sep 2019 19:23:26 GMT

Thanks for the feedback Norbert.

Re: memLeak at ArcGISTiledLayer and Basemap

NorbertThoden — Mon, 14 Oct 2019 08:13:31 GMT

Hi!

Ich got the info that the bug should be fixed with V100.7 🙂
(Case 02386995)

Thx