C++ Logo

std-proposals

Advanced search

Re: [std-proposals] Deliberate memory leak

From: Thiago Macieira <thiago_at_[hidden]>
Date: Mon, 14 Oct 2024 10:42:20 -0700
On Monday 14 October 2024 03:22:20 GMT-7 Frederick Virchanza Gotham via Std-
Proposals wrote:
> On Mon, Oct 14, 2024 at 12:07 AM Richard Hodges wrote:
> > MyThing* mything_ptr = new ( sbrk(sizeof(MyThing)) ) MyThing ();
> >
> > voila. Your MyThing will never be destroyed, and malloc/new will be
> > completely unaware of it.
> >
> > No need to alter the standard.
>
> But what if the allocation takes place inside a proprietary shared
> library?

Yes, how are you going to do that if they don't give you the pointer to the
memory in the first place? How are you going to mark it as "don't count as
leaked"? Your technique here wouldn't have worked:

> An alternative to editing the source code for libpango would have been
> to do the following in my own program:
>
> SomeClass *p = pango_some_function( a, b, c ):
> for ( unsigned i = 0u; i < p->fonts->count; ++i )
> std::deliberate_leak( p->fonts->f[i] );
>
> std::deliberate_leak would be most useful in cases where you don't
> have the library's source code.

You need upstream to mark as deliberate. But then you have to discuss whether
it is the case for every user and every platform and situation.

How is such a marking going to be useful to the tooling? It needs to have some
code emitted, like Valgrind's requests do, otherwise the tooling won't know
the marking is there. But if code is emitted, then this is not zero cost,
meaning some projects might balk at accepting such contributions for the same
reason they don't free the block in the first place.

What would be incredibly useful would be to have Valgrind and ASan share a set
of marker macros that work on both. Why don't you work on that?

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Principal Engineer - Intel DCAI Platform & System Engineering

Received on 2024-10-14 17:42:23