Re: A bug (memory leak) in GCC?

[Chris Vine]

On 18 Dec 2018 18:58:14 GMT
r...@zedat.fu-berlin.de (Stefan Ram) wrote:
> Is this possible: A bug (memory leak) in GCC?
>
> What is your opinion about this?
>
> Udo S. recently reported in the German C++ newsgroup
> "comp.lang.iso-c++" that GCC's library contains code like:
>
> template<typename _Facet> locale::locale(const locale& __other, _Facet* __f)
> { _M_impl = new _Impl(*__other._M_impl, 1);
>
> Let me remind you: The locales contain reference-counting
> memory management for facets. When the last locale
> referencing a facet (by a pointer) goes away, the facet also
> will be deleted. (Unless the facet was constructed with
> constructor argument »1«.)
>
> Now, Udo said that the locale cannot possibly delete the
> facet when the »new« quoted above will throw, so there'd be
> a leak.

There may be a bug but I do not think it lies in the code you have
posted.

If new throws std::bad_alloc then there is no leak with respect to that
particular allocation because there has been none, and surely neither
locale's constructor nor _Impl's constructor will run? If the _Impl
constructor above throws then the new expression is required to clean
up any memory the operator new() allocated for the _Impl object in
question.

Furthermore if the _Impl constructor throws then the locale object's
constructor will execute no further, so it cannot increment __f's
reference count. As the __f object is not passed to _Impl's
constructor I don't immediately see where the problem arises there
either (possibly the object accessed through the __other reference does
something amiss with other facets, who knows). I think you are going
to have to dig deeper into where the leak you have found arises (I have
not examined whether your leak detector works correctly and whether the
bug lies there instead).