Re: Application doesn't leak memory running valgrind

On Mon, 2022-02-28 at 09:45 -0800, Stefano Antonelli wrote:
> On Mon, 2022-02-28 at 18:00 +0100, Floyd, Paul wrote:
> > On 2022-02-28 17:28, Stefano Antonelli wrote:
> > 
> Using a memory pool doesn't explain why the leak doesn't get bigger
> when running valgrind though does it?

So I think I understand the problem.

QML sits on top of EGL.  The EGL layer is supplied in binary form.

In pmap I see a growing number of pages owned by /dev/dri/renderD129
which is a device file.

crw-rw---- 1 root render 226, 129 Feb 23 15:48 /dev/dri/renderD129

When the leak occurs, the number of 4k pages owned by this render
device increases.  Running valgrind leak-test (or gdb with malloc
breakpoint), the number of 4k pages owned by this render device _do
not_ increase.

I believe that QML creates "a graphic thing" from this render device
and probably also deletes it, but I don't think the library controlling
the render device is freeing the memory.

I *think* this library (libglapi.so) is using malloc, but I don't have
any source code.  ldd shows me:

12: 00000000     0 FUNC    GLOBAL DEFAULT  UND malloc@GLIBC_2.4 (3)

So something real is happening when valgrind leak-test is used that's
affecting this graphics library in a good way.

Can anyone explain what valgrind does?  I know it replaces malloc with
vg_malloc, but does anything else happen?

Thanks,
Stef