subject:"Is this a memory leak\?"

Re: How to confirm a memory leak

2016-08-01 Thread Emmanuele Bassi

Hi;

On 30 July 2016 at 14:58,  <jcup...@gmail.com> wrote:
> You need to set the malloc routines to use the real system malloc;
>
> export G_DEBUG=gc-friendly
> export G_SLICE=always-malloc

With recent (2 years old at least) versions of GLib,
`G_SLICE=always-malloc` is not necessary: GLib will detect if it's
running under Valgrind and will disable the slice allocator
automatically. It'll also mark regions in GObject that do tricks with
memory management, like the per-instance private data.

There's still a plan to make GLib more Valgrind friendly by having
"cleanup" sections that get run at the end of the process life time,
if the process is running under Valgrind, but it's not a trivial thing
to achieve because of the potential for re-entrancy and dependencies
between components.

Ciao,
 Emmanuele.

> On 28 July 2016 at 17:18, Norman Goldstein <norm...@telus.net> wrote:
>> I'd like to understand how to confirm a potential memory leak in gtk3.
>> Valgrind shows a definite leak, and "top" shows a steadily increasing
>> resident set size (RES).  However, as I have come to understand, due to how
>> gtk/glib uses slices for memory management, and how the main loop of gtk
>> plays a part, things are not as straightforward as I have just outlined.  Is
>> there a definitive guide, "How to confirm a memory leak in GTK"?  I have
>> only seen various relevant pages on the net.
>> ___
>> gtk-app-devel-list mailing list
>> gtk-app-devel-list@gnome.org
>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

-- 
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: How to confirm a memory leak

2016-08-01 Thread Emmanuele Bassi

Hi;

On 30 July 2016 at 20:00, Norman Goldstein <norm...@telus.net> wrote:

> It seems the debug version is less confusing for valgrind, or
>
>*** Does the debug code actually present different source code to the
> compiler?

Yes; debugging code enables various code paths that are meant to make
it easier for developers to debug GLib and GTK+.

> You mention, below, that I may need to add a few suppressions, but before
> adding another suppression, I got this far with the debug info:
>
> In /usr/src/debug/glib-2.48.1/gio/gdbusproxy.c
>
> LoadPropertiesOnNameOwnerChangedData *data;
> data = g_new0 (LoadPropertiesOnNameOwnerChangedData, 1);
> data->name_owner = g_strdup (new_owner); //<=== line 1391 Leak
>
> So it appears that data->name_owner is not being freed.

It is, if you look at the code of on_name_owner_changed_get_all_cb:

https://git.gnome.org/browse/glib/tree/gio/gdbusproxy.c#n1246

If the operation was not cancelled, the name_owner string is "stolen"
and stored inside the proxy instance structure; the name_owner field
is going to be freed when the proxy instance is finalized.

If the operation was cancelled, the name_owner string is freed.

Ciao,
 Emmanuele.

> On 30/07/16 06:58 AM, jcup...@gmail.com wrote:
>>
>> You need to set the malloc routines to use the real system malloc;
>>
>>  export G_DEBUG=gc-friendly
>>  export G_SLICE=always-malloc
>>
>> I have this suppressions file:
>>
>>   https://github.com/jcupitt/libvips/blob/master/libvips.supp
>>
>> That's for a gobject-based library, you might need to add a few things
>> to it. Run your program with:
>>
>>   valgrind --suppressions=libvips.supp --leak-check=yes
>> ./myprogram
>>
>> And hopefully you'll see "0 bytes definitely lost".
>>
>> John
>>
>>
>>
>>
>> On 28 July 2016 at 17:18, Norman Goldstein <norm...@telus.net> wrote:
>>>
>>> I'd like to understand how to confirm a potential memory leak in gtk3.
>>> Valgrind shows a definite leak, and "top" shows a steadily increasing
>>> resident set size (RES).  However, as I have come to understand, due to
>>> how
>>> gtk/glib uses slices for memory management, and how the main loop of gtk
>>> plays a part, things are not as straightforward as I have just outlined.
>>> Is
>>> there a definitive guide, "How to confirm a memory leak in GTK"?  I have
>>> only seen various relevant pages on the net.
>>> ___
>>> gtk-app-devel-list mailing list
>>> gtk-app-devel-list@gnome.org
>>> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
>
>
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list



-- 
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: How to confirm a memory leak

2016-08-01 Thread Norman Goldstein


Thank you for this.  I have attached the source for the code being tested.

The valgrind report, attached, was greatly pared down,
as a consequence  of your suppression file.

I ran valgrind twice:

1st time: No debug info -- 519 bytes definitely lost
2nd time: With debug info -- 7 bytes definitely lost  ## This is the one 
attached

Both times contained a
Conditional jump or move depends on uninitialised value(s) ).

It seems the debug version is less confusing for valgrind, or

   *** Does the debug code actually present different source code to 
the compiler?


You mention, below, that I may need to add a few suppressions, but before
adding another suppression, I got this far with the debug info:

In /usr/src/debug/glib-2.48.1/gio/gdbusproxy.c

LoadPropertiesOnNameOwnerChangedData *data;
data = g_new0 (LoadPropertiesOnNameOwnerChangedData, 1);
data->name_owner = g_strdup (new_owner); //<=== line 1391 Leak

So it appears that data->name_owner is not being freed.
From the subsequent call of g_dbus_connection_call, it seems
that data is being considered as user data, so is being expected
to be freed by whoever allocated it.  In fact, deallocation is happening,
since only data's "name_owner" field is not being freed.

In /usr/src/debug/glib-2.48.1/glib/gmem.h

#define g_new0(struct_type, n_structs)   _G_NEW (struct_type, 
n_structs, malloc0)


but this is where I lost things, as the _G_NEW macro is rather 
confusing, so I

did not get to the code that is deallocating "data".

In summary (and I hope the above is not too much analysis in a post):

   *** Why would "data" be deallocated, but not its "name_owner" field?





On 30/07/16 06:58 AM, jcup...@gmail.com wrote:

You need to set the malloc routines to use the real system malloc;

 export G_DEBUG=gc-friendly
 export G_SLICE=always-malloc

I have this suppressions file:

  https://github.com/jcupitt/libvips/blob/master/libvips.supp

