Uploaded image for project: 'Qt'
  1. Qt
  2. QTBUG-13145

S60 memory not deleted at app exit

    XMLWordPrintable

Details

    • 4fdb6a01b35d9cd4dc9e5e4d6682449476d68375

    Description

      There has been some in-depth analysis of memory not deleted by app exit time in a simple Qt application running on S60. Such memory may cause the following problems:

      • this might be a real memory leak
      • it makes it harder to detect real memory leaks, by swamping the AnalyzeTool output with false positives
      • If Qt is only loaded into a process by plugin, and the plugin is unloaded, these will be true memory leaks in the host app.

      This is the detail of the analysis, together with some suggested improvements to Qt:

      This is a complete analysis of simpleapp. The atool data-file (.xml) is attached. The contents of the heap are also attached (based on the output of my quick hack to atool customuser.cpp).

      BTW, the docmlhelloworld app seems to have 1082 "leaks".

      • Patches for two Qt "leaks" (involving 7 blocks) are included below.
        These are not really leaks in the sense that the memory does not
        grow over time, but they are easy to tidy up. Perhaps we should
        call these "puddles"
      • Intentional leaks in simpleapp main.cpp commented-out.
      • 31 leaks remain, categorized as follows:
      • 2 blocks qt_vg_image_pool
      • 3 blocks QSoftKeyManagerPrivate::self
      • 5 blocks Khronos
      • 6 blocks m_animations
      • 3 blocks graphics_system
      • 4 blocks __crt0
      • 7 blocks QThreadData
      • 1 block eventLoops
      • Recommend ignoring __crt0 allocations.
      • The 5 blocks labeled "Khronos" /may/ be fixed by calling
        eglReleaseThread(). Or they can just be ignored.
      • The 8 blocks of QThreadData are still alive because they are
        referenced by the various private objects that are still alive.
      • qt_vg_image_pool, QSoftKeyManagerPrivate::self, m_animations,
        graphics_system, and eventLoops /could/ be deallocated and would
        likely remove all leaks except __crt0.

      QVGImagePool::instance() holds reference (qt_vg_image_pool) to QVImagePool().

      http://s60lxr/source/sf/mw/qt/src/openvg/qvgimagepool.cpp?v=mcl_201030_hw79#070
      070 qt_vg_image_pool = new QVGImagePool();

      61c4b8 2 QVGImagePoolPrivate
      61c4b0 2 QVGImagePool

      QSoftKeyManager::instance() allocates a new QSoftKeyManager, and stores a reference to it in QSoftKeyManagerPrivate::self – but that is never deleted.

      http://s60lxr/source/sf/mw/qt/src/gui/kernel/qsoftkeymanager.cpp?v=mcl_201030_hw79#087
      087 QSoftKeyManagerPrivate::self = new QSoftKeyManager;

      61d028 6
      e29178 35 QSoftKeyManagerPrivateS60
      61c498 2 QSoftKeyManager

      QEglContextTracker tracks calls to QEglContext::QEglContext() correctly.
      But perhaps a call to eglReleaseThread() is missing?

      http://s60lxr/source/sf/mw/qt/src/gui/egl/qegl.cpp?v=mcl_201030_hw79#067
      067 eglTerminate(QEgl::display());

      61c4a0 2
      61d010 6
      6044a0 3
      e2abe0 4243
      604494 3

      QS60StylePrivate::QS60StylePrivate() appends new QS60StyleAnimation object to m_animations, but this is never freed.

      http://s60lxr/source/sf/mw/qt/src/gui/styles/qs60style_s60.cpp?v=mcl_201030_hw79#1150
      1150 m_animations()->append(progressBarAnimation);

      e16d98 21 QObjectPrivate
      603268 10 AnimationDataV2
      e0f288 21 QObjectPrivate
      6048d0 6 AnimationData
      e08638 21 QObjectPrivate
      6022d0 4 QS60StyleAnimation

      http://s60lxr/source/sf/mw/qt/src/gui/kernel/qapplication.cpp?v=mcl_201030_hw79#927
      927 graphics_system = QGraphicsSystemFactory::create(graphics_system_name);

      6012e8 2
      e16f78 21 QObjectPrivate
      60284c 3

      __crt0()

      601128 2
      600a30 8
      600910 8
      601828 3

      QThreadData-related.

      600590 12 #1 QWaitConditionPrivate
      e08558 15 #2 QMutexPrivate
      e084e0 29 #3 QThreadPrivate (owned by #4) refers to #4,#7,#2,#1
      6010d8 2 #4 QAdoptedThread
      e084a0 15 #5 QMutex (member of QThreadData)
      e08460 15 #6 QMutex (member of QPostEventList)
      e08420 15 #7 QThreadData refers to #6,#5,#4 and 61bec8

      Note: e08420 is referred-to by e29178, e16d98, e0f288, e08638, e16f78

      QEventLoop::exec() stores a QStack in threadData; later eventLoops.pop() is called but the underlying storage is not deallocated.

      http://s60lxr/source/sf/mw/qt/src/corelib/kernel/qeventloop.cpp?v=mcl_201030_hw79#188
      188 d->threadData->eventLoops.push(this);

      61bec8 6

      Remove CDir-related leaks (4 blocks)

      — original/qglobal.cpp 2010-08-24 13:43:18.536969700 +0300
      +++ qglobal.cpp 2010-08-24 13:45:28.245075300 +0300
      @@ -1833,6 +1833,7 @@ QSysInfo::S60Version QSysInfo::s60Versio
      if (err == KErrNone && contents->Count() > 0 && (*contents)[0].iName.Length() >= 12) {
      TInt major = (*contents)[0].iName[9] - '0';
      TInt minor = (*contents)[0].iName[11] - '0';
      + delete contents;
      if (major == 3) {
      if (minor == 1)

      { return cachedS60Version = SV_S60_3_1; @@ -1850,8 +1851,9 @@ QSysInfo::S60Version QSysInfo::s60Versio return cachedS60Version = SV_S60_5_2; }

      }
      + } else

      { + delete contents; }
      • delete contents;
        }
      1. ifdef Q_CC_NOKIAX86

      Remove CClientRepository-related leaks (3 blocks)

      — original/qapplication_s60.cpp 2010-08-24 13:47:23.343244900 +0300
      +++ qapplication_s60.cpp 2010-08-24 13:47:50.891177700 +0300
      @@ -1375,6 +1375,7 @@ void qt_init(QApplicationPrivate * /* pr
      S60->avkonComponentsSupportTransparency = (value==1) ? true : false;
      }
      }
      + delete repository;
      #endif

      #ifdef QT_KEYPAD_NAVIGATION

      Attachments

        No reviews matched the request. Check your Options in the drop-down menu of this sections header.

        Activity

          People

            mread Murray Read
            mread Murray Read
            Votes:
            3 Vote for this issue
            Watchers:
            5 Start watching this issue

            Dates

              Created:
              Updated:
              Resolved:

              Gerrit Reviews

                There are no open Gerrit changes