The operating system will reclaim all of the memory in the program's heap
when the program exits, so the memory does not leak here. Using a static
pointer here, instead of a static object, does mean that the object's
destructor will not be called. However, that is for the best, because static
deinitialization order is compiler dependent as well, and we do not want
the global variables to be destructed in the wrong order.
The TLSContainerStorage destructor does not perform any important action
(e.g. writing to a file), so it is safe to skip it on program exit.

A better solution to this problem in general would probably be to replace
the global variables with variables that are limited in scope, so that the
order of initialization and deinitialization could be controlled. However,
that would be a much bigger change. I opted for this solution because all
of the changes are in one file, and it fixes this bug without introducing
any new bugs.


On Sun, Jan 19, 2014 at 1:01 AM, Ilya Lavrenov <notifications@github.com>wrote:

> In modules/core/src/system.cpp:
>
> > @@ -1131,17 +1131,24 @@ class TLSContainerStorage
> >          }
> >      }
> >  };
> > -static TLSContainerStorage tlsContainerStorage;
> > +
> > +// This is a wrapper function that will ensure 'tlsContainerStorage' is constructed on first use.
> > +// For more information: http://www.parashift.com/c++-faq/static-init-order-on-first-use.html
> > +static TLSContainerStorage& getTLSContainerStorage()
> > +{
> > +    static TLSContainerStorage *tlsContainerStorage = new TLSContainerStorage();
>
> memory leak?
>
> —
> Reply to this email directly or view it on GitHub<https://github.com/Itseez/opencv/pull/2171/files#r8991379>
> .
>