That's for a gobject-based library, you might need to add a few things
to it. Run your program with:

  valgrind --suppressions=libvips.supp --leak-check=yes ./myprogram

And hopefully you'll see "0 bytes definitely lost".

John




On 28 July 2016 at 17:18, Norman Goldstein <norm...@telus.net> wrote:

I'd like to understand how to confirm a potential memory leak in gtk3.
Valgrind shows a definite leak, and "top" shows a steadily increasing
resident set size (RES).  However, as I have come to understand, due to how
gtk/glib uses slices for memory management, and how the main loop of gtk
plays a part, things are not as straightforward as I have just outlined.  Is
there a definitive guide, "How to confirm a memory leak in GTK"?  I have
only seen various relevant pages on the net.
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list


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

Re: How to confirm a memory leak

2016-07-30 Thread jcupitt

You need to set the malloc routines to use the real system malloc;

export G_DEBUG=gc-friendly
export G_SLICE=always-malloc

I have this suppressions file:

 https://github.com/jcupitt/libvips/blob/master/libvips.supp

That's for a gobject-based library, you might need to add a few things
to it. Run your program with:

 valgrind --suppressions=libvips.supp --leak-check=yes ./myprogram

And hopefully you'll see "0 bytes definitely lost".

John




On 28 July 2016 at 17:18, Norman Goldstein <norm...@telus.net> wrote:
> I'd like to understand how to confirm a potential memory leak in gtk3.
> Valgrind shows a definite leak, and "top" shows a steadily increasing
> resident set size (RES).  However, as I have come to understand, due to how
> gtk/glib uses slices for memory management, and how the main loop of gtk
> plays a part, things are not as straightforward as I have just outlined.  Is
> there a definitive guide, "How to confirm a memory leak in GTK"?  I have
> only seen various relevant pages on the net.
> ___
> gtk-app-devel-list mailing list
> gtk-app-devel-list@gnome.org
> https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

How to confirm a memory leak

2016-07-30 Thread Norman Goldstein

I'd like to understand how to confirm a potential memory leak in gtk3.  
Valgrind shows a definite leak, and "top" shows a steadily increasing 
resident set size (RES).  However, as I have come to understand, due to 
how gtk/glib uses slices for memory management, and how the main loop of 
gtk plays a part, things are not as straightforward as I have just 
outlined.  Is there a definitive guide, "How to confirm a memory leak in 
GTK"?  I have only seen various relevant pages on the net.

___
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

2016-06-02 Thread 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

2016-06-02 Thread 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

2016-06-02 Thread 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

2016-06-02 Thread 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

Help with GtkBuilder memory leak

2016-06-02 Thread Giovanni Panozzo



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;

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);

}

int
main (intargc,
  char **argv)
{
  GtkApplication *app;
  int status;

  app = gtk_application_new ("org.gtk.builderleak", 
G_APPLICATION_FLAGS_NONE);

  g_signal_connect (app, "activate", G_CALLBACK (activate), NULL);
  status = g_application_run (G_APPLICATION (app), argc, argv);
  g_object_unref (app);

  return status;
}
--
- builderleak.glade --



  
  
True
False

  
True
False
label
  

  

--

Just compile the above builderleak.c with

gcc `pkg-config --cflags gtk+-3.0` -o builderleak builderleak.c 
`pkg-config --libs gtk+-3.0` -fsanitize=address


[tested on current Arch Linux, with gtk3 3.20.6-1]

And execute it.

When closing the main window, the application will exit, but the address 
sanitizer will shows you a lot of memory leaks of objects allocated by 
libfontconfig.


Here is part of the address sanitizer output:

=
==14900==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 1280 byte(s) in 2 object(s) allocated from:
#0 0x7f56220d8120 in __interceptor_realloc 
/build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:59

#1 0x7f561d86fb9a  (/usr/lib/libfontconfig.so.1+0x1db9a)

Indirect leak of 3168 byte(s) in 99 object(s) allocated from:
#0 0x7f56220d7d58 in __interceptor_malloc 
/build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:38

#1 0x7f561d85e0ef  (/usr/lib/libfontconfig.so.1+0xc0ef)

Indirect leak of 1340 byte(s) in 114 object(s) allocated from:
#0 0x7f56220d7d58 in __interceptor_malloc 
/build/gcc/src/gcc/libsanitizer/asan/asan_malloc_linux.cc:38

#1 0x7f561f854ab9 in __strdup (/usr/lib/libc.so.6+0x7dab9)
...


Just swap the internal GtkLabel widget with a GtkDrawingArea, and all 
memory leaks.


The question is: is my program which is causing all these memory leaks ? 
Why ?



Thank you



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

Re: GTK 2.24.10 memory leak on win32?

2012-07-03 Thread Gabriele Greco

 code (that I think is correct) do not leak in linux (ubuntu 12.04, gtk
  2.24.10) nor on win32 (GTK 2.16) while it leaks about 12kbyte/sec with
 GTK
  2.24.10 on win32.
 G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
 --num-callers=32 src/your-binary


I had already tested there was no leak in linux (same gtk version 2.24.10),
with ps hat is not that accurate in the short term, but if you let your
program run a pair of hours and both VSZ and RSS do not change I think it's
accurate enough.

Anyway I ran valgrind (without suppress file) for a pair of minutes and I
got a positive result (at least I think):

==11727== HEAP SUMMARY:
==11727== in use at exit: 320,761 bytes in 5,570 blocks
==11727==   total heap usage: 72,767 allocs, 67,197 frees, 3,161,964 bytes
allocated
==11727==
==11727== LEAK SUMMARY:
==11727==definitely lost: 0 bytes in 0 blocks
==11727==indirectly lost: 0 bytes in 0 blocks
==11727==  possibly lost: 9,848 bytes in 309 blocks
==11727==still reachable: 310,913 bytes in 5,261 blocks

... on win32 with gtk 2.24.10 (20120208 bundle from gtk.org) the program
leaks about 10kb per sec, and as I said there is no leak also on win32 with
2.16.6 (20100207 bundle from gtk.org)

