Yes, various libraries in the stack perform one-off allocations; these
are *NOT* leaks, since they do not grow unbounded and are collected by
the OS at the end of the process.
Yes!
I modified builderleak.c allocating 1000 times GtkBuilder and
deallocating it just after. The leak reported by
Hi;
On 2 June 2016 at 16:45, Giovanni Panozzo wrote:
> I tryied to unref it, but memory leaks are still here. Almost all are
> indicating something allocated inside libfontconfig and never freed :(
Yes, various libraries in the stack perform one-off allocations; these
are *NOT* leaks, since the
Thank you for answering.
Use Valgrind, instead.
I will try.
g_object_unref (b);
It's good to know that I can destroy the GtkBuilder object early in the
application. I didn't know it.
I tryied to unref it, but memory leaks are still here. Almost all are
indicating something allo
Hi;
you're missing a `g_object_unref()` inside the `activate` handler:
On 2 June 2016 at 16:03, Giovanni Panozzo wrote:
>
> I'm trying to identify some memory leaks of my application using
> -fsanitize=address of GCC.
Use Valgrind, instead.
> static void
> activate (GtkApplication* app,
>
I'm trying to identify some memory leaks of my application using
-fsanitize=address of GCC.
But really I came to a point where all seems to be inside GTK.
Here is my small test program, compile
- builderleak.c -
#include
GtkApplicationWindow *w;
sta
