Re: How to confirm a memory leak

tein 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

Re: How to confirm a memory leak

supp --leak-check=yes ./myprogram And hopefully you'll see "0 bytes definitely lost". John On 28 July 2016 at 17:18, Norman Goldstein wrote: I'd like to understand how to confirm a potential memory leak in gtk3. Valgrind shows a definite leak, and "top" shows a

Re: How to confirm a memory leak

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 wrote: >>> >>> I'd like to u

Re: How to confirm a memory leak

. 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 wrote: I'd like to understand how to confirm a potential memory leak in gtk3. Val

Re: How to confirm a memory leak

ed 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 wrote: > I'd like to understand how to con

How to confirm a memory leak

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 ma

Re: Help with GtkBuilder memory leak

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

Re: Help with GtkBuilder memory leak

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

Re: Help with GtkBuilder memory leak

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

Re: Help with GtkBuilder memory leak

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

Help with GtkBuilder memory leak

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

RE: Pygobject memory leak in set_property?

This is a memory leak in pygobject. Lots leaks were fixed in get_property() last release [1] but set_property() still needs work [2]. -Simon [1] https://bugzilla.gnome.org/show_bug.cgi?id=726999#c7 [2] https://bugzilla.gnome.org/show_bug.cgi?id=735018 Thank you

Re: Pygobject memory leak in set_property?

On Fri, Jan 2, 2015 at 1:29 PM, Colin Myers wrote: > Yes, the memory increase is in proportion with the size of the text. > > > > But it is more likely to be an error in my understanding than a pygobject or > gtk bug – this is usually the case… This is a memory leak in pyg

RE: Pygobject memory leak in set_property?

Myers Cc: gtk-app Subject: Re: Pygobject memory leak in set_property? Hello, How big is the memory increase? set_text() allocates memory for text, which might be the cause. Best, Gergely On 1 Jan 2015 22:55, "Colin Myers" mailto:colin.my...@tabernus.com>> wrote: Hello list, I&#

Re: Pygobject memory leak in set_property?

Hello, How big is the memory increase? set_text() allocates memory for text, which might be the cause. Best, Gergely On 1 Jan 2015 22:55, "Colin Myers" wrote: > Hello list, > > I've been wrangling with a leak in my Pygobject/Gtk application and > believe the following lines of python demonstrat

Pygobject memory leak in set_property?

Hello list, I've been wrangling with a leak in my Pygobject/Gtk application and believe the following lines of python demonstrate the problem: from gi.repository import Gtk cell = Gtk.CellRendererText() text = 'Hello world' while True: cell.set_property('text', text) No new python objects

Re: GTK 2.24.10 memory leak on win32?

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_id

Re: GTK 2.24.10 memory leak on win32?

> > ... 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 -- Bye, Gabry ___

Re: GTK 2.24.10 memory leak on win32?

On 2 July 2012 15:44, Gabriele Greco 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_

Re: GTK 2.24.10 memory leak on win32?

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