-- 
Ing. Gabriele Greco, DARTS Engineering
Tel: +39-0100980150  Fax: +39-0100980184
s-mail: Piazza Della Vittoria 9/3 - 16121 GENOVA (ITALY)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: GTK 2.24.10 memory leak on win32?

2012-07-03 Thread jcupitt

On 2 July 2012 15:44, Gabriele Greco gabriele.gr...@darts.it wrote:
 I'm posting the code here before creating a bugzilla entry for it since I'm
 not sure I can use g_idle_add to notify a new frame is available without
 freeing the source, that works in linux and in older WIN32 versions and it
 seems correct since g_idle_add() documentation says:

Your code looks a bit strange, but I agree it should work with no
leaks. Probably a bug.

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

Re: GTK 2.24.10 memory leak on win32?

2012-07-03 Thread Gabriele Greco


 ... on win32 with gtk 2.24.10 (20120208 bundle from gtk.org) the program
 leaks about 10kb per sec, and as I said there is no leak also on win32 with
 2.16.6 (20100207 bundle from gtk.org)


Filed bug 679312 https://bugzilla.gnome.org/show_bug.cgi?id=679312

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

Re: GTK 2.24.10 memory leak on win32?

2012-07-03 Thread Gabriele Greco

Your code looks a bit strange, but I agree it should work with no
 leaks. Probably a bug.


In the real code there are 1 to X (up to 12) GdkImage(s) that are semaphore
protected and filled by h264 decoders in different threads. Once the thread
fills his  GdkImage with the frame data it uses g_idle_add() to signal the
GUI thread that the associated GdkDrawingArea has to be redraw, the idle
function simply queue the draw of the widget and the expose event locks the
gdkimage and do the real drawing.

This works quite smoothly (25fps) with twelve 352x288 video inputs on any
dual core PC .

I pulled out all the threaded logic and made an example as simple as
possible to trigger the problem, actually I could also remove the drawing
itself, but it was useful to see that the program was not hung :)

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

Re: GTK 2.24.10 memory leak on win32?

2012-07-02 Thread Olivier Sessink

On 07/02/2012 04:44 PM, Gabriele Greco wrote:
 We have found a regression that block us to migrate our existing apps from
 GTK 2.16.x to GTK 2.24.10 (20120208), it seems there is a memory leak in
 g_idle_add() use or something related to queue_draw(), anyway the following
 code (that I think is correct) do not leak in linux (ubuntu 12.04, gtk
 2.24.10) nor on win32 (GTK 2.16) while it leaks about 12kbyte/sec with GTK
 2.24.10 on win32.

have you tried running the code in valgrind on Linux to test this for
sure? try:

G_SLICE=always-malloc G_DEBUG=gc-friendly valgrind --tool=memcheck
--num-callers=32 src/your-binary

I don't see any obvious problemin your code, but I have no experience
with the code you posted.

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

Is this a memory leak?

2011-11-14 Thread Traktor Toni

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-list

Re: Is this a memory leak?

2011-11-14 Thread 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?

2011-11-14 Thread 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: gtk_widget_destroy(my_window) memory leak

2011-05-04 Thread Allin Cottrell

On Wed, 4 May 2011, jessonel wrote:

 Have ever reported the memory leak of gtk_widget_destroy?

Yes, hundreds of people. Have you heard of a useful tool called
google? 99.9 percent of such leak reports are bogus, reflecting
lack of knowledge of how memory management works in the GTK stack.

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

How Test Gtk GUI application memory leak and Property Chages

2009-11-04 Thread Balakrishnan V

HI,
I need to test GUI gtk program.

this Include following requirements

* Capture and Replay X events... here we have some tools (Xnee)
** Test Heap usage only GTK lib using (not include other lib heap usage like
pango)*
*Problem here all libs using same heap ... information providing in smaps
files also like same .*
this i tried no tool supports screen comparison *
*
** detect memory leaks this support ARM architecture.*
*
*
*
*
Thanks
Bala*
*
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: valgrind reports memory leak on g_main_loop_run

2008-12-17 Thread Alexander Semenov


Sune Ahlgren wrote:

Hi,

I use 1 GMain event loop in my main context for monitoring of events on file 
descriptors. I shut down my program by receiving a SIGTERM. In this signal 
handler I do the following:

   g_main_loop_quit(loop);  g_main_loop_unref(loop);  loop = NULL;

I've also tried to move:
   g_main_loop_unref(loop);  loop = NULL;to the very end of my main function. I 
still get:

==6087== 744 bytes in 3 blocks are possibly lost in loss record 7 of 9==6087==  
  at 0x4021C8A: memalign (vg_replace_malloc.c:460)==6087==by 0x4021D3E: 
