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 _______________________________________________ Valgrind-users mailing list Valgrind-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/valgrind-users