Re: GTK 2.24.10 memory leak on win32?

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 (

GTK 2.24.10 memory leak on win32?

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

Re: memory leak on windows

On Mon, Mar 05, 2012 at 10:32:03AM +0400, Igor Chetverovod wrote: > Hi Gaetano, > you are right - this application steals memory. > I compiled it by mingw g++ with gtk+-bundle_2.24.10-20120208_win32.zip. > About 8 kByte per second for WinXP. > > Best regards, > > Igor Thank you for your testing.

Re: memory leak on windows

2012/3/2, Gaetano Guerriero : > Greetings, > this code leaks memory on Windows XP until the program crashes after some > minutes: > === > #include "gtk/gtk.h" > > static gboolean progressbar_pulse(gpointer data) { > gtk_progress_bar_pulse(GTK_PROGRESS_BAR(data)); > retur

Re: memory leak on windows

On Fri, 2 Mar 2012, Gaetano Guerriero wrote: this code leaks memory on Windows XP until the program crashes after some minutes [...] Well, using GTK 2.24.9 on Linux the program runs cleanly (no leaks) as verified by valgrind, after a minor modification to make it close down properly when the

memory leak on windows

Greetings, this code leaks memory on Windows XP until the program crashes after some minutes: === #include "gtk/gtk.h" static gboolean progressbar_pulse(gpointer data) { gtk_progress_bar_pulse(GTK_PROGRESS_BAR(data)); return TRUE; } int main(int argc, char *argv[]) {

Re: memory leak in PangoLayout?

On 05/06/2011 09:28 AM, Olivier Sessink wrote: Hi all, valgrind reports a memory leak in the following code: gint widget_get_string_size(GtkWidget * widget, gchar * string) { PangoLayout *layout; gint retval = -1; layout = gtk_widget_create_pango_layout(widget, string); if (layout != NULL

Re: memory leak in PangoLayout?

On 05/07/2011 12:00 AM, Bill C wrote: On 06/05/11 17:28, Olivier Sessink wrote: Hi all, valgrind reports a memory leak in the following code: gint widget_get_string_size(GtkWidget * widget, gchar * string) { PangoLayout *layout; gint retval = -1; layout = gtk_widget_create_pango_layout(widget

Re: memory leak in PangoLayout?

On 06/05/11 17:28, Olivier Sessink wrote: Hi all, valgrind reports a memory leak in the following code: gint widget_get_string_size(GtkWidget * widget, gchar * string) { PangoLayout *layout; gint retval = -1; layout = gtk_widget_create_pango_layout(widget, string); if (layout

memory leak in PangoLayout?

Hi all, valgrind reports a memory leak in the following code: gint widget_get_string_size(GtkWidget * widget, gchar * string) { PangoLayout *layout; gint retval = -1; layout = gtk_widget_create_pango_layout(widget, string); if (layout != NULL

Re: gtk_widget_destroy(my_window) memory leak

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 st

gtk_widget_destroy(my_window) memory leak

Hello, Have ever reported the memory leak of gtk_widget_destroy? I facing the memory leak after gtk_widget_destroy (my-gtk-window). Memory leak occurs, thogh my window does not contain any widget. my codes is as below: = #include

Memory leak in pixbuf?

Hi! I try reproduce error #584944 (gnome bugzilla) as clean experiment, and when use code from gtk-demo, i resive simular results: with show animation from file loaded progressive ( http://0lvins-experements.googlecode.com/svn/trunk/c/pixpuf-gtk/main-anim.c): memory usage grow and free only on g_

Re: GKeyFile memory leak on Windows ?

Fixed now in git, bug #621168. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list

GKeyFile memory leak on Windows ?

try this little prog on Windows xp: #include int main() { while(1) { GKeyFile *key = g_key_file_new(); g_key_file_free(key); } } It will eat up all memory. I can't find why. Could someone help me ? I think this maybe a memory

How Test Gtk GUI application memory leak and Property Chages

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 fi

memory leak https://bugzilla.gnome.org/show_bug.cgi?id=558594

Hello All, The bug 558594 does show a reproductible memory leak (on Linux/Debian/Sid with libgtk2.0-0 2.16.6-1). https://bugzilla.gnome.org/show_bug.cgi?id=558594 I did read the source code and did not found any apparent leak (that is, in my understanding of Gtk & Glib documentation, the

Re: valgrind reports memory leak on g_main_loop_run

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 mo

valgrind reports memory leak on g_main_loop_run

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_u

Re: Confusing about memory leak and GtkTreeView, GtkCellRendererCombo & GtkCellRendererSpin

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

Re: Confusing about memory leak and GtkTreeView, GtkCellRendererCombo & GtkCellRendererSpin

igits", 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 GObjectClas

Re: Confusing about memory leak and GtkTreeView, GtkCellRendererCombo & GtkCellRendererSpin

'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

Confusing about memory leak and GtkTreeView, GtkCellRendererCombo & GtkCellRendererSpin

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

Re: another memory leak

On Fri, 31 Oct 2008, Alexander Semenov wrote: > Jacques Le Normand wrote: > > thank you for helping me to solve my previous post, which > > found that I had a memory leak. The solution was to remove uim > > (universal input method). I have a new memory leak problem. >

Re: another memory leak

Jacques Le Normand wrote: Hello list, thank you for helping me to solve my previous post, which found that I had a memory leak. The solution was to remove uim (universal input method). I have a new memory leak problem. This one creates and removes 2000 text entries every 100ms. I've ha

Re: another memory leak

thank you for helping me to solve my previous post, which found that I > > had a memory leak. The solution was to remove uim (universal input > > method). > > Would you say more about the solution in the list? I am also interested > in it but don't know why there is a leak.

Re: another memory leak

On Wed, 2008-10-29 at 22:08 -0400, Jacques Le Normand wrote: > Hello list, > thank you for helping me to solve my previous post, which found that I > had a memory leak. The solution was to remove uim (universal input > method). Would you say more about the solution in the lis

Re: memory leak when destroying widgets

On Mon, 2008-10-27 at 16:50 -0400, Dave Foster wrote: > Hi, > > On Mon, Oct 27, 2008 at 4:22 PM, Jacques Le Normand <[EMAIL PROTECTED]>wrote: > > > > >gtk_container_remove(GTK_CONTAINER(vbox),child); > > > > Most likely I am wrong on this, but you solely do a container remove, and > not a de

Re: memory leak when destroying widgets

turns out there were two problems: I forgot to free the GList* uim caused a memory leak fixing these two problems fixed the memory leak cheers --Jacques On Mon, Oct 27, 2008 at 4:50 PM, Dave Foster <[EMAIL PROTECTED]> wrote: > Hi, > > On Mon, Oct 27, 2008 at 4:22 PM, Jacques Le

Re: memory leak when destroying widgets

Hi, On Mon, Oct 27, 2008 at 4:22 PM, Jacques Le Normand <[EMAIL PROTECTED]>wrote: > >gtk_container_remove(GTK_CONTAINER(vbox),child); > Most likely I am wrong on this, but you solely do a container remove, and not a delete/free etc on something that was created with entry_new(). I'm fairly

memory leak when destroying widgets

Hello list I have this short program that's leaking memory (according to top). Could someone tell me what I'm doing wrong? The program simply creates, packs and shows 100 gtk_entries and then destroys them at 400 ms intervals I appreciate any help you can give P.-S. I didn't know which list to send

possible memory leak help.

Hi, I have a memory leak problem which I can't seem to understand. I have a GtkTreeview/ GtkTreeModelFilter/ GtkTreeStore setup. I have traced it to a case where memory leaks when I call "gtk_tree_store_set" multiple times. Here is a snipnet of my code demonstrating the problem

A memory leak problem in GtkTextView

Hi, I'm facing a problem in the use of GtkTextView. When I insert a image into the GtkTextView, there is an explicit memory leak problem. Some source code is as follow: // image=gtk_image_new_from_file(path); gtk_widget_show(image); anchor = gtk_text_buffer_create_child_a

Memory leak

Hi, I am seeing a memleak being reported when I run valgrind against my app. The trace is: at 0x4023D6E: malloc (in /usr/lib/valgrind/x86-linux/vgpreload_memcheck.so) by 0x482F1F3: g_malloc (in /usr/lib/libglib-2.0.so.0.1600.3) by 0x449899F: gtk_tree_model_filter_build_level (in /usr/lib/libgtk-

Re: memory leak in gtk

l like valgrind with a large gtk-specific suppression file. A memory leak is a memory leak, but it's only those leaks that accumulate that are a problem. Sometimes I'll use a memory profiler and make sure my program's memory use doesn't increase beyond bounds. One trick i

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

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 th

Re: memory leak in gtk

Junior Polegato - GTK+ & GTKmm wrote: > 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.

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

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

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

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

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

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 w

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

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

Re: memory leak in gtk

to keep this email for reference. Thanks, Michael On 24/11/2007, c f <[EMAIL PROTECTED]> wrote: > Hi, > > In my opinion the definition what you have given describes well when a > memory leak can cause serious problems but I would call memory > leak,any dynamically allocated mem

Re: memory leak in gtk

Hi, In my opinion the definition what you have given describes well when a memory leak can cause serious problems but I would call memory leak,any dynamically allocated memory what is not freed when you are done with it . However it is true that OS will cleanup everything when the program

Re: memory leak in gtk

> > I have used mtrace to check for memory leaks. In this simple > > application there are more than 5000 memory allocation which is not > > freed. Note that just a dynamic memory allocation that isn't freed before the application terminates is not a leak, in case there still exists a way to acces

Re: memory leak in gtk

On Wed, 21 Nov 2007 20:15:25 +0100 c f wrote: [...] > I have used mtrace to check for memory leaks. In this simple > application there are more than 5000 memory allocation which is not > freed. See: http://www.gtk.org/faq/#AEN703 > I have checked the GTK documentation and it states that gtk_ex

Re: memory leak in gtk

Hi Michael, Thanks for your suggestion. Actually I have not mentioned but I also tried to decrease the ref count of the mainWindow (just to be sure). In theory it is already destroyed at this point as the main quit is called in the destoyed handler of the main window. In that case (unref), GTK sh

Re: memory leak in gtk

I'm no master profiler but I think that you'll want to put a gtk_widget_destroy(mainWindow); after the gtk_main();. You really don't need to do this because it will be destroyed when the application terminates 0.01 seconds after that line. But if you feel you must then go for it. I also like to

memory leak in gtk

Hi, I have made a simple application with a top level window: " #include #include gboolean OnDeleteHandler(GtkWidget *sender, GdkEvent *event, gpointer data) { return FALSE; } void OnDestroyHandler(GtkWidget *sender, gpointer data)

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

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

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

he 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 pr

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

he 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 t

is there a memory leak problem with gtk_widget_queue_draw()?

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 probl

Re: memory leak with gtk+-2.8.20-r1

On Sun, 2006-08-06 at 20:55 +0200, Vincent Torri wrote: > > > > >> ==29096==still reachable: 41,380 bytes in 618 blocks. > > That's completely normal. Surely they're static variables holding > > pointers to freed memory. > > maybe this comes from glib memory allocator. I have such results wit

Re: memory leak with gtk+-2.8.20-r1

> >> ==29096==still reachable: 41,380 bytes in 618 blocks. > That's completely normal. Surely they're static variables holding > pointers to freed memory. maybe this comes from glib memory allocator. I have such results with gstreamer too Vincent ___

Re: memory leak with gtk+-2.8.20-r1

On Sun, 2006-08-06 at 14:07 +0200, gwenj wrote: > The result to valgrind is : > ==29096== LEAK SUMMARY: > ==29096==definitely lost: 0 bytes in 0 blocks. Nothing malloc'ed and not freed. > ==29096== possibly lost: 800 bytes in 20 blocks. This may be investigated further, but I bet they are

Re: memory leak with gtk+-2.8.20-r1

On Sun, 2006-08-06 at 11:38 +0200, David Nečas (Yeti) wrote: > On Sun, Aug 06, 2006 at 09:45:00AM +0200, Iago Rubio wrote: > > > > I've just compiled and run this code snippet with valgrind, and the > > results are on my system (Fedora): > > > > ERROR SUMMARY: 0 errors from 0 contexts (suppressed

Re: memory leak with gtk+-2.8.20-r1

terior of the analyzed block that may have pointed to the start of the > block and have been moved, among other possible causes, such as debug > padding - where a pointer to an object is returned as the start + > padding of the memory block as with pymalloc and python debug builds. > &

Re: memory leak with gtk+-2.8.20-r1

On Sun, 06 Aug 2006 09:45:00 +0200 Iago Rubio <[EMAIL PROTECTED]> wrote: > On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote: > > Hello, > > I use gtk+ for my soft's graphic interface. > > But valgrind make an log file containing approximately 22700 lines for an > > simple source code like : > > #in

Re: memory leak with gtk+-2.8.20-r1

On Sun, 6 Aug 2006, Iago Rubio wrote: > The 'possibly lost' bites means - AFAIK - that exists pointers to the > interior of the analyzed block that may have pointed to the start of the > block and have been moved, among other possible causes, such as debug > padding - where a pointer to an object

Re: memory leak with gtk+-2.8.20-r1

terior of the analyzed block that may have pointed to the start of the > block and have been moved, among other possible causes, such as debug > padding - where a pointer to an object is returned as the start + > padding of the memory block as with pymalloc and python debug builds. > &

Re: memory leak with gtk+-2.8.20-r1

to the start of the block and have been moved, among other possible causes, such as debug padding - where a pointer to an object is returned as the start + padding of the memory block as with pymalloc and python debug builds. >From this output I would not bet that exists - for sur

Re: memory leak with gtk+-2.8.20-r1

On Sun, Aug 06, 2006 at 09:45:00AM +0200, Iago Rubio wrote: > > I've just compiled and run this code snippet with valgrind, and the > results are on my system (Fedora): > > ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 12 from 1) > malloc/free: in use at exit: 0 bytes in 0 blocks. > malloc

Re: memory leak with gtk+-2.8.20-r1

On Sun, 06 Aug 2006 09:45:00 +0200 Iago Rubio <[EMAIL PROTECTED]> wrote: > On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote: > > Hello, > > I use gtk+ for my soft's graphic interface. > > But valgrind make an log file containing approximately 22700 lines for an > > simple source code like : > > #in

Re: memory leak with gtk+-2.8.20-r1

On Fri, 2006-08-04 at 13:25 +0200, gwenj wrote: > Hello, > I use gtk+ for my soft's graphic interface. > But valgrind make an log file containing approximately 22700 lines for an > simple source code like : > #include > > int main(int argc, char **argv) { > gtk_init(&argc, &argv); >

memory leak with gtk+-2.8.20-r1

Hello, I use gtk+ for my soft's graphic interface. But valgrind make an log file containing approximately 22700 lines for an simple source code like : #include int main(int argc, char **argv) { gtk_init(&argc, &argv); GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);

memory leak with gtk+-2.8.20-r1

Hello, I use gtk+ for my soft's graphic interface. But valgrind make an log file containing approximately 22700 lines for an simple source code like : #include int main(int argc, char **argv) { gtk_init(&argc, &argv); GtkWidget *win= gtk_window_new(GTK_WINDOW_TOPLEVEL);

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

w() 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,

how do I plug this glib main loop memory leak?

I'm not understanding something about the glib main loop and reference counting. I've got this trivial program that does nothing: - begin - #include #include #include GMainLoop* main_loop = NULL; void signal_handler(int signo) { printf("caught signal %d

pango memory leak

hello all, futher to my previous mail about a memory leak that i suspect in the pango_font_description_set_family and pango_font_description_set_size functions, i observe that the leak exists in the latest version of pango. i am using fedora core 4 with pango version 1.8.1. in my program

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

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

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

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

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

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

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

On Tue, 2005-06-28 at 10:43 -0400, Tristan Van Berkom wrote: > 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 mem

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

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

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

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 c

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

> 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? Obviously I would then produce this at the end of the program: /* lets free all memory */ for(i = 0; i < TABLE_SIZE; i++)

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

Hi, I'm a starting C/Gtk programmer trying to avoid mistakes. Would the following create a memory leak or would glib prevent it? (it seems it does, the RES memory use grows and then stops growing even though I continue pounding on the buttons) for(i = 0; i < TABLE_SIZE; i++) {

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

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

How to deal with a possible Memory Leak when using GdkPixMap

Hi, 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: GdkPixmap* gdk_pixmap_new_from_file( const char *filename ) { Gdk

Memory leak problem

Hi all. Please check this code fragment: pxb = gdk_pixbuf_new_from_file(path, &err); // Check if the image was previously allocated. If so, destroy it // Note that this relies on the pxb being destroyed too. It seems // this does _not_ happen (Valgrind indicate this) if (img_item) gtk_o

  1   2   >