I would not to say "still reachable" simply means the allocation is not
leaked.
Think about the following senario: A programer allocate a big chunk of
memory from heap and hold it in a global variable, supposed that by design
this memory chunk will not used any more at some point and is aimed to be
released to save memory, but the programmer forget to free it, this memory
will be considered "still reachable" on exit but the fact is that this
behaviour do harm to the program since it will waste more memory when
running the program. This allocation should be considered as leak.
Maybe the "still reachable" memory allocations caused by not
destructing global variables of qt plugin will not do any harm to qt app,
but others may do harm, how can we easily distinguish the bad ones from the
good ones? I think the best approach is to make sure we release all memory
allocated from heap on exit.
BTW, not every memory leak detector can tell you which memory is "still
reachable", I used bulitin memory leak detector of debug version of msvcrt,
inspector from Intel and C++ memory leak detector from softwareverify.com,
they don't have the concept of "still reachable".
Anyway, I still consider that we should introduce a method to disable
the not unloading qt plugin feature at runtime, maybe we can only disable
this feature in a developer build of qt and that will not cause any crash
in a release build.
On Sat, Oct 15, 2016 at 11:48 PM, Thiago Macieira <thiago.macie...@intel.com
> wrote:
> Em sábado, 15 de outubro de 2016, às 15:33:53 PDT, Liang Jian escreveu:
> > But I am still curious about that If we don't unload the plugin, will
> > the destructor of the gobal object in it be called? If it is not called,
> > what if the gobal object of the plugin hold some memory allocated from
> heap?
>
> It's easy to test.
>
> In any case, I don't consider leaks those that happen because the memory
> wasn't freed at program exit while holding a pointer to it. In fact,
> neither
> does valgrind: those are "still reachable" allocations.
>
> --
> Thiago Macieira - thiago.macieira (AT) intel.com
> Software Architect - Intel Open Source Technology Center
>
> _______________________________________________
> Development mailing list
> Development@qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
_______________________________________________
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