posix_memalign (vg_replace_malloc.c:569)==6087==by 0x409391E: (within 
/usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x40950F2: g_slice_alloc (in 
/usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x404F55E: g_array_sized_new 
(in /usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x404F676: g_array_new (in 
/usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x40A0423: g_static_private_set 
(in /usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x4075A43: (within 
/usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x407606C: 
g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1600.6)==6087==by 
0x4079852: (within /usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x4079D71: 
g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1600.6)==6087==by 0x806F805: 
init (init.c:193)


I set up the main loop like this:
   loop = g_main_loop_new(NULL, FALSE);
   g_main_loop_run(loop);
What am I doing wrong?

BRs
/Sune
_
Senaste sportnyheterna  rykande färska resultat!
http://sport.msn.se/
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

   

Hi.

T popular kind of question. Are you aware of 
http://live.gnome.org/Valgrind ?


Regards.

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

Re: Confusing about memory leak and GtkTreeView, GtkCellRendererCombo GtkCellRendererSpin

2008-12-11 Thread Yu Feng

Hi Kim,

Usually if a property of a GObject is G_TYPE_OBJECT, the GObject will
hold a reference count of that property.

And because your GtkAdjustment is created in a floating state, you don't
need to unref it after setting it as a property value of a GObject.

refer to line 209:gtkcellrendererspin.c
   if (obj)
priv-adjustment = g_object_ref_sink (obj);
  break;

and line 150:gtkcellrendererspin.c
  if (priv  priv-adjustment)
g_object_unref (priv-adjustment);

adj = GTK_ADJUSTMENT (gtk_adjustment_new (50.0, 0.0, 100.0, 5.0,
 10.0, 0.0));

   adj-ref_count = unknown,
   adj-is_floating = true.

   renderer = gtk_cell_renderer_spin_new ();
   renderer-ref_count = unknown
   renderer-is_floating = true
 
g_object_set (renderer, editable, TRUE, adjustment, adj,
 digits, 0, NULL);
 
   renderer-ref_count = unknown
   renderer-is_floating = true
   adj-ref_count = 1
   adj-is_floating = -1


the remaining ref_count of adj shouldn't be freed by you. It will be
freed in  GObjectClass-dispose of renderer. (that's why that reference
is owned by renderer: who frees, who owns)

Yu

On Fri, 2008-12-12 at 14:10 +0900, Keedi Kim wrote:
 HI, :-)
 
 Memory leak and reference counts are very confused.
 I am using GtkTreeView with GtkCellRendererCombo and GtkCellRenderSpin.
 So, I use Adjustment for GtkCellRendererSpin
 and GtkListStore(or GtkTreeStore) for GtkCellRenderCombo.
 
 Some of columns uses same Adj, and TreeModel, so saved them in renderer.
 Rest of columns uses different so I saved them in GtkTreeModel and set
 attributes.
 
 Anyway, I'm very confusing about memory management.
 
 I have understood I have to decrease reference count to avoid memory leak
 when I use following API because they increase reference count:
 
 g_object_set()
 gtk_tree_store_set()
 
 Now I have some question about those API, and GtkCellRenderer{Combo|Spin}.
 
 1.
 If I use GtkCellRenderSpin and make new GtkAdjustment
 which is saved in the **Renderer**, then do I have to do g_object_unref(adj)
 ?
 
 2.
 If I use GtkCellRenderSpin and make new GtkAdjustment
 which is saved in the **GtkTreeModel** with setting attribute,
 then do I have to do g_object_unref(adj) ?
 
 3.
 If I use GtkCellRenderCombo and make new Gtk{Tree|List}Store
 which is saved in the **Renderer**, then do I have to do
 g_object_unref(model) ?
 
 4.
 If I use GtkCellRenderCombo and make new Gtk{Tree|List}Store
 which is saved in the **GtkTreeModel** with setting attribute,
 then do I have to do g_object_unref(adj) ?
 
 5.
 Is there any connection with floating issues?
 When I save GtkAdjustment in Renderer
 before saving, floating value is true
 and after saving floating value is false,
 But I save GtkAdjustment in GtkTreeModel,
 before saving, and after saving floating value is still true.
 
 And here is some code snippets for asking this issues.
 
 * code snippet which saves GtkAdjustment in Renderer
 code:
  {
GtkAdjustment *adj;
GtkCellRenderer *renderer;
GtkTreeViewColumn *column;
 
adj = GTK_ADJUSTMENT (gtk_adjustment_new (50.0, 0.0, 100.0, 5.0,
 10.0, 0.0));
renderer = gtk_cell_renderer_spin_new ();
 
  {
gboolean colorness_float;
colorness_float = g_object_is_floating (adj);
g_debug (= float: colorness(%d)\n, colorness_float);
  }
 
g_object_set (renderer, editable, TRUE, adjustment, adj,
 digits, 0, NULL);
 
  {
gboolean colorness_float;
colorness_float = g_object_is_floating (adj);
g_debug (= float: colorness(%d)\n, colorness_float);
  }
 
g_object_unref (adj); - /* DO I NEED THIS? */
 
g_signal_connect (G_OBJECT (renderer), edited, G_CALLBACK
 (brightness_edited), window);
 
column = gtk_tree_view_column_new_with_attributes
 (_(column_titles[VIEW_CAMERA_BRIGHTNESS]),
   renderer,
   text,
 MODEL_CAMERA_BRIGHTNESS,
   visible,
 MODEL_SUPPORT_CAMERA_PROPERTY,
   sensitive,
 MODEL_ONLINE,
   NULL);
gtk_tree_view_column_set_resizable (column, FALSE);
gtk_tree_view_column_set_clickable (column, FALSE);
gtk_tree_view_append_column (GTK_TREE_VIEW (tree_view), column);
  }
 
 result:
  = float: colorness(1)
  = float: colorness(0)
 
 * code snippet which saves GtkAdjustment and GtkListStore in GtkTreeModel.
 code:
  {
GtkAdjustment *bitrate_adj, *gop_size_adj;
GtkListStore *quality_model;
gchar quality_str[1024];
 
bitrate_adj = GTK_ADJUSTMENT (gtk_adjustment_new (10.0, 10.0, 100.0,
 10.0, 20.0, 0.0));
gop_size_adj = GTK_ADJUSTMENT (gtk_adjustment_new (10.0, 10.0,
 100.0, 10.0

Re: Confusing about memory leak and GtkTreeView, GtkCellRendererCombo GtkCellRendererSpin

2008-12-11 Thread Keedi Kim

Thanks Yu,

Now I could understand a little bit about floating and reference count. :-)

I'm sorry to bother you, but..
then are the following answers right?

1.
If I use GtkCellRenderSpin and make new GtkAdjustment
which is saved in the **Renderer**, then do I have to do g_object_unref(adj)
?

- DO NOT g_object_unref()
since GtkCellRenderSpin will eliminates floating and it will free
GtkAdjustment.

2.
If I use GtkCellRenderSpin and make new GtkAdjustment
which is saved in the **GtkTreeModel** with setting attribute,
then do I have to do g_object_unref(adj) ?

- DO g_object_ref()

3.
If I use GtkCellRenderCombo and make new Gtk{Tree|List}Store
which is saved in the **Renderer**, then do I have to do
g_object_unref(model) ?

- DO g_object_ref_sink() then g_object_ref() -- Is this right?

4.
If I use GtkCellRenderCombo and make new Gtk{Tree|List}Store
which is saved in the **GtkTreeModel** with setting attribute,
then do I have to do g_object_unref(model) ?

- DO g_object_ref()

Thanks again, :-)


2008/12/12 Yu Feng rainwood...@gmail.com

 Hi Kim,

 Usually if a property of a GObject is G_TYPE_OBJECT, the GObject will
 hold a reference count of that property.

 And because your GtkAdjustment is created in a floating state, you don't
 need to unref it after setting it as a property value of a GObject.

 refer to line 209:gtkcellrendererspin.c
   if (obj)
priv-adjustment = g_object_ref_sink (obj);
  break;

 and line 150:gtkcellrendererspin.c
  if (priv  priv-adjustment)
g_object_unref (priv-adjustment);

 adj = GTK_ADJUSTMENT (gtk_adjustment_new (50.0, 0.0, 100.0, 5.0,
  10.0, 0.0));

adj-ref_count = unknown,
   adj-is_floating = true.

   renderer = gtk_cell_renderer_spin_new ();
renderer-ref_count = unknown
   renderer-is_floating = true
  
 g_object_set (renderer, editable, TRUE, adjustment, adj,
  digits, 0, NULL);
  
renderer-ref_count = unknown
   renderer-is_floating = true
   adj-ref_count = 1
   adj-is_floating = -1


 the remaining ref_count of adj shouldn't be freed by you. It will be
 freed in  GObjectClass-dispose of renderer. (that's why that reference
 is owned by renderer: who frees, who owns)

 Yu

 On Fri, 2008-12-12 at 14:10 +0900, Keedi Kim wrote:
  HI, :-)
 
  Memory leak and reference counts are very confused.
  I am using GtkTreeView with GtkCellRendererCombo and GtkCellRenderSpin.
  So, I use Adjustment for GtkCellRendererSpin
  and GtkListStore(or GtkTreeStore) for GtkCellRenderCombo.
 
  Some of columns uses same Adj, and TreeModel, so saved them in renderer.
  Rest of columns uses different so I saved them in GtkTreeModel and set
  attributes.
 
  Anyway, I'm very confusing about memory management.
 
  I have understood I have to decrease reference count to avoid memory leak
  when I use following API because they increase reference count:
 
  g_object_set()
  gtk_tree_store_set()
 
  Now I have some question about those API, and
 GtkCellRenderer{Combo|Spin}.
 
  1.
  If I use GtkCellRenderSpin and make new GtkAdjustment
  which is saved in the **Renderer**, then do I have to do
 g_object_unref(adj)
  ?
 
  2.
  If I use GtkCellRenderSpin and make new GtkAdjustment
  which is saved in the **GtkTreeModel** with setting attribute,
  then do I have to do g_object_unref(adj) ?
 
  3.
  If I use GtkCellRenderCombo and make new Gtk{Tree|List}Store
  which is saved in the **Renderer**, then do I have to do
  g_object_unref(model) ?
 
  4.
  If I use GtkCellRenderCombo and make new Gtk{Tree|List}Store
  which is saved in the **GtkTreeModel** with setting attribute,
  then do I have to do g_object_unref(adj) ?
 
  5.
  Is there any connection with floating issues?
  When I save GtkAdjustment in Renderer
  before saving, floating value is true
  and after saving floating value is false,
  But I save GtkAdjustment in GtkTreeModel,
  before saving, and after saving floating value is still true.
 
  And here is some code snippets for asking this issues.
 
  * code snippet which saves GtkAdjustment in Renderer
  code:
   {
 GtkAdjustment *adj;
 GtkCellRenderer *renderer;
 GtkTreeViewColumn *column;
  
 adj = GTK_ADJUSTMENT (gtk_adjustment_new (50.0, 0.0, 100.0, 5.0,
  10.0, 0.0));
 renderer = gtk_cell_renderer_spin_new ();
  
   {
 gboolean colorness_float;
 colorness_float = g_object_is_floating (adj);
 g_debug (= float: colorness(%d)\n,
 colorness_float);
   }
  
 g_object_set (renderer, editable, TRUE, adjustment, adj,
  digits, 0, NULL);
  
   {
 gboolean colorness_float;
 colorness_float = g_object_is_floating (adj);
 g_debug (= float: colorness(%d)\n,
 colorness_float);
   }
  
 g_object_unref (adj); - /* DO I NEED THIS? */
  
 g_signal_connect (G_OBJECT (renderer), edited, G_CALLBACK
  (brightness_edited), window);
  
 column

Re: {Spam?} Re: memory leak in gtk

2007-11-25 Thread Emmanuele Bassi


On Sat, 2007-11-24 at 10:09 +0100, Vincent Torri wrote:

  From what I've heard about memory leaking, this is not unique to the
  GTK library.  If the rumours are correct, applications like `ls` are
  notorious for leaking memory, safe in the knowledge that the OS will
  clean up after them.
 
 and if someone calls 'ls' iteratively in his program ?

if you call 'ls' in a child process the leak happens in you child
process, so it will be cleaned up by the OS when the child process
terminates and the parent reaps it. the memory will be reassigned to
other applications, thus is *not* a leak.

in a real leak the OS cannot reassign the leaked memory because your
application is still the owner.

ciao,
 Emmanuele.

-- 
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net

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

Re: {Spam?} Re: memory leak in gtk

2007-11-24 Thread Vincent Torri



On Sat, 24 Nov 2007, Michael Lamothe wrote:

 From what I've heard about memory leaking, this is not unique to the
 GTK library.  If the rumours are correct, applications like `ls` are
 notorious for leaking memory, safe in the knowledge that the OS will
 clean up after them.

and if someone calls 'ls' iteratively in his program ?

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

Re: {Spam?} Re: memory leak in gtk

2007-11-24 Thread Junior Polegato - GTK+ GTKmm

Vincent Torri escreveu:
 On Sat, 24 Nov 2007, Michael Lamothe wrote:
   
 From what I've heard about memory leaking, this is not unique to the
   
 GTK library.  If the rumours are correct, applications like `ls` are
 notorious for leaking memory, safe in the knowledge that the OS will
 clean up after them.
 
 and if someone calls 'ls' iteratively in his program ?
   
When a process finish, the OS clean up memory. However, on some cases, 
the cost to freeing the memory is greater than let to the OS.

-- 
Yours Truly,

   Junior Polegato

   A pilgrim of problems; A parchment of solutions!
   Professional Page: http://www.juniorpolegato.com.br

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

Re: {Spam?} Re: {Spam?} Re: memory leak in gtk

2007-11-24 Thread Junior Polegato - GTK+ GTKmm

Vincent Torri escreveu:
 On Sat, 24 Nov 2007, Junior Polegato - GTK+  GTKmm wrote:
 Vincent Torri escreveu:
 On Sat, 24 Nov 2007, Michael Lamothe wrote:
 From what I've heard about memory leaking, this is not unique to the
 GTK library.  If the rumours are correct, applications like `ls` are
 notorious for leaking memory, safe in the knowledge that the OS will
 clean up after them.
 and if someone calls 'ls' iteratively in his program ?
 When a process finish, the OS clean up memory. However, on some 
 cases, the cost to freeing the memory is greater than let to the OS.
 and ? You have definitely a leak there. Calling, in your program (with 
 the exec() functions family), iteratively and infinitely a program 
 that leaks can crash your system. 'ls' is maybe not a good example, 
 but i'm sure you see what I mean ;)
I said on some cases, like ls. On this case you have described, the 
cost is the system crash.

-- 
Yours Truly,

   Junior Polegato

   A pilgrim of problems; A parchment of solutions!
   Professional Page: http://www.juniorpolegato.com.br

___
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()?

2007-09-09 Thread 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

is there a memory leak problem with gtk_widget_queue_draw()?

2007-09-07 Thread okty


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()?

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

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

2007-09-07 Thread 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()?

2007-09-07 Thread 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

how do I plug this glib main loop memory leak?

2006-07-25 Thread Sebastian Kuzminsky

I'm not understanding something about the glib main loop and reference
counting.

I've got this trivial program that does nothing:


- begin -

#include signal.h
#include stdio.h
#include glib.h

GMainLoop* main_loop = NULL;


void signal_handler(int signo) {
printf(caught signal %d\n, signo);
g_main_loop_quit(main_loop);
}


int main(int argc, char *argv[]) {
main_loop = g_main_loop_new(NULL, TRUE);

signal(SIGTERM, signal_handler);
signal(SIGINT, signal_handler);

while (g_main_loop_is_running(main_loop)) {
printf(top of main loop\n);
g_main_context_iteration(NULL, TRUE);
}

printf(cleaning up and exiting\n);

g_main_loop_unref(main_loop);

return 0;
}

- end -


It looks a little funny because it's reduced from a bigger program.
I run this under valgrind and hit ^C:

0 [EMAIL PROTECTED] /home/seb/tmp  gcc `pkg-config --cflags --libs glib-2.0` 
main-loop-leak.c -o main-loop-leak
0 [EMAIL PROTECTED] /home/seb/tmp  valgrind --show-reachable=yes 
--leak-check=yes ./main-loop-leak
==3880== Memcheck, a memory error detector.
==3880== Copyright (C) 2002-2006, and GNU GPL'd, by Julian Seward et al.
==3880== Using LibVEX rev 1606, a library for dynamic binary translation.
==3880== Copyright (C) 2004-2006, and GNU GPL'd, by OpenWorks LLP.
==3880== Using valgrind-3.2.0-Debian, a dynamic binary instrumentation 
framework.
==3880== Copyright (C) 2000-2006, and GNU GPL'd, by Julian Seward et al.
==3880== For more details, rerun with: -v
==3880==
--3880-- DWARF2 CFI reader: unhandled CFI instruction 0:50
--3880-- DWARF2 CFI reader: unhandled CFI instruction 0:50
top of main loop
caught signal 2
cleaning up and exiting
==3880==
==3880== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 13 from 1)
==3880== malloc/free: in use at exit: 5,196 bytes in 14 blocks.
==3880== malloc/free: 15 allocs, 1 frees, 5,208 bytes allocated.
==3880== For counts of detected errors, rerun with: -v
==3880== searching for pointers to 14 not-freed blocks.
==3880== checked 69,340 bytes.
==3880==
==3880== 1,472 bytes in 8 blocks are still reachable in loss record 1 of 2
==3880==at 0x401DBE6: memalign (vg_replace_malloc.c:332)
==3880==by 0x401DC75: posix_memalign (vg_replace_malloc.c:386)
==3880==by 0x406F287: (within /usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x406FC9A: g_slice_alloc (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x404102A: g_ptr_array_sized_new (in 
/usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x4041071: g_ptr_array_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x40598F6: g_main_context_new (in 
/usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x4059AB8: g_main_context_default (in 
/usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x405A2E4: g_main_loop_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x804856B: main (in 
/home/seb/slask/snippits/c/glib2.0/main-loop-leak)
==3880==
==3880==
==3880== 3,724 bytes in 6 blocks are still reachable in loss record 2 of 2
==3880==at 0x401DA06: calloc (vg_replace_malloc.c:279)
==3880==by 0x406051D: g_malloc0 (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x405989F: g_main_context_new (in 
/usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x4059AB8: g_main_context_default (in 
/usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x405A2E4: g_main_loop_new (in /usr/lib/libglib-2.0.so.0.1000.3)
==3880==by 0x804856B: main (in 
/home/seb/slask/snippits/c/glib2.0/main-loop-leak)
==3880==
==3880== LEAK SUMMARY:
==3880==definitely lost: 0 bytes in 0 blocks.
==3880==  possibly lost: 0 bytes in 0 blocks.
==3880==still reachable: 5,196 bytes in 14 blocks.
==3880== suppressed: 0 bytes in 0 blocks.
0 [EMAIL PROTECTED] /home/seb/tmp


The way I read this, g_main_loop_new() is allocating memory and not
freeing it, even though I quit the loop and unref it.  Clue in a helpless
noob, what's going on here?


This is with 2.10.3, by the way, on a Debian Etch/Sid system.


-- 
Sebastian Kuzminsky  FUSION OF BRUNDLEFLY AND TELEPORTER POD SUCCESSFUL
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

Re: how do I plug this glib main loop memory leak?

2006-07-25 Thread Tristan Van Berkom

Sebastian Kuzminsky wrote:
[...]

The way I read this, g_main_loop_new() is allocating memory and not
freeing it, even though I quit the loop and unref it.  Clue in a helpless
noob, what's going on here?

  


The way I'm reading that trace, the g_main_loop_new() function when called
the first time; ensures that glib has a default GMainContext, that 
GMainContext
is used for every consecutive call to g_main_loop_new().

I dont think that the internal default context counts as a memory leak...

Cheers,
-Tristan

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

Is this TreeModel memory leak or something wrong in my code???

2006-05-18 Thread Viktors Petrovs

Hello,
i'm trying to use GtkListStore. I'm calling this function many times (i
use timer) and i see growing memory used by my program in Gnome System
Monitor.
What am i doing wrong?



void test_add_delete_line (void)
{
GtkWidget *TreeView = lookup_widget (GTK_WIDGET (MainWindow),
TestTreeView);
GtkListStore *Model = GTK_LIST_STORE (gtk_tree_view_get_model
(GTK_TREE_VIEW (TreeView))); 

GtkTreeIter iter;

// append row 
gtk_list_store_append (Model, iter);
// add some data
gtk_list_store_set (Model, iter, 0, test, 0, 0, 0, 0, 0);

// remove row
gtk_list_store_remove (Model, iter);
}




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

Is this TreeModel memory leak or something wrong in my code???

2006-05-18 Thread Viktors Petrovs

Hello,
i'm trying to use GtkListStore. I'm calling this function many times (i
use timer) and i see growing memory used by my program in Gnome System
Monitor.
What am i doing wrong?



void test_add_delete_line (void)
{
GtkWidget *TreeView = lookup_widget (GTK_WIDGET (MainWindow),
TestTreeView);
GtkListStore *Model = GTK_LIST_STORE (gtk_tree_view_get_model
(GTK_TREE_VIEW (TreeView)));

GtkTreeIter iter;

// append row 
gtk_list_store_append (Model, iter);
// add some data
gtk_list_store_set (Model, iter, 0, test, 0, 0, 0, 0, 0);

// remove row
gtk_list_store_remove (Model, iter);
}





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

Re: GLib/GModule Memory Leak? [now also GThread]

2006-04-25 Thread Nathaniel McCallum

I reran after implementing my app using GThreads and still got the
attached results after using: env G_DEBUG=gc-friendly
G_SLICE=always-malloc valgrind --leak-check=full --show-reachable=yes.
Notice also that there may be a small leak with g_thread_create().  Of
course this could also be how I'm using it.  However, my usage is fairly
simple: I just create one thread to do a download, I process some stuff
in the foreground and then do a join() when I need the content from the
download.  Anyway, thanks for the help so far.

Nathaniel

On Sun, 16 Apr 2006, Kalle Vahlman wrote:
On 4/15/06, Nathaniel McCallum npmccallum gentoo org wrote:
 I hope this is the right list to ask this on.  I ran valgrind on an
 application I'm developing with glib using gmodule.  Results attached.

I'm under the impression that valgrind and the new slice allocator
code do not really mix. There is a way to turn it to mallocs for
memory debugging, see

  http://developer.gnome.org/doc/API/2.0/glib/glib-running.html

and G_SLICE for details.

 Am I just worried about something that's not a big deal or is this a bug
 I should file?

Most likely no, but if you rerun with the always-malloc you should know better.
==24649== Memcheck, a memory error detector.
==24649== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al.
==24649== Using LibVEX rev 1471, a library for dynamic binary translation.
==24649== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP.
==24649== Using valgrind-3.1.0, a dynamic binary instrumentation framework.
==24649== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al.
==24649== For more details, rerun with: -v
==24649== 
==24649== 
==24649== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 101 from 1)
==24649== malloc/free: in use at exit: 26,289 bytes in 321 blocks.
==24649== malloc/free: 62,943 allocs, 62,622 frees, 2,704,716 bytes allocated.
==24649== For counts of detected errors, rerun with: -v
==24649== searching for pointers to 321 not-freed blocks.
==24649== checked 10,952,536 bytes.
==24649== 
==24649== 8 bytes in 2 blocks are still reachable in loss record 1 of 17
==24649==at 0x40051F9: malloc (vg_replace_malloc.c:149)
==24649==by 0xBE6CD2: _dl_map_object_from_fd (in /lib/ld-2.4.so)
==24649==by 0xBE8118: _dl_map_object (in /lib/ld-2.4.so)
==24649==by 0xBEBCA5: openaux (in /lib/ld-2.4.so)
==24649==by 0xBED6C8: _dl_catch_error (in /lib/ld-2.4.so)
==24649==by 0xBEC245: _dl_map_object_deps (in /lib/ld-2.4.so)
==24649==by 0xBF1172: dl_open_worker (in /lib/ld-2.4.so)
==24649==by 0xBED6C8: _dl_catch_error (in /lib/ld-2.4.so)
==24649==by 0xBF0C19: _dl_open (in /lib/ld-2.4.so)
==24649==by 0xD59E03: dlopen_doit (in /lib/libdl-2.4.so)
==24649==by 0xBED6C8: _dl_catch_error (in /lib/ld-2.4.so)
==24649==by 0xD5A3FF: _dlerror_run (in /lib/libdl-2.4.so)
==24649== 
==24649== 
==24649== 20 bytes in 1 blocks are still reachable in loss record 2 of 17
==24649==at 0x40045EB: calloc (vg_replace_malloc.c:279)
==24649==by 0xD5A45D: _dlerror_run (in /lib/libdl-2.4.so)
==24649==by 0xD59D48: dlopen@@GLIBC_2.1 (in /lib/libdl-2.4.so)
==24649==by 0xDD5558: g_module_open (in /usr/lib/libgmodule-2.0.so.0.1000.2)
==24649==by 0x8049BFE: main (noweb.c:49)
==24649== 
==24649== 
==24649== 32 bytes in 1 blocks are still reachable in loss record 3 of 17
==24649==at 0x40052ED: realloc (vg_replace_malloc.c:306)
==24649==by 0x99D5FA: g_realloc (in /usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x97E220: (within /usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x97E5A3: g_array_set_size (in /usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x9B43CC: g_static_private_set (in 
/usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x9BA4ED: g_get_charset (in /usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x981307: g_get_filename_charsets (in 
/usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x981530: (within /usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x9B44C4: g_thread_init_glib (in 
/usr/lib/libglib-2.0.so.0.1000.2)
==24649==by 0x3F618D: g_thread_init (in /usr/lib/libgthread-2.0.so.0.1000.2)
==24649==by 0x8049B5F: main (noweb.c:37)
==24649== 
==24649== 
==24649== 79 bytes in 1 blocks are still reachable in loss record 4 of 17
==24649==at 0x40052ED: realloc (vg_replace_malloc.c:306)
==24649==by 0xC58ADE: vasprintf (in /lib/libc-2.4.so)
==24649==by 0xC4035D: asprintf (in /lib/libc-2.4.so)
==24649==by 0xD5A24C: dlerror (in /lib/libdl-2.4.so)
==24649==by 0xDD4FFE: (within /usr/lib/libgmodule-2.0.so.0.1000.2)
==24649==by 0xDD51ED: g_module_symbol (in 
/usr/lib/libgmodule-2.0.so.0.1000.2)
==24649==by 0xDD5665: g_module_open (in /usr/lib/libgmodule-2.0.so.0.1000.2)
==24649==by 0x8049BFE: main (noweb.c:49)
==24649== 
==24649== 
==24649== 96 bytes in 3 blocks are still reachable in loss record 5 of 17
==24649==at 0x40051F9: malloc (vg_replace_malloc.c:149)
==24649==by 0xBF156A: dl_open_worker

Re: GLib/GModule Memory Leak?

2006-04-16 Thread Kalle Vahlman

On 4/15/06, Nathaniel McCallum [EMAIL PROTECTED] wrote:
 I hope this is the right list to ask this on.  I ran valgrind on an
 application I'm developing with glib using gmodule.  Results attached.

I'm under the impression that valgrind and the new slice allocator
code do not really mix. There is a way to turn it to mallocs for
memory debugging, see

  http://developer.gnome.org/doc/API/2.0/glib/glib-running.html

and G_SLICE for details.

 Am I just worried about something that's not a big deal or is this a bug
 I should file?

Most likely no, but if you rerun with the always-malloc you should know better.

--
Kalle Vahlman, [EMAIL PROTECTED]
Powered by http://movial.fi
Interesting stuff at http://syslog.movial.fi
___
gtk-devel-list mailing list
gtk-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-devel-list

RE: Will this create a memory leak? Can't determine from top.

2005-07-01 Thread Freddie Unpenstein


 As I understand it string = g_strdup_printf(... produces a copy and
 points string towards that copy, the adress of the copy is then
 passed on by g_signal_connect as the data pointer, hence freeing
 string destroys the string and should not be done (and doing it
 produces random output in the print_button callback).

Plenty of people suggested using a weak reference to free the string data.  But 
since the string is attached to the signal, why not let the signal clean up the 
string itself?

gulong g_signal_connect_data (gpointer instance, const gchar *detailed_signal, 
GCallback c_handler, gpointer data, GClosureNotify destroy_data, GConnectFlags 
connect_flags);

I haven't actually needed to do something like that myself, but it's sitting 
there in the APIs just waiting for someone to use it!  According to the API's, 
the GClosureNotify receives your data as its one and only argument, which makes 
it a perfect place to stick g_free().


Fredderic

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


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

Re: Will this create a memory leak? Can't determine from top.

2005-06-28 Thread Tristan Van Berkom


Bartek Kostrzewa wrote:

Should I define an array of char pointers
*message[TABLE_SIZE][TABLE_SIZE] to hold the pointers created by
g_strdup_printf or would that just be a waste of memory?


   I guess you want to free the string when the object emmiting the
signal is finalized, in that case you can use a function like
g_object_weak_ref like so:

===
void
free_signal_string (gpointer data,
GObject *where_the_object_was)
{
/* free the string here */
g_free (data);
}

/*
 .
 .
 .
 */
string = g_strdup_printf (...);
g_signal_connect(button[i][j], clicked,
 G_CALLBACK(print_position), string);

/* Hook onto buttons finalization */
g_object_weak_ref (G_OBJECT (button[i][j]),
   free_signal_string, string);
===

Ofcourse you could think up a million solutions for this
problem and they could all be good.

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

Re: Will this create a memory leak? Can't determine from top.

2005-06-28 Thread Tristan Van Berkom


Tristan Van Berkom wrote:

Bartek Kostrzewa wrote:


Should I define an array of char pointers
*message[TABLE_SIZE][TABLE_SIZE] to hold the pointers created by
g_strdup_printf or would that just be a waste of memory?



   I guess you want to free the string when the object emmiting the
signal is finalized, in that case you can use a function like
g_object_weak_ref like so:


Come to think of it, you can make it even simpler by just doing:

  g_object_weak_ref (G_OBJECT (button[i][j]),
 (GWeakNotify)g_free, string);

Cheers,
-Tristan

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

RE: How to deal with a possible Memory Leak when using GdkPixMap

2005-06-02 Thread Freddie Unpenstein


 I have written a program pretty much by re-adjusting the scribble
 example from the GTK Tutorial, instead of creating my own PixMap in
 the configure_event I called the following function which creates a
 pixmap from file:

pixbuf = gdk_pixbuf_new_from_file(filename,NULL);

There's yor CPU hog...!


 I have this function called everytime expose_event is called
 because the file that will get displayed in the drawing area keeps
 getting updated by another program.

Are you sure you need to reload the image EVERY time your expose event gets 
called?

At the very least, user stat() to check whether the last modified time on the 
image file has been changed, and only re-load it when neccesary.

You may also find, though, that part of the image gets updated with the new 
image, while part of it remains the old one (unles you're updating the entire 
thing every expose event, which itself would be a CPU hog).


 As the program runs and I move the mouse around the screen making
 marks my CPU activity jumps dramatically and the virtual memory
 occupied by the X-Window seems to be increasing on like an
 exponential level.

Making a mark shouldn't be too taxing...  Unless, as I said, you're updating 
the entire drawing area each time.  In either case, you should only be updating 
the smallest part of the drawing area you need to.


As far as updating the background image is concerned, I'd most definately do 
that from a timer, instead of from the expose event.  Every couple of seconds, 
or several times a second, or whatever, check to see if the file has changed 
(date and size), and if so, re-load the image and refresh the entire drawing 
area (which causes a full expose event).


Fredderic

___
Join Excite! - http://www.excite.com
The most personalized portal on the Web!


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

41 matches

Mail list logo