Re: Help with GtkBuilder memory leak

[Giovanni Panozzo]

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 the address sanitizer 
is exactly big as the one with a single GtkBuilder allocation

(8681 bytes in 308 allocations)

So you are right, it's a "one time" allocation meant to be freed by the 
OS. It seems to be only a problem with libfontconfing: all other 
libraries I use, do not expose this behavior.




When using Valgrind, you can also use suppression files which can
remove false positives and help you pinpoint the actual leaks in your
code.


With ASAN can be done too... I will blacklist them in some way.

Thank you

Ciao
Giovanni
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with GtkBuilder memory leak

[Emmanuele Bassi]

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 they do not grow unbounded and are collected by
the OS at the end of the process.

When using Valgrind, you can also use suppression files which can
remove false positives and help you pinpoint the actual leaks in your
code.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with GtkBuilder memory leak

[Giovanni Panozzo]

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 allocated inside libfontconfig and never freed :(


___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Help with GtkBuilder memory leak

[Emmanuele Bassi]

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,
>   gpointeruser_data)
> {
> GtkBuilder* b;
> b = gtk_builder_new_from_file("builderleak.glade");
> w = GTK_APPLICATION_WINDOW(gtk_builder_get_object(b, "mainwin"));
> g_object_set(w, "application", app, NULL);
>

g_object_unref (b);

> }

You also may want to look into using GtkBuilder templates, and your
own GtkApplicationWindow subclass.

Ciao,
 Emmanuele.

-- 
https://www.bassi.io
[@] ebassi [@gmail.com]
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: Is this a memory leak?

[Emmanuele Bassi]

no, a one-off memory allocation is not a memory leak.

there have been multiple threads regarding using Valgrind with Glib and
Gtk+; I suggest you look at the Gnome wiki and the archives of this list.

ciao,
Emmanuele.

sent from my phone, sorry for the formatting.

On 14 Nov 2011 19:03, Traktor Toni trustthe...@googlemail.com wrote:

Hi, I'm using librsvg-2. Just calling rsvg_init() rsvg_term() tells bytes
possibly lost in valgrind at line g_type_init_with_debug_flags inside
rsvg_init().


Also, why is it still calling g_type_init_with_debug_flags even though I'm
not compiling with any -g flag?

Thanks guys, this is making me nervous :(
__**_
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/**listinfo/gtk-devel-listhttp://mail.gnome.org/mailman/listinfo/gtk-devel-list
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: Is this a memory leak?

[David Nečas]

On Wed, Nov 09, 2011 at 02:38:44PM +0100, Traktor Toni wrote:
 Hi, I'm using librsvg-2. Just calling rsvg_init() rsvg_term() tells  
 bytes possibly lost in valgrind at line g_type_init_with_debug_flags  
 inside rsvg_init().

Do you use nip2.supp?

 Also, why is it still calling g_type_init_with_debug_flags even though  
 I'm not compiling with any -g flag?

g_type_init() is just an alias for g_type_init_with_debug_flags() with
zero debug flags.  So type initialisation always goes through
g_type_init_with_debug_flags().  And the flags are GObject debugging
flags they have nothing to do with the debugging info put into binaries
by the C compiler.

Yeti

___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

Re: is there a memory leak problem with gtk_widget_queue_draw()?

[okty]

 Does the profiler report the problem is inside gtk_widget_queue_draw code?

Actually, Glib's memory profiling does not show the exact place where memory
leak occurs, it just shows how much memory allocated. it is not as
comprehensive as Valgrind. May be it is better to check with Valgrind, with
a simple test application whether gtk_widget_queue_draw() causes such a
problem or not as Jim suggested. I will check and inform.

thanks,

Onur


Fernando Apesteguía wrote:
 
 On 9/6/07, okty [EMAIL PROTECTED] wrote:

 Hi,

 I am using GLib's memory profiling to check memory usage of my program. I
 noticed that for each refresh in my screen with gtk_widget_queue_draw(),
 I
 am checking my allocated memory and each refresh increases the size of
 allocated memory. Do you know any memory leak problem in
 gtk_widget_queue_draw()?
 
 I've never used Glib's memory profiling, but sometimes other programs
 like Valgrind (you could use this as well) report false positives in
 memory leaks. It has something to do with the way the memory is
 allocated (GAllocator is specially confusing for profilers)
 Does the profiler report the problem is inside gtk_widget_queue_draw code?
 
 Cheers
 

 Regards,
 --
 View this message in context:
 http://www.nabble.com/is-there-a-memory-leak-problem-with-gtk_widget_queue_draw%28%29--tf4392383.html#a12523308
 Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com.

 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
 
 

-- 
View this message in context: 
http://www.nabble.com/is-there-a-memory-leak-problem-with-gtk_widget_queue_draw%28%29--tf4392383.html#a12563182
Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com.

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: is there a memory leak problem with gtk_widget_queue_draw()?

[Jim George]

On 9/6/07, okty [EMAIL PROTECTED] wrote:

 Hi,

 I am using GLib's memory profiling to check memory usage of my program. I
 noticed that for each refresh in my screen with gtk_widget_queue_draw(), I
 am checking my allocated memory and each refresh increases the size of
 allocated memory. Do you know any memory leak problem in
 gtk_widget_queue_draw()?

The page http://live.gnome.org/Valgrind has some info on providing
flags to glib, making it use less efficient (but memcheck-friendly)
memory allocation code. Also, try writing a bare-bones program that
does nothing except call gtk_widget_queue_draw code periodically, and
see if you can replicate the problem.

-Jim
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: is there a memory leak problem with gtk_widget_queue_draw()?

[Fernando Apesteguía]

On 9/6/07, okty [EMAIL PROTECTED] wrote:

 Hi,

 I am using GLib's memory profiling to check memory usage of my program. I
 noticed that for each refresh in my screen with gtk_widget_queue_draw(), I
 am checking my allocated memory and each refresh increases the size of
 allocated memory. Do you know any memory leak problem in
 gtk_widget_queue_draw()?

I've never used Glib's memory profiling, but sometimes other programs
like Valgrind (you could use this as well) report false positives in
memory leaks. It has something to do with the way the memory is
allocated (GAllocator is specially confusing for profilers)
Does the profiler report the problem is inside gtk_widget_queue_draw code?

Cheers


 Regards,
 --
 View this message in context: 
 http://www.nabble.com/is-there-a-memory-leak-problem-with-gtk_widget_queue_draw%28%29--tf4392383.html#a12523308
 Sent from the Gtk+ - Apps Dev mailing list archive at Nabble.com.

 ___
 gtk-app-devel-list mailing list
 gtk-app-devel-list@gnome.org
 http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list