GtkBuilder causing memory leaks?
The following code spawns a window --
if (connect_build_object != NULL) {
g_object_unref (G_OBJECT ( connect_build_object ));
object = NULL;
}
connect_build_object = gtk_builder_new();
gtk_builder_add_from_file ( connect_build_object,
main_window.glade, NULL );
gtk_builder_connect_signals ( connect_build_object, NULL );
connect_window = GTK_WIDGET ( gtk_builder_get_object (
connect_build_object, connec ) );
gtk_widget_show ( connect_window );
Where connect_build_object is a global variable.
Before spawning, it's checked if connect_build_object is initilized, if
that's the case, its destroyed by g_object_unref.
Closing the window calls the default handler.
Problem: Each time I open and close a window, memory usage increases.
I don't understand the problem. Please help!
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: g_idle_add source memory leaks
On 05/09/2011 01:36 PM, Gabriele Greco wrote:
just a note on your example code: use the GPOINTER_TO_INT and
GINT_TO_POINTER macro's to avoid 64bit portability problems:
gboolean mycbk(gpointer data)
{
gint val = GPOINTER_TO_INT(data);
char buffer[16];
sprintf(buffer, %09d, val);
gtk_label_set_text(l, buffer);
return FALSE;
}
void threadfunc(void *unused) {
gint msec = 0;
while (1) {
msec++;
g_usleep(1000);
g_idle_add((GSourceFunc)mycbk, GINT_TO_POINTER(msec));
}
}
Olivier
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
g_idle_add source memory leaks
If I use g_idle_add to send to my main thread that does the GTK rendering
some notifications I have to free the source handle that the function
returns to me every time or not to avoid a memory leak?
Here is a simple code example, that seems not to leak on linux (ps gives
constant resource occupation, gtk 2.22), but it seems to leak on win32 (task
manager mem usage grows, gtk 2.16):
#include gtk/gtk.h
GtkLabel *l;
int mycbk(int val)
{
char buffer[16];
sprintf(buffer, %09d, val);
gtk_label_set_text(l, buffer);
return FALSE;
}
void threadfunc(void *unused) {
int msec = 0;
while (1) {
msec++;
g_usleep(1000);
g_idle_add((GSourceFunc)mycbk, (void *)msec);
}
}
int main(int argc, char *argv[]){
GtkWidget *w;
g_thread_init(NULL);
gtk_init(argc, argv);
g_thread_create((GThreadFunc)threadfunc, NULL, TRUE, NULL);
w = gtk_window_new(GTK_WINDOW_TOPLEVEL);
l = GTK_LABEL(gtk_label_new(-));
gtk_container_add(GTK_CONTAINER(w), GTK_WIDGET(l));
gtk_widget_show_all(w);
gtk_main();
return 0;
}
--
Ing. Gabriele Greco, DARTS Engineering
Tel: +39-0105761240 Fax: +39-0105760224
s-mail: Via G.T. Invrea 14 - 16129 GENOVA (ITALY)
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
FWIW I tracked sown the mechanism for suppressing leak detections in MSVC.
Basically, you can set checkpoints and only display the leaks between two
specified points. It might not be as flexible as the method used in Valgrind
but it's one helluva lot easier. Here's how I modified my original code:-
int main (int argc, char *argv[])
{
Gtk::Main app (argc, argv);
MainWindow mainWnd;
// g_thread initialisation here
mainWnd.set_title (Hello World !);
_CrtMemState state;// These two
_CrtMemCheckpoint ( state );// lines added
app.run ( mainWnd );
_CrtMemDumpAllObjectsSince ( state ); // Dumps the 'leaks'
return;
}
As you can see, I've told the dumper to ignore memory allocated during my
initialisation. This leaves me with around 80 leak reports, some of which are
very likely due to my own code. And although I don't see any g_warnings when I
run the app, some are probably down to similar entities that delayed their
initialisation until after app.run(). So let's say that ultimately, I can get
my list down to around 65 leaks. At least that's a lot more manageable than I
was seeing before! Hopefully this might help anyone who finds himself in the
same situation as me. I still think that some cleanup functionality would be
better though.
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 13/02/11 04:43, John Emmas wrote:
FWIW I tracked sown the mechanism for suppressing leak detections in MSVC.
Basically, you can set checkpoints and only display the leaks between two
specified points. It might not be as flexible as the method used in Valgrind
but it's one helluva lot easier. Here's how I modified my original code:-
int main (int argc, char *argv[])
{
Gtk::Main app (argc,argv);
MainWindow mainWnd;
// g_thread initialisation here
mainWnd.set_title (Hello World !);
_CrtMemState state;// These two
_CrtMemCheckpoint (state );// lines added
app.run ( mainWnd );
_CrtMemDumpAllObjectsSince (state ); // Dumps the 'leaks'
return;
}
As you can see, I've told the dumper to ignore memory allocated during my
initialisation. This leaves me with around 80 leak reports, some of which are
very likely due to my own code. And although I don't see any g_warnings when I
run the app, some are probably down to similar entities that delayed their
initialisation until after app.run(). So let's say that ultimately, I can get
my list down to around 65 leaks. At least that's a lot more manageable than I
was seeing before! Hopefully this might help anyone who finds himself in the
same situation as me. I still think that some cleanup functionality would be
better though.
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Seems a useful solution.. Thanks John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
I posted this the last time this subject came up (twice last year, I think), but I made this valgrind suppression file for my project: http://www.vips.ecs.soton.ac.uk/development/nip2.supp With this, I get no reported leaks in my huge (200,000 lines of C) application on Ubuntu with current gtk+. There are some comments in the file explaining what the various bits do. No doubt I've made some errors :-( but perhaps it might be useful. On 9 February 2011 17:01, James Morris jwm.art@gmail.com wrote: On 9 February 2011 16:10, Michael Cronenworth m...@cchtml.com wrote: James Morris wrote: How does one gain this mysterious tool for Linux? It's called Google. There's a web page[1] that details how to setup valgrind to debug gtk/glib apps and even a preliminary suppression file. [1] http://live.gnome.org/Valgrind That's called patronising. I have been there already. What good is a work in progress when the progress stopped over two years ago? Not only do we have to write our own code, we have to put work into making other peoples code ignore the errors in other peoples code so we can see the errors in our own code. It's a bloody outrage! ___ 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
Re: Memory leaks
Because malloc() implementations generally kept a linear linked list of free space, and traversed the list on a free() in case they found adjacent memory areas to the one you were freeing, which they could join together and make into a single larger area. I'm sorry, I now understand what you mean. If what you say is true (which I don't doubt) it's a really boneheaded mechanism in my opinion. Defragmenting memory in realtime is a performance nightmare. But that's irrelevant. Your point is well taken. However, consider a modern GUI app. It's allocating and freeing several orders of magnitude more pointers than are left at the end of the program. So, when you finally get to the end and have searched through all those heaps of pointers to free them and are stuck with only 200 (say) you just give up. It's like drowning near the shore. Plus, searching through a 200 pointer linked list should be an order of magnitude faster than ((200/n) * (what it takes to free the n pointers the program uses normally)). Assuming n is quite a bit larger than 200 (which IMHO is really not far-fetched). ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
Hi All On 10/02/11 18:26, John Emmas wrote: On 9 Feb 2011, at 17:01, James Morris wrote: Not only do we have to write our own code, we have to put work into making other peoples code ignore the errors in other peoples code so we can see the errors in our own code. It's a bloody outrage! I've never used Valgrind but I can fully understand how frustrating that would be and how unproductive. Surely everybody agrees that tracking down genuine leaks in one's code is a good and desirable thing? And surely everybody agrees that having to jump through hoops like that in order to achieve it is an unproductive waste of the programmer's time? Full marks to Valgrind for providing the feature - but it shouldn't excuse sloppiness by other developers. A few years back I first used valgrind with GTK. On the Web I came across details on setting up an exception file; tried it and gave up. I think it is the wrong approach, and maybe explains why noone has bothered to update it in the last 2 years. I neglected to post the solution that worked for me I would say that valgrind is a very powerful tool, but requires good software engineering skills to use. It does not spoonfeed you an answer. My approach was to only look at leaked memory that I had allocated myself. Using this approach worked for my C generated from Legacy Pascal source, using my own compilation workbench. That is I know exactly what is happening outside of GTK2 as everything else is my code. (wrapper code, generated C code, database code or written subroutines) With an IDE and C++ you are introducing new variables. As with any debugging problem, what is needed is a minimal test program, so code with GTK and C and see what happens. Is the problem GTK or gtkmm? What happens on the latest Linux and Windows releases of GTK2 and GTK3. I dont think I use the calls you use, else I would give it a go. Also I am not using GTK3 or GTK under windows Rgds Bill ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
From: Carlos Pereira [jose.carlos.pere...@ist.utl.pt], Date: 10/02/2011 09:10: something), but aside from that it's a pure waste of CPU cycles. I am sorry, I totally disagree. I can only see two cases. Either fixing these hundreds and hundreds of mem leaks is easy or difficult. In the first case, is just a question of plain laziness and bad programming practises. The second case is much worse, it means the code is badly designed. A leak is a resource that outlives its lifetime, and becomes lost. Where are these leaks you're so worried about? Some of them can be recovered by shutting down services that were started due to being required by what you WERE doing. Those services will be shut down when there's no chance of needing them again. If that happens to be at application shutdown, then why not allow the OS to reclaim them in bulk, if doing so will properly and correctly recover those resources. As has already been pointed out at least once, memory allocated during initialisation (possibly of components required but otherwise independent from the one you were actually using) that isn't a progressively worsening problem during the applications lifetime (the definition of a leak), and will be properly released by the OS at application shutdown, the cost of manually releasing those resources can amount to a significant and utterly unnecessary waste of effort. Especially, and this is something I know about well as someone using older and limited hardware, if some of those resources or the referring structures thereof, are presently stored within swapped out memory. I really don't want to have to sit around for an extra 10-20 seconds while a closing application crawls along pulling data from swap space for no particularly good reason, when the OS could have simply marked those pages as available and been done with it. Fredderic ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
The basic idea that one must understand about programming is that of paradigms and concepts. They are really stressed for C++ and higher level stuff (scripting languages notwithstanding ofcourse). But if you're gonna use C you're gonna write paradigms and concepts that you'll really have to be ensure are coherent. You're definition of a leak is a hack in every way. When you define something in a program you call it by it's proper name. If it's a leak to libc, it's a leak to Valgrind, it's a leak from every programmatic point of view you can muster. It's a leak from the ground up. It's not a leak at all but one layer: the first. Sure, it won't matter most of the times but it's really messy. Nobody is arguing that manually cleaning up is more efficient. But why on earth would 200 pointers initialized and _used_ by GTK be likely to be found in swap (I may be slightly wrong, but just as a point of view). But, more importantly: as I mentioned before, let's compare apples with apples. When you close your program you're properly, manually freeing probably hundreds, thousands more pointers. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 10/02/11 19:50, Costin Chirvasuta wrote: I'm sorry, I now understand what you mean. If what you say is true (which I don't doubt) it's a really boneheaded mechanism in my opinion. Defragmenting memory in realtime is a performance nightmare. But that's irrelevant. Your point is well taken. To describe the standard mechanism of garbage collection as a boneheaded idea shows a total lack of awareness of first year Computer Science course principles. That garbage collection has been refined and highly optimised over the years is true; however it is a very necessary thing with modern compiler technology. Less so in the days of Cobol Liam - To have a problem with freeing up memory prior to exiting suggests that either you have a memory leak, or a bad design (or both). It might be your development environment. I once came across a compiler for a virtual memory minicomputer that implemented free() as a empty procedure. It allowed the system to keep allocating ram until the disc was full of swapped pages. My company lost a benchmark because it could not run the program. Our competitor run it but very slowly. The slights of hand, by definition are unseen. The compiler time to market was faster, and I never heard that the issue became public knowledge, or was fixed. Rgds Bill ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 10 Feb 2011, at 11:36, Freddie Unpenstein wrote: I really don't want to have to sit around for an extra 10-20 seconds while a closing application crawls along pulling data from swap space for no particularly good reason, when the OS could have simply marked those pages as available and been done with it. Which is exactly the reason why it should be optional. FWIW I came to gtk+ about 18 months ago after programming in MFC for almost 2 decades. gtk+ was quite a steep learning curve after the beautiful simplicity of MFC and I wouldn't by any means claim to have mastered gtk+. However, I've come to realise that the rewards of working with gtk+ are well worth persevering with the steep (and sometimes not very intuitive) learning curve. I'd have to say though that the difficulty of tracking my memory leaks is the first thing that's seriously made me question my move to gtk+. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
To describe the standard mechanism of garbage collection as a boneheaded idea shows a total lack of awareness of first year Computer Science course principles. That garbage collection has been refined and highly optimised over the years is true; however it is a very necessary thing with modern compiler technology. Less so in the days of Cobol Why would I want to program in C if I can't use manual memory management? Of course not manual as in having to use custom malloc/free implementations. There is a great penalty to garbage collection in many instances and one should have the option of not using it. Now that I know this about the malloc/free implementation I don't think of my coworkers at my ex-company as madmen for having written their own malloc/free implementation for our product. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 02/10/2011 12:19 AM, Costin Chirvasuta wrote: I find not cleaning up explicitly quite ugly. I shudder at the thought and maybe I'm not the only one. Not only that, but cleaning up explicitly is obviously useful for some people. I guess we're at an impasse then. The discussion has now moved from the definition of leak to some personal idea of what beauty is. I know that the standard glibc library does static allocations on program load that I don't free, and don't think that glibc frees them either. That in no way impacts the beauty or elegance of my code. Back to the original discussion, I'm sure if someone wanted to make some patches to make GTK+ pure reentrant, actual GTK+ developers would probably take a look, and benchmarks could be made. There are a few corner cases where a reentrant GTK would be very useful, such as in a plugin system, or maybe integration with other toolkits like Qt. Or it might turn out the most elegant solution is to use separate processes and bridge them using some form of IPC and shared memory. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 10 Feb 2011, at 17:48, Michael Torrie wrote: I guess we're at an impasse then. The discussion has now moved from the definition of leak to some personal idea of what beauty is. In which case, maybe we should agree to use the word leak for the simple purpose of identifying the characteristic we're discussing and not in any derogatory sense. To me, the debate has become something very simple when a program needs to allocate a block of memory only once, does the programmer necessarily have to release it programmatically or can he defer it to the OS? Remember we aren't specifically discussing memory that needs to persist for the lifetime of the program. Take my earlier example of g_message(). When you issue a g_message you have no way of knowing whether or not another g_message will follow later. And yet the allocated memory gets held open for the entire lifetime of the program. Some of the contributors here (me included) believe that this is just plain sloppy. Others aren't too bothered by it. Neither view is inherently right or wrong but it's clear there are as many devs holding one viewpoint as hold the other. So an optional counterpart to gtk_init() would seem to be an obvious way of pacifying both camps (or at least a good starting point, since that's where many of the leaks seem to originate).. The $64,000 question is whether anyone would make the effort to write it. Given the very large number of leaks (remember, 'leaks' is no longer a derogatory term!) finding them is bound to be a daunting task. But if it isn't done now it sure as hell won't get any easier to do in the future. If those aren't persuasive enough arguments for implementing such a function, there's another much more compelling argument - namely, gtkmm. In C++ programming there's a widespread expectation that when you delete an object it should release the memory that got allocated for it. If it doesn't there needs to be a very good justification for not doing so. IMHO, saying Sod it, leave it to the OS doesn't even come close to being a good justification. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Thu, Feb 10, 2011 at 07:28:40PM +, John Emmas wrote: To me, the debate has become something very simple when a program needs to allocate a block of memory only once, does the programmer necessarily have to release it programmatically or can he defer it to the OS? Remember we aren't specifically discussing memory that needs to persist for the lifetime of the program. Take my earlier example of g_message(). When you issue a g_message you have no way of knowing whether or not another g_message will follow later. And yet the allocated memory gets held open for the entire lifetime of the program. Some of the contributors here (me included) believe that this is just plain sloppy. Others aren't too bothered by it. And others, Gtk+ devs probably including, consider this a useful optimisation – and in many cases a necessity. You still do not seem to accept even the existence of this point of view. If those aren't persuasive enough arguments for implementing such a function, there's another much more compelling argument - namely, gtkmm. In C++ programming there's a widespread expectation that when you delete an object it should release the memory that got allocated for it. If it doesn't there needs to be a very good justification for not doing so. Remember we are talking about program-wide facility setup. How exactly you release GQuarks or static registered types (not instances!)? What objects are deleted? You do not want GTypes to be teared down if no object of this type exists because then two subsequent GTK_TYPE_WIDGETs might evaluate to different GTypes. The same applies to the logging system: if it registers handlers, opens files or whatever, this is program-wide. The ‘object’ that holds the memory is the main program – and when that's deleted the memory surely goes away too. While I agree having a clean-up function could be useful in some cases (dynamical modules with GUI) this ‘widespread expectation in C++’ stuff is just rubbish. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Thu, 2011-02-10 at 10:50 +0200, Costin Chirvasuta wrote: Because malloc() implementations generally kept a linear linked list of free space, and traversed the list on a free() in case they found adjacent memory areas to the one you were freeing, which they could join together and make into a single larger area. I'm sorry, I now understand what you mean. If what you say is true (which I don't doubt) it's a really boneheaded mechanism in my opinion. Defragmenting memory in realtime is a performance nightmare. But that's irrelevant. Your point is well taken. It was necessary on smaller machines. GNU malloc used to take he approach (may still) of using only powers of two for bucket sizes, which is faster (less fragmentation) but uses on average about twice as much memory if requested sizes are random. However, consider a modern GUI app. It's allocating and freeing several orders of magnitude more pointers than are left at the end of the program. So, when you finally get to the end and have searched through all those heaps of pointers to free them and are stuck with only 200 (say) you just give up. It's like drowning near the shore. Plus, searching through a 200 pointer linked list should be an order of magnitude faster than ((200/n) * (what it takes to free the n pointers the program uses normally)). Assuming n is quite a bit larger than 200 (which IMHO is really not far-fetched). A few million isn't unlikely for a GUI-based program - e.g. consider allocating an event structure whenever the mouse pointer moves. Remember that just because you free'd something doesn't mean it's gone -- it's still on the heap and available for reuse in that list. Some versions of malloc do try and return pages to the operating system under some circumstances, although the cost of doing that in performance is large, so you don't want to do it often. Also, Bill C wrote, Liam - To have a problem with freeing up memory prior to exiting suggests that either you have a memory leak, or a bad design (or both). It might be your development environment. Maybe it was bad -- System VR3 Unix, SunOS 4, IRIX, 4.3BSD etc etc. The situation was a program that allocated millions of small objects. The point still stands though - don't assume it's fast (or slow) until you've measured. The package itself did not, I think, have a badly designed memory architecture for its time, but maybe I just think that because I wrote it :-) There were no leaks -- I measured carefully and did in fact account for every item of memory. Well, I wrote a carefully-tested program to do it :-) Best, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 11/02/11 09:13, David Nečas wrote: While I agree having a clean-up function could be useful in some cases (dynamical modules with GUI) this ‘widespread expectation in C++’ stuff is just rubbish. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list I have been amazed by the expertise shown by posters to this thread and propose a solution. A stub gtk-tidy() be implemented as an empty procedure. People who want this function can investigate it and supply what is needed. Maybe the project could fork from GTK as GTKX where X indicates eXpert. It might later be merged back into GTK Open Source generally produces intelligent discussion which ends up producing excellent products such as GTK, and if GTKX is even better, then we all win. The people who want this can do it... A useful aspect of open source, as experience teaches. As an analogy, hairdressers make the world a better place... lots of women with beautiful hair cuts. A woman wants her head shaved, so the haiddresser does it, and the bald headed woman is happy for a while. An experienced hairdresser might have refused the job... You want your head shaved go somewhere else. Now our hairdresser has a test drive in an F1 car. Doesn't like the acceleration, not like her Ford. Well in this case, VB is the Ford and GTK the F1 car. There are not many F1 car drivers around, if you want to drive an F1 car, you have to learn how to handle it, dont complain about the acceleration. I think the best idea to come from this discussion is If you are having problems with free(), provide your own version of free(). If you implement this as an empty routine, many testing issues will disappear. List contributors wishing to increase their expertise will be amazed at how simple it is to fix basic errors they get which are caused by unreliable code outside of their control. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 10 Feb 2011, at 22:13, David Nečas wrote: And others, Gtk+ devs probably including, consider this a useful optimisation – and in many cases a necessity. You still do not seem to accept even the existence of this point of view. I would say quite the reverse. Every single person here who is arguing in favour a cleanup function is arguing for something that could be called optionally (and typically, on exit) as, and if, it was felt beneficial. Every one of them recognises that there are situations where it might be felt not to be beneficial. If anything, the problem is the other way around. Those people who are arguing against it will not even countenance the thought that it has any merit whatsoever - even though it's clear that many developers want this functionality; many have submitted very good arguments in its favour; and most of them have given good explanations of why they want it. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 8 Feb 2011, at 09:36, John Emmas wrote:
int main (int argc, char *argv[])
{
Gtk::Main *app = new Gtk::Main (argc, argv);
delete app;
return 0;
}
The above code causes hundreds of memory leaks.
I spent a few minutes on this (literally just a few) this morning, while I was
sipping my first coffee and still trying to wake up! During gtk_init() I
discovered a couple of places where g_strdup() gets used but the allocated
memory never gets freed. For example in gdk/gdkinternals.h, the memory
allocated to the variable '_gdk_display_arg_name' never gets properly freed (it
gets freed if it needs to get reallocated but otherwise, it just leaks). I
also discovered (although it wasn't relevant to my original post) that simply
calling g_warning() results in about 15 memory leaks, although I didn't have
enough time to find any of them.
I don't know what to do about this. I remember from about a year ago that a
guy was offering to track down memory leaks and if I could find some spare time
over the next few months I'd be happy to assist in finding them, a few at a
time if it would help - but even just that one line of code produces many
hundreds of leaks, so I don't want to be wasting my time if they're just an
inevitable part of the way gtk+ is structured. This seems like one of those
tasks that could soon turn into a can of worms!!
John
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
It's just a question of definition. Many people, me included, don't consider once-only allocations of memory that stays accessible and aren't freed before the program exits leaks. GTK+ and GLib isn't the kind of libraries that you could load dynamically, use a bit, and then unload, and expect to free all their allocations upon unloading. A *true* leak, in my opinion, is if performing some code sequence over and over again (like what happens if you just do the same UI actions repeatedly) causes the amount of unreachable memory to grow continuously. Can Visual Studio detect such leaks? Do you see any of them? And anyway, this OMG GTK+ leaks memory discussion has been had several times already over the years. This parrot is dead. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, 2011-02-09 at 10:44 +0200, Tor Lillqvist wrote:
And anyway, this OMG GTK+ leaks memory discussion has been had
several times already over the years. This parrot is dead.
True.
But it is a shame that there isn't a
gtk_unload_no_I_mean_really_unload_honest() function that we could use -
not for normal use, because with modules etc there are too many
resurrection corner cases - but as a last call before exit() when
testing to make valgrind's life a little easier.
{shrug}
AfC
Sydney
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, Feb 9, 2011 at 4:44 PM, Tor Lillqvist t...@iki.fi wrote: It's just a question of definition. Many people, me included, don't consider once-only allocations of memory that stays accessible and aren't freed before the program exits leaks. GTK+ and GLib isn't the kind of libraries that you could load dynamically, use a bit, and then unload, and expect to free all their allocations upon unloading. IMO there is a use-case for this (or at least a gtk_fini ();) especially in applications where the UI elements are controlled by loadable modules. Not unloading like this is extremely dangerous when those allocated objects and slots go stale and the application might try to re-load the module which initializes gtk again Kind Regards, Sam A *true* leak, in my opinion, is if performing some code sequence over and over again (like what happens if you just do the same UI actions repeatedly) causes the amount of unreachable memory to grow continuously. Can Visual Studio detect such leaks? Do you see any of them? And anyway, this OMG GTK+ leaks memory discussion has been had several times already over the years. This parrot is dead. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Sam Spilsbury ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 Feb 2011, at 08:44, Tor Lillqvist wrote: A *true* leak, in my opinion, is if performing some code sequence over and over again (like what happens if you just do the same UI actions repeatedly) causes the amount of unreachable memory to grow continuously. It's an interesting argument and I could (almost) agree with it if we were referring specifically to program initialisation - but let me cite my earlier example of g_warning(). A call to g_warning() results in 16 memory leaks but when I re-tested it after reading your comment, I realised that 2 calls still only produce 16 leaks. So by your definition Tor, g_warning() doesn't count as code that leaks memory. I would say that it does leak memory because the leak can happen anywhere in my program and won't happen at all a g_warning() never gets issued. When it does leak though, it won't necessarily be associated with the program being initialised so in my view, g_warning() is definitely an example of leaking code. Can Visual Studio detect such leaks? Do you see any of them? Well, that's where things get difficult. AFAIK you can't tell Visual C++ to report some leaks but ignore others. Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been allocated but not yet released. This creates a problem, inasmuch as if memory is leaking according to your definition Tor, it's almost impossible to find the leak among all the other leaks that wouldn't be classed as leaks by your definition. If 500 leaks are being reported, I've no easy way of finding the one leak that you'd describe as genuine. Maybe other leak detectors are more flexible? It would be interesting to find out. I've asked a few other devs if they can suggest a way for VC to ignore certain leaks so I'll let you know if I find anything.. And anyway, this OMG GTK+ leaks memory discussion has been had several times already over the years. This parrot is dead. Well that's the reason I asked. I didn't want to waste my time tracking down these leaks if no-one else was bothered about them. However, it's good to see a couple of other people who can appreciate the value off nailing these leaks! If nothing else, they clearly make leak detection a very difficult task. Just my 2 cents. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: EXTERNAL: Re: Memory leaks
On 2/9/2011 3:44 AM, Tor Lillqvist wrote: several times already over the years. This parrot is dead. No he isn't, he's pining for the fjords... Sorry, couldn't resist Damon Register ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been allocated but not yet released. So it doesn't take into consideration at all whether the memory in question is / can be used or not, i.e. whether there is any pointer to it in local variables, etc. All memory that has not been released is a leak? Does it make sense for a library to spend significant amount of time (potentially paging in pages that have otherwise been stale for ages) when the using process is about to exit, just to free memory, that will be truly freed by the OS anyway as soon as the process finally gets to actually exiting, which it would have already, hadn't the library been spendign time trawling its data structures in order to free memory? This creates a problem, inasmuch as if memory is leaking according to your definition Tor, it's almost impossible to find the leak among all the other leaks that wouldn't be classed as leaks by your definition. With the right tool there is no problem at all in finding such true leaks. On Windows, I guess it could be Purify? --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, Feb 9, 2011 at 12:54, John Emmas john...@tiscali.co.uk wrote: On 9 Feb 2011, at 08:44, Tor Lillqvist wrote: A *true* leak, in my opinion, is if performing some code sequence over and over again (like what happens if you just do the same UI actions repeatedly) causes the amount of unreachable memory to grow continuously. It's an interesting argument and I could (almost) agree with it if we were referring specifically to program initialisation - but let me cite my earlier example of g_warning(). A call to g_warning() results in 16 memory leaks but when I re-tested it after reading your comment, I realised that 2 calls still only produce 16 leaks. So by your definition Tor, g_warning() doesn't count as code that leaks memory. I would say that it does leak memory because the leak can happen anywhere in my program and won't happen at all a g_warning() never gets issued. When it does leak though, it won't necessarily be associated with the program being initialised so in my view, g_warning() is definitely an example of leaking code. No, it just delayed initialization of the logging subsystem. -- Andrew W. Nosenko andrew.w.nose...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 Feb 2011, at 11:13, Tor Lillqvist wrote: Each time you call _CrtDumpMemoryLeaks() it dumps all the memory that's been allocated but not yet released. So it doesn't take into consideration at all whether the memory in question is / can be used or not, i.e. whether there is any pointer to it in local variables, etc. All memory that has not been released is a leak? In your program, you don't normally call _CrtDumpMemoryLeaks() at all (although it's available if you want to do so). Normally though, you leave this to the debugger which calls it when your program closes. In that way, it lists all the memory that got allocated (by the program) but not released (by the program). Does it make sense for a library to spend significant amount of time (potentially paging in pages that have otherwise been stale for ages) when the using process is about to exit, just to free memory, that will be truly freed by the OS anyway If there's a benefit, yes. In this case the benefit is that it would make it easier to find genuine memory leaks. With the right tool there is no problem at all in finding such true leaks. On Windows, I guess it could be Purify? It's certainly worth trying but in my experience, third party analysis tools are rarely better than those built into my IDE (even though they might be more extensive). If there's an evaluation version though, I'll give it a try and see how it performs. Thanks for the suggestion. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 February 2011 11:13, Tor Lillqvist t...@iki.fi wrote: With the right tool there is no problem at all in finding such true leaks. How does one gain this mysterious tool for Linux? I have used Valgrind but as mentioned by numerous souls at numerous times in the past, a suppressions file is needed for GTK/GLIB. And creating a suppressions file is more work than actually writing the code of the program I'm trying to debug in the first place is. james. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, Feb 09, 2011 at 04:02:01PM +, James Morris wrote: I have used Valgrind but as mentioned by numerous souls at numerous times in the past, a suppressions file is needed for GTK/GLIB. And creating a suppressions file is more work than actually writing the code of the program I'm trying to debug in the first place is. Valgrind can generate suppressions, did you know? Anyway, if you can write your complete program in a few minutes then either you can code extermely fast compared to mere mortals such as me or the program is so simple that its correctness can be immediately verified by looking at the source code. The number of required suppressions varies between something like five to a couple of dozens, depending on the parts of Gtk+ and GLib used. Yeti ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
James Morris wrote: How does one gain this mysterious tool for Linux? It's called Google. There's a web page[1] that details how to setup valgrind to debug gtk/glib apps and even a preliminary suppression file. [1] http://live.gnome.org/Valgrind ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 February 2011 16:10, Michael Cronenworth m...@cchtml.com wrote: James Morris wrote: How does one gain this mysterious tool for Linux? It's called Google. There's a web page[1] that details how to setup valgrind to debug gtk/glib apps and even a preliminary suppression file. [1] http://live.gnome.org/Valgrind That's called patronising. I have been there already. What good is a work in progress when the progress stopped over two years ago? Not only do we have to write our own code, we have to put work into making other peoples code ignore the errors in other peoples code so we can see the errors in our own code. It's a bloody outrage! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 Feb 2011, at 17:01, James Morris wrote: Not only do we have to write our own code, we have to put work into making other peoples code ignore the errors in other peoples code so we can see the errors in our own code. It's a bloody outrage! I think I'd agree with you if I'd ever used Valgrind but at least having the option of a suppressions file is better than not having it (as seems to be the case with VC++). It's a double edged sword of course because there's a danger that Valgrind's ability to work with a suppressions file might be seen by those other programmers as carte blanche for them to delay fixing their memory leaks or even not to bother fixing them at all, or (as we have here) to reclassify them as not being genuine leaks. Which brings us neatly back to where we all started off. John P.S I will say though that in all my life I don't think I've ever written a program where it was either impractical (or too difficult) to fix its leaks. IMHO ignoring leaks is a bad habit to get into and one whose consequences usually get worse over time. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
P.S I will say though that in all my life I don't think I've ever written a programwhere it was either impractical (or too difficult) to fix its leaks. IMHO ignoringleaks is a bad habit to get into and one whose consequences usually get worse over time. I could not agree more with this. It seems obvious to me that the GTK team should write code without mem leaks. It's a sad day we even need to argue this. There is no such a thing as good and bad mem leaks, in the long-term they are all plain wrong and promoting buggy code. Carlos On 02/09/11 17:27, John Emmas wrote: On 9 Feb 2011, at 17:01, James Morris wrote: Not only do we have to write our own code, we have to put work into making other peoples code ignore the errors in other peoples code so we can see the errors in our own code. It's a bloody outrage! I think I'd agree with you if I'd ever used Valgrind but at least having the option of a suppressions file is better than not having it (as seems to be the case with VC++). It's a double edged sword of course because there's a danger that Valgrind's ability to work with a suppressions file might be seen by those other programmers as carte blanche for them to delay fixing their memory leaks or even not to bother fixing them at all, or (as we have here) to reclassify them as not being genuine leaks. Which brings us neatly back to where we all started off. John P.S I will say though that in all my life I don't think I've ever written a program where it was either impractical (or too difficult) to fix its leaks. IMHO ignoring leaks is a bad habit to get into and one whose consequences usually get worse over time. ___ 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
Re: Memory leaks
On Wed, 9 Feb 2011, Carlos Pereira wrote: P.S I will say though that in all my life I don't think I've ever written a programwhere it was either impractical (or too difficult) to fix its leaks. IMHO ignoringleaks is a bad habit to get into and one whose consequences usually get worse over time. I could not agree more with this. It seems obvious to me that the GTK team should write code without mem leaks. It's a sad day we even need to argue this. There is no such a thing as good and bad mem leaks, in the long-term they are all plain wrong and promoting buggy code. You're missing Tor's point. Yes, all memory leaks are bad, but most (all?) of the instances of not-explicitly-released memory in the GTK stack are _not_ leaks. If you still have a pointer to it, it ain't a leak, even if a dumb debugger says so. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 Feb 2011, at 20:06, Allin Cottrell wrote: You're missing Tor's point. Yes, all memory leaks are bad, but most (all?) of the instances of not-explicitly-released memory in the GTK stack are _not_ leaks. If you still have a pointer to it, it ain't a leak, even if a dumb debugger says so. But my original example looked like this:- Gtk::Main *app = new Gtk::Main (argc, argv); delete app; How could there possibly be valid pointers still lurking after those operations? Sure, there'll be pointers and they'll be pointing to some memory - but neither of them is valid any more. I think what Tor meant (and this does admittedly have some validity) was that the un-released memory will eventually (in fact, soon) be released by the operating system anyway, so what purpose does it serve to release it specifically? My argument against that was that it makes it a lot easier for a leak detecting utility to do its job properly. But quite apart from that, there's bound to be a suspicion about whether the true reason for not fixing such leaks is really one of scale. Remember that just that one gtkmm call left me with literally hundreds of leaks. Supposing there'd only been six leaks. Would that have imbued more motivation to plug them? I suspect the answer is yes. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, 9 Feb 2011, John Emmas wrote: On 9 Feb 2011, at 20:06, Allin Cottrell wrote: You're missing Tor's point. Yes, all memory leaks are bad, but most (all?) of the instances of not-explicitly-released memory in the GTK stack are _not_ leaks. If you still have a pointer to it, it ain't a leak, even if a dumb debugger says so. But my original example looked like this:- Gtk::Main *app = new Gtk::Main (argc, argv); delete app; How could there possibly be valid pointers still lurking after those operations? Sure, there'll be pointers and they'll be pointing to some memory - but neither of them is valid any more. You initialized the GTK library stack. That involves lots of allocations that have nothing specifically to do with your program. The pointers are maintained at the level of the library code, not your app. I'm afraid you're talking through your hat here. Have your ever worked through the code for even a simple shared library that saves state? Freeing all memory on exit can be useful as a debugging exercise (e.g. if you get a segfault that tells you something), but aside from that it's a pure waste of CPU cycles. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
but aside from that it's a pure waste of CPU cycles. I hate to throw fuel in the fire but this is just absurd! How complex is freeing 200 pointers? O(1)? ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
something), but aside from that it's a pure waste of CPU cycles. Dear Allin, I am sorry, I totally disagree. I can only see two cases. Either fixing these hundreds and hundreds of mem leaks is easy or difficult. In the first case, is just a question of plain laziness and bad programming practises. The second case is much worse, it means the code is badly designed. Carlos ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 9 Feb 2011, at 23:41, Carlos Pereira wrote: something), but aside from that it's a pure waste of CPU cycles. Dear Allin, I am sorry, I totally disagree. I can only see two cases. Either fixing these hundreds and hundreds of mem leaks is easy or difficult. In the first case, is just a question of plain laziness and bad programming practises. The second case is much worse, it means the code is badly designed. I think Allin's point is that even though I deleted the object in my example app, the gtk shared library code is still technically available to be used by some other part of my program (without needing to be re-initialized). In my example, I just happened to not use it. But to go back to some of the earlier suggestions, maybe it would be beneficial to have some kind of unload() / finish() / cleanup() functionality that could be invoked by users who need it. That's what seems to be missing at present. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 10/02/11 04:01, James Morris wrote: On 9 February 2011 16:10, Michael Cronenworthm...@cchtml.com wrote: That's called patronising. I have been there already. What good is a work in progress when the progress stopped over two years ago? Not only do we have to write our own code, we have to put work into making other peoples code ignore the errors in other peoples code so we can see the errors in our own code. It's a bloody outrage! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list My experience with valgrind and GTK is that it is easy to fix leaks. Simply look for leaked memory that you allocated. Then determine where you should have released it. If it was not allocated by you its not your problem so ignore it. Works for me, but I rely on minimal third party software and compile everything with debug enabled. Dont see any sign of leakage problems in GTK, but I dont claim to use all its features; only the ones I need for my GUI code. From time to time I use valgrind to check for leaks with GTK2+ programs written in C and it is clear that there are no leaks. Have not tried GTK3. Have not tried the C++ wrappers. Dont use an IDE. Maybe the problems you have are outside GTK. Rgds Bill C ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
I think Allin's point is that even though I deleted the object in my example app, the gtk shared library code is still technically available to be used by some other part of my program (without needing to be re-initialized). In my example, I just happened to not use it. Yes, I accept Allin's argument here, if you still have access to the pointer is not a leak, I just don't agree with the pure waste of CPU cycles argument... But to go back to some of the earlier suggestions, maybe it would be beneficial to have some kind of unload() / finish() / cleanup() functionality that could be invoked by users who need it. That's what seems to be missing at present. You mean a OPTIONAL gtk_end () function, that could be added in the end, at the programmers's will, after a gtk_main (), to clean everything before going back to the OS? gtk_main (); gtk_end (); I completely agree. Being optional, I suppose both sides would be happy... Carlos John ___ 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
Re: Memory leaks
There is already gtk_init(). It's only logical it should have a counterpart. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, 2011-02-09 at 17:22 -0500, Allin Cottrell wrote: I'm afraid you're talking through your hat here. Have your ever worked through the code for even a simple shared library that saves state? Freeing all memory on exit can be useful as a debugging exercise (e.g. if you get a segfault that tells you something), but aside from that it's a pure waste of CPU cycles. And the fact that so many shared library hackers have this view is the reason modern desktops need to ship with four gigs of RAM minimum and still can't stay up for more than a week. Jeff -- web: http://www.chaosphere.com Author of Genesys, a Free Universal Paper and Pencil RPG. http://www.chaosphere.com/genesys/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 02/09/2011 04:39 PM, Bill C wrote: My experience with valgrind and GTK is that it is easy to fix leaks. Simply look for leaked memory that you allocated. Then determine where you should have released it. If it was not allocated by you its not your problem so ignore it. Right. And if your memory use isn't growing without bound over time then it's not leaking. Whether GTK+ frees it's own allocations or not, your program's memory use is going to be the same. Works for me, but I rely on minimal third party software and compile everything with debug enabled. Dont see any sign of leakage problems in GTK, but I dont claim to use all its features; only the ones I need for my GUI code. From time to time I use valgrind to check for leaks with GTK2+ programs written in C and it is clear that there are no leaks. Have not tried GTK3. Have not tried the C++ wrappers. I would bet that Qt leaks in a similar manner to GTK+. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 02/09/2011 05:05 PM, Jeff Clough wrote: And the fact that so many shared library hackers have this view is the reason modern desktops need to ship with four gigs of RAM minimum and still can't stay up for more than a week. Rubbish. What an absurd and fallacious argument. Whether GTK+ leaks (by your definition) or not, your program, while running, is still going to need the same amount of RAM whether it cleans up initial allocations on program end or not. So except in the case where you want to continually load and unload GTK+'s shared libraries, deleting these initializations on exit is a waste of time. And GTK+ is not designed to be unloaded (I don't know of very many UI libraries that are), I don't see what the problem is. Whether you have a very small amount of RAM or a lot does not matter in the least. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Wed, 9 Feb 2011, Carlos Pereira wrote: something), but aside from that it's a pure waste of CPU cycles. Dear Allin, I am sorry, I totally disagree. I can only see two cases. Either fixing these hundreds and hundreds of mem leaks is easy or difficult. Easy or difficult, if the OS is any good it will do the job just as efficiently or better. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
How times have changed: http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
Some people really don't get this but it's a fact that people like to work with a Bill Atkinson. Not so much with hackers (if you read the above link). Childish? Maybe. Just hope some people get my point. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 02/09/2011 05:34 PM, Costin Chirvasuta wrote: How times have changed: http://www.folklore.org/StoryView.py?story=Were_Not_Hackers!.txt Nothing to do with the issue at hand. Nothing at all. The issue is whether a library intended for one-time loading should clean up after itself. Whether we're talking 64 KB or 4 GB, cleaning up every one-time allocation is still a waste of time. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
I think it's worth pointing out that these normally harmless leaks would
become a problem if gtk was repeatedly loaded and unloaded with
dlopen()+dlclose(). Each dlopen() results in a fresh state, so Gtk would
allocate new instances of these global structures each time.
Not exactly a prominent use case though.
On 9 February 2011 16:50, Michael Torrie torr...@gmail.com wrote:
On 02/09/2011 02:29 PM, John Emmas wrote:
But my original example looked like this:-
Gtk::Main *app = new Gtk::Main (argc, argv);
delete app;
Change it to this and then look at memory use:
for (;;) {
Gtk::Main *app = new Gtk::Main (argc, argv);
delete app;
}
If memory usage grows then GTK leaks. If it doesn't, there is no leak.
___
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
Re: Memory leaks
So it's better to use suppresion with Valgrind then to add a gtk_cleanup() counterpart to gtk_init()? It's better to print something to the display and then put electrical tape over it? Tip: (regarding whether or not that link is relevant) Intelligence means analogy. Being able to make connections. If you understood my meaning and thought it wrong you should have said You analogy is incorrect. Not point out that you didn't find one. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
I'm not saying this is really important and it should be done soon. I'm merely stating that the value of having gtk_cleanup() would be greater than zero. That is, regardless of how much trouble it would be for someone to write, if it would end up in the codebase it's value would be greater than the code bloat it would produce. A lot of people are using GTK and some definitely want it. Not only is it logical and pretty, it would help people as noted above. More clearly, I argue that if gtk_cleanup() existed in the codebase there would be no rationale to remove it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Thu, 10 Feb 2011, Costin Chirvasuta wrote: So it's better to use suppresion with Valgrind then to add a gtk_cleanup() counterpart to gtk_init()? That's debatable, of course, but Yes, it's more efficient for the ordinary use case of the GTK stack -- let the OS reclaim memory on exit -- although it's slightly more awkward for GTK app developers who want to check for true leaks in our apps. If there were a gtk_cleanup() I'd probably use it, but I'm not going to fault the GTK guys for not providing such a function. I think they're doing a great job, and I'm OK with using a suppression file when I'm checking my app's memory use. Allin Cottrell ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 02/09/2011 06:08 PM, Costin Chirvasuta wrote: Tip: (regarding whether or not that link is relevant) Intelligence means analogy. Being able to make connections. If you understood my meaning and thought it wrong you should have said You analogy is incorrect. Not point out that you didn't find one. Why? Your link is simply not relevant to the discussion at hand. I thought I implied that your analogy was incorrect by stating that. I'm sorry you were not able to make [that connection]. Your analogy is incorrect, I say. One last time for luck: Having a gtk_cleanup() has absolutely nothing to do with efficient use of memory. Whether gtk_cleanup() existed or not would have zero impact on the memory usage of your GTK program. Your program will still consume the same amount of RAM, allocated by one-time initializations of the library instance. Thus the argument as to whether GTK+ should be made fully reentrant is completely orthogonal to a pontification on efficient use of RAM. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On Thu, 2011-02-10 at 00:43 +0200, Costin Chirvasuta wrote: but aside from that it's a pure waste of CPU cycles. I hate to throw fuel in the fire but this is just absurd! How complex is freeing 200 pointers? O(1)? Years ago my text retrieval package had an option to call free() for all the data structures on exit, basically just for debugging. It made the programs often go really slow when they exited - adding tens of seconds wasn't uncommon. Why? Because malloc() implementations generally kept a linear linked list of free space, and traversed the list on a free() in case they found adjacent memory areas to the one you were freeing, which they could join together and make into a single larger area. If your application had a larger heap than fit comfortably into main memory, every free() would bring in every page from disk in turn and swap out the earlier ones... and with the next free() the process would repeat... and then just a few million calls to free() could take many many minutes. But on exit() without doing a free, it's indeed O(1) because the OS just marks the pages as unused, without caring about the no-longer-relevant internal structure. These days things are much faster, but a very simple test program indicated that free() can be comparable in some cases in time overhead to malloc(). I'll attach the program; you can vary the constant N and also the amount allocated each time. Using a random amount would be a fairer simulation, and would also might make some implementations of malloc/free() run quite a bit slower. Whether it's better to add something to an API or to write a valgrind special-case file is another matter... consider code that creates a singleton factory,t hat would now have to add that factory to a linked list of items to destroy, together with (possibly new) code to destroy it... using a bit more memory, a bit more code space, more lines of code to maintain, slightly bigger API, documentation, translations... So, I agree it's a good idea to do (and as I mentioned, I've done it myself in the past) but it's for sure not a case of adding one simple line of O(1) code... Best, Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
My analogy had nothing to do with memory use. It had something to do with code beauty which was all that Bill Atkinson was about. It was all that article was about. You got it exactly the other way around. Efficient use of memory at the expense of ugliness was the thing to avoid in that article. I find not cleaning up explicitly quite ugly. I shudder at the thought and maybe I'm not the only one. Not only that, but cleaning up explicitly is obviously useful for some people. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Memory leaks
On 10 Feb 2011, at 01:19, Costin Chirvasuta wrote: I'm not saying this is really important and it should be done soon. I'm merely stating that the value of having gtk_cleanup() would be greater than zero. That is, regardless of how much trouble it would be for someone to write, if it would end up in the codebase it's value would be greater than the code bloat it would produce. A lot of people are using GTK and some definitely want it. I'd like to add my support to that statement though arguably, it's of greater importance in gtkmm. There's a common assumption with object oriented code that it should clean up after itself, which is of course the assumption I'd made (wrongly, as it now seems) in my original example. Remember that it was gtkmm code in my example, not straight gtk+. That's why I assumed there shouldn't be so many leaks being reported. I can't agree with this though:- On 10 Feb 2011, at 00:43, Michael Torrie wrote: The issue is whether a library intended for one-time loading should clean up after itself. Whether we're talking 64 KB or 4 GB, cleaning up every one-time allocation is still a waste of time. Not really. *Something* needs to perform the cleanup operation so if the app did it on shutdown, the OS (presumably) would take correspondingly fewer cycles to unload the app. And remember, we're talking about OPTIONAL functionality here. NOT offering the option results in a far greater waste of programmer time. Remember this comment from a user of Valgrind:- On 9 Feb 2011, at 17:01, James Morris wrote: Not only do we have to write our own code, we have to put work into making other peoples code ignore the errors in other peoples code so we can see the errors in our own code. It's a bloody outrage! I've never used Valgrind but I can fully understand how frustrating that would be and how unproductive. Surely everybody agrees that tracking down genuine leaks in one's code is a good and desirable thing? And surely everybody agrees that having to jump through hoops like that in order to achieve it is an unproductive waste of the programmer's time? Full marks to Valgrind for providing the feature - but it shouldn't excuse sloppiness by other developers. I think there's a compelling case for some kind of optional gtk_end() or gtk_unload() type of function - especially given that gtk is now object oriented through the mechanism of gtkmm. In fact, in the case of gtkmm, Gtk::Main() could possibly just have an extra parameter to signify whether its d'tor should clean up or not. John ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Potential memory leaks on windows port
Hello,
I have tested Deleaker tool (www.deleaker.com) for my application and I have
seen some problems with Gdi objects and user objects.
My actual version of GTK is gtk+-bundle_2.16.0-20090317_win32.
Gdi objects :
0x97011704 (Device context)
GDI32.dll!CreateDCA
libgdk-win32-2.0-0.dll!gdk_keymap_translate_keyboard_state + 921 bytes
libgtk-win32-2.0-0.dll!gtk_disable_setlocale + 1541 bytes
libglib-2.0-0.dll!g_option_context_parse + 1611 bytes
libgtk-win32-2.0-0.dll!gtk_parse_args + 150 bytes
libgtk-win32-2.0-0.dll!gtk_init_check + 24 bytes
libgtk-win32-2.0-0.dll!gtk_init + 24 bytes
NetAlytix.exe!main Line 220
(d:\netanalysis\projects\netalytix\trunk\src\main.c)
NetAlytix.exe!WinMain Line 204
(d:\netanalysis\projects\netalytix\trunk\src\main.c)
NetAlytix.exe!WinMainCRTStartup Line 198 (crt0.c)
0x7c817077
0x
0x2D0A1705 (Font)
GDI32.dll!CreateFontIndirectW
libcairo-2.dll!cairo_win32_printing_surface_create + 918 bytes
libcairo-2.dll!cairo_win32_scaled_font_select_font + 66 bytes
libcairo-2.dll!cairo_win32_scaled_font_select_font + 6874 bytes
libcairo-2.dll!cairo_scaled_font_create + 718 bytes
libpangocairo-1.0-0.dll!pango_cairo_font_get_type + 304 bytes
libpangocairo-1.0-0.dll!pango_cairo_font_get_scaled_font + 409 bytes
libpango-1.0-0.dll!pango_layout_line_x_to_index + 1022 bytes
libpango-1.0-0.dll!pango_layout_line_get_extents + 640 bytes
libpango-1.0-0.dll!pango_layout_line_get_extents + 768 bytes
libpango-1.0-0.dll!pango_layout_line_get_pixel_extents + 6297 bytes
libpango-1.0-0.dll!pango_layout_get_pixel_extents + 71 bytes
libgtk-win32-2.0-0.dll!gtk_cell_renderer_text_new + 906 bytes
libgtk-win32-2.0-0.dll!gtk_cell_view_get_type + 2163 bytes
libgobject-2.0-0.dll!g_closure_invoke + 277 bytes
libgobject-2.0-0.dll!g_signal_has_handler_pending + 2386 bytes
libgobject-2.0-0.dll!g_signal_emit_valist + 1969 bytes
libgobject-2.0-0.dll!g_signal_emit_by_name + 156 bytes
libgtk-win32-2.0-0.dll!gtk_size_group_get_widgets + 219 bytes
libgtk-win32-2.0-0.dll!gtk_size_group_get_widgets + 1212 bytes
libgtk-win32-2.0-0.dll!gtk_combo_box_set_focus_on_click + 439 bytes
libgtk-win32-2.0-0.dll!gtk_combo_box_set_button_sensitivity + 1324 bytes
libgtk-win32-2.0-0.dll!gtk_combo_box_set_button_sensitivity + 2042 bytes
libgobject-2.0-0.dll!g_closure_invoke + 277 bytes
libgobject-2.0-0.dll!g_signal_has_handler_pending + 3925 bytes
libgobject-2.0-0.dll!g_signal_emit_valist + 1969 bytes
libgobject-2.0-0.dll!g_signal_emit + 38 bytes
libgtk-win32-2.0-0.dll!gtk_tree_model_row_inserted + 98 bytes
libgtk-win32-2.0-0.dll!gtk_list_store_insert + 432 bytes
libgtk-win32-2.0-0.dll!gtk_list_store_append + 76 bytes
libgtk-win32-2.0-0.dll!gtk_combo_box_append_text + 272 bytes
I think that the first leak is not really important but for the second,
the problem appears at each call of gtk_combo_box_append_text()
User objects :
The list below (a bit long), show some problems with icons deletion. For
example :
{
gtk_dialog_new_with_buttons()
gtk_widget_show_all()
gtk_dialog_run()
gtk_widget_destroy()
}
The pseudo code above destroy the dialog boxe but doesn't remove all created
icons.
0x1EEF0149 (Icon)
USER32.dll!CopyIcon
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
libgdk-win32-2.0-0.dll!gdk_window_set_transient_for + 2098 bytes
libgtk-win32-2.0-0.dll!gtk_text_view_new_with_buffer + 4170 bytes
libgtk-win32-2.0-0.dll!gtk_text_view_get_border_window_size + 853 bytes
libgobject-2.0-0.dll!g_closure_invoke + 277 bytes
libgobject-2.0-0.dll!g_signal_has_handler_pending + 2386 bytes
libgobject-2.0-0.dll!g_signal_emit_valist + 1969 bytes
libgobject-2.0-0.dll!g_signal_emit + 38 bytes
libgtk-win32-2.0-0.dll!gtk_widget_realize + 324 bytes
libgtk-win32-2.0-0.dll!gtk_widget_set_parent + 768 bytes
libgtk-win32-2.0-0.dll!gtk_scrolled_window_get_shadow_type + 6704 bytes
libgobject-2.0-0.dll!g_closure_invoke + 277 bytes
libgobject-2.0-0.dll!g_signal_has_handler_pending + 2386 bytes
libgobject-2.0-0.dll!g_signal_emit_valist + 1969 bytes
libgobject-2.0-0.dll!g_signal_emit + 38 bytes
libgtk-win32-2.0-0.dll!gtk_container_add + 315 bytes
0x1EE20149 (Icon)
USER32.dll!CopyIcon
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
0x00142d7b
libgdk-win32-2.0-0.dll!gdk_window_set_transient_for + 2098 bytes
libgtk-win32-2.0-0.dll!gtk_text_view_new_with_buffer + 4170 bytes
libgtk-win32-2.0-0.dll!gtk_text_view_get_border_window_size + 853 bytes
libgobject-2.0-0.dll!g_closure_invoke + 277 bytes
libgobject-2.0-0.dll!g_signal_has_handler_pending + 2386 bytes
libgobject-2.0-0.dll!g_signal_emit_valist + 1969 bytes
libgobject-2.0-0.dll!g_signal_emit + 38 bytes
libgtk-win32-2.0-0.dll!gtk_widget_realize + 324 bytes
libgtk-win32-2.0-0.dll!gtk_widget_set_parent + 768 bytes
libgtk-win32-2.0-0.dll!gtk_scrolled_window_get_shadow_type + 6704 bytes
libgobject-2.0-0.dll!g_closure_invoke + 277 bytes
libgobject-2.0-0.dll!g_signal_has_handler_pending + 2386 bytes
Re: Potential memory leaks on windows port
Please file a bug report at bugzilla.gnome.org and attach a *minimal* and *complete* sample program (as a single source file, in C or Python) that reproduces the leak. (I.e., a program which shows a continuously growing amount of GDI resources consumed without any clear reason.) --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE : Potential memory leaks on windows port
Ok, I am sorry. I report the bug as soon as possible. Cyril ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
memory leaks observed in gtk app.
Hi, I am working on a gtk application which when used continuously exhibits memory leak. I have verified this by top output which shows continuous increase in memory used by it. After analysing the problem with valgrind, memprof and mpatrol, a couple of observations have been made: 1- program heavily uses gtk_main_iteration. memory debuggers show memory leak in this function. 2- No references have been made to gtk objects from the program, still it is opbserved that after destroying a window object it is still referenced. I am using gtk+ 2.4.13. Is there any chance of any gtk api function creating a reference to an object which the caller has the responsibility to clear? If yes, is there a list available for such functions because the documentation does not specify any such thing. Also, are there any know issues with using gtk_main_iteration? Thanks Anurag The information contained in this electronic mail transmission may be privileged and confidential, and therefore, protected from disclosure. If you have received this communication in error, please notify us immediately by replying to this message and deleting it from your computer without copying or disclosing it. ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Valgrind-users] debugging gtk-related memory leaks
I tried it with the debug info packages and malloc, and now there are only a few X/gtk errors. Anyone have suggestions on how to approach those? Maybe someone on the gtk-app-devel-list? Thanks, David Julian Seward wrote: Maybe you should set G_SLICE=always-malloc in the environment in order to make valgrind more useful: http://developer.gnome.org/doc/API/2.0/glib/glib-running.html I agree; from a guess I'd say that glib is using a private allocator, which confuses the issue. Unrelatedly .. It looks like the 'valgrind-3.1.1-Debian' you are using has been shipped without a set of suppressions suitable for getting rid of all the complaints of the form ==3722== Conditional jump or move depends on uninitialised value(s) ==3722==at 0x401139F: (within /lib/ld-2.3.6.so) ==3722==by 0x4006ACE: (within /lib/ld-2.3.6.so) ==3722==by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) which is a shame. It may be that if you install debug info packages for /lib/ld-2.3.6.so and/or libc-2.3.6.so, that noise will go away. J ==25785== Memcheck, a memory error detector. ==25785== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==25785== Using LibVEX rev 1575, a library for dynamic binary translation. ==25785== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==25785== Using valgrind-3.1.1-Debian, a dynamic binary instrumentation framework. ==25785== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==25785== For more details, rerun with: -v ==25785== ==25785== Syscall param write(buf) points to uninitialised byte(s) ==25785==at 0x4836783: __write_nocancel (in /lib/tls/i686/cmov/libpthread-2.3.6.so) ==25785==by 0x4D16E3E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4D1BB54: (within /usr/lib/libX11.so.6.2.0) ==25785==by 0x4D1BC7C: _XReply (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4D01862: XInternAtom (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4D160EA: XSetWMProperties (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4B90C59: (within /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x4B93B25: gdk_window_new (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x4B71F9B: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x4B510DE: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x497378E: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.800.17) ==25785==by 0x49737C3: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.800.17) ==25785== Address 0x5210FD0 is 128 bytes inside a block of size 16,384 alloc'd ==25785==at 0x480788E: calloc (vg_replace_malloc.c:279) ==25785==by 0x4D06B83: XOpenDisplay (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4B71EC1: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x4B510DE: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x497378E: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.800.17) ==25785==by 0x49737C3: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.800.17) ==25785==by 0x8059238: main_gui(int, char**) (gui.C:108) ==25785==by 0x804F6B1: main (time.C:83) ==25785== ==25785== Syscall param write(buf) points to uninitialised byte(s) ==25785==at 0x48367AB: (within /lib/tls/i686/cmov/libpthread-2.3.6.so) ==25785==by 0x4D16E3E: _X11TransWrite (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4D1BB54: (within /usr/lib/libX11.so.6.2.0) ==25785==by 0x4D1CEAB: _XEventsQueued (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4D08792: XPending (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4B7E9CD: _gdk_events_queue (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x4B7EBCE: (within /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x4E0F690: g_main_context_dispatch (in /usr/lib/libglib-2.0.so.0.1000.2) ==25785==by 0x4E129D6: (within /usr/lib/libglib-2.0.so.0.1000.2) ==25785==by 0x4E12F27: g_main_loop_run (in /usr/lib/libglib-2.0.so.0.1000.2) ==25785==by 0x4974340: gtk_main (in /usr/lib/libgtk-x11-2.0.so.0.800.17) ==25785==by 0x80595D3: main_gui(int, char**) (gui.C:157) ==25785== Address 0x52110F4 is 420 bytes inside a block of size 16,384 alloc'd ==25785==at 0x480788E: calloc (vg_replace_malloc.c:279) ==25785==by 0x4D06B83: XOpenDisplay (in /usr/lib/libX11.so.6.2.0) ==25785==by 0x4B71EC1: gdk_display_open (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x4B510DE: gdk_display_open_default_libgtk_only (in /usr/lib/libgdk-x11-2.0.so.0.800.17) ==25785==by 0x497378E: gtk_init_check (in /usr/lib/libgtk-x11-2.0.so.0.800.17) ==25785==by 0x49737C3: gtk_init (in /usr/lib/libgtk-x11-2.0.so.0.800.17) ==25785==by 0x8059238: main_gui(int, char**) (gui.C:108) ==25785==by 0x804F6B1: main (time.C:83) join engine... ==25785== ==25785== Syscall param write(buf) points to uninitialised byte(s) ==25785==
debugging gtk-related memory leaks
Hello, Could anyone offer help or advice on debugging mysterious gtk-related memory leaks and errors reported by valgrind when checking a threaded GTK+ program? The primary potential leak seems to be a sizeable chunk in g_thread_init, and there are quite a few errors from various unknown contexts (including g_module_open). Please take a look at the attached valgrind --leak-check=full output, and/or offer general advice on pursuing such errors and leaks, which are almost undoubtedly caused by my code, yet do not appear to come from any context I am familiar with. Is there some procedure for cleaning up g_threads, apart from adding a window destroy handler like gtk_main_quit? Thanks, David ==3722== Memcheck, a memory error detector. ==3722== Copyright (C) 2002-2005, and GNU GPL'd, by Julian Seward et al. ==3722== Using LibVEX rev 1575, a library for dynamic binary translation. ==3722== Copyright (C) 2004-2005, and GNU GPL'd, by OpenWorks LLP. ==3722== Using valgrind-3.1.1-Debian, a dynamic binary instrumentation framework. ==3722== Copyright (C) 2000-2005, and GNU GPL'd, by Julian Seward et al. ==3722== For more details, rerun with: -v ==3722== ==3722== Conditional jump or move depends on uninitialised value(s) ==3722==at 0x4011394: (within /lib/ld-2.3.6.so) ==3722==by 0x4006ACE: (within /lib/ld-2.3.6.so) ==3722==by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x48A1E6A: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x45F9D27: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x45FA456: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45F9D80: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45398F8: (within /usr/lib/libX11.so.6.2.0) ==3722==by 0x4539B42: _XlcDynamicLoad (in /usr/lib/libX11.so.6.2.0) ==3722==by 0x454E108: _XOpenLC (in /usr/lib/libX11.so.6.2.0) ==3722== ==3722== Conditional jump or move depends on uninitialised value(s) ==3722==at 0x401139F: (within /lib/ld-2.3.6.so) ==3722==by 0x4006ACE: (within /lib/ld-2.3.6.so) ==3722==by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x48A1E6A: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x45F9D27: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x45FA456: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45F9D80: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45398F8: (within /usr/lib/libX11.so.6.2.0) ==3722==by 0x4539B42: _XlcDynamicLoad (in /usr/lib/libX11.so.6.2.0) ==3722==by 0x454E108: _XOpenLC (in /usr/lib/libX11.so.6.2.0) ==3722== ==3722== Conditional jump or move depends on uninitialised value(s) ==3722==at 0x40113AA: (within /lib/ld-2.3.6.so) ==3722==by 0x4006ACE: (within /lib/ld-2.3.6.so) ==3722==by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x48A1E6A: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x45F9D27: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x45FA456: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45F9D80: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45398F8: (within /usr/lib/libX11.so.6.2.0) ==3722==by 0x4539B42: _XlcDynamicLoad (in /usr/lib/libX11.so.6.2.0) ==3722==by 0x454E108: _XOpenLC (in /usr/lib/libX11.so.6.2.0) ==3722== ==3722== Conditional jump or move depends on uninitialised value(s) ==3722==at 0x40114DA: (within /lib/ld-2.3.6.so) ==3722==by 0x4006ACE: (within /lib/ld-2.3.6.so) ==3722==by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x48A1E6A: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x45F9D27: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x45FA456: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45F9D80: dlopen (in /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x45398F8: (within /usr/lib/libX11.so.6.2.0) ==3722==by 0x4539B42: _XlcDynamicLoad (in /usr/lib/libX11.so.6.2.0) ==3722==by 0x454E108: _XOpenLC (in /usr/lib/libX11.so.6.2.0) ==3722== ==3722== Conditional jump or move depends on uninitialised value(s) ==3722==at 0x40114DA: (within /lib/ld-2.3.6.so) ==3722==by 0x400717A: (within /lib/ld-2.3.6.so) ==3722==by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722==by 0x48A1E6A: _dl_open (in /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x45F9D27: (within /lib/tls/i686/cmov/libdl-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) ==3722
Re: [Valgrind-users] debugging gtk-related memory leaks
On Sun, 2006-08-20 at 05:48 -0400, David Ellis wrote: Hello, Could anyone offer help or advice on debugging mysterious gtk-related memory leaks and errors reported by valgrind when checking a threaded GTK+ program? The primary potential leak seems to be a sizeable chunk in g_thread_init, and there are quite a few errors from various unknown contexts (including g_module_open). Please take a look at the attached valgrind --leak-check=full output, and/or offer general advice on pursuing such errors and leaks, which are almost undoubtedly caused by my code, yet do not appear to come from any context I am familiar with. Is there some procedure for cleaning up g_threads, apart from adding a window destroy handler like gtk_main_quit? Maybe you should set G_SLICE=always-malloc in the environment in order to make valgrind more useful: http://developer.gnome.org/doc/API/2.0/glib/glib-running.html \David -- ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: [Valgrind-users] debugging gtk-related memory leaks
Maybe you should set G_SLICE=always-malloc in the environment in order to make valgrind more useful: http://developer.gnome.org/doc/API/2.0/glib/glib-running.html I agree; from a guess I'd say that glib is using a private allocator, which confuses the issue. Unrelatedly .. It looks like the 'valgrind-3.1.1-Debian' you are using has been shipped without a set of suppressions suitable for getting rid of all the complaints of the form ==3722== Conditional jump or move depends on uninitialised value(s) ==3722==at 0x401139F: (within /lib/ld-2.3.6.so) ==3722==by 0x4006ACE: (within /lib/ld-2.3.6.so) ==3722==by 0x48A14AF: (within /lib/tls/i686/cmov/libc-2.3.6.so) ==3722==by 0x400BA5E: (within /lib/ld-2.3.6.so) which is a shame. It may be that if you install debug info packages for /lib/ld-2.3.6.so and/or libc-2.3.6.so, that noise will go away. J ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Finding memory leaks
Valgrind http://valgrind.org On 1/18/06, Juan Pablo [EMAIL PROTECTED] wrote: Hi list! I've made some progress on my program and now i would like to check for memory leaks. Do you recommend any way or program in special for doing this? Thanks all. Saludos, Juan Pablo. ___ 1GB gratis, Antivirus y Antispam Correo Yahoo!, el mejor correo web del mundo http://correo.yahoo.com.ar ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Thomas Coppi ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
RE: Finding memory leaks
I've made some progress on my program and now i would like to check formemory leaks. Do you recommend any way or program in special for doing this? Something I've sometimes found useful, was to write a little chunk of code that throws up a small window that holds a list view, into which I place some basic information about various widgets and windows. Such things as address, visible state, name (if set), and the objets current reference count (which unfortunately can't be monitored with a signal handler). It won't find everything, but if you suspect an object might be hanging around, you can easily keep an eye on it. Essentially I wrote a add_XXX_watch() (eg. add_window_watch or add_object_watch) function which takes a newly allocated object, and connects a bunch of signals to it, along with a weak reference, and creates a row in the list view. (It also creates the list window if it's not already open) You just call that function in various places where you've created a new object. The class specific function connects callbacks that pluck out the information I'm interested in, forms it into a string, and sets that as the new row data (a simple string is nice and easy). One callback can usually handle several signals, by only taking the first argument (object pointer) and plucking out what it needs from scratch. When the weak reference ends, it alters the row colour, and sets the object pointer to NULL (so we don't go trying to access it). A quick row click handler lets me call gtk_window_present() on the entry clicked (doesn't work too good on non-windows though ;) ), and clicking an old reference (no object pointer) totally removes it from the list view. Generally I just toss little bits and pieces into the thing as I go along (or quite often, as I see them on this list and want to try it out for myself). It's a seriously messy piece of code, but it comes in quite handy. I actually practiced building my first menu popup on the thing. ;) The codes compiled as a small library I include into projects I'm working on, and the header makes everything go away nice and cleanly if a #define isn't jammed in. I think it's slowly evolving into some kind of gtk widget explorer, but one of its most handy features is still the reference count, of all things (which I update on a low priority timeout). The important thing, though, is that my little home-grown tool knows exactly what I'm often interested in, presents it in a way that I find appropriate, and provides me a means to quickly point my debugger at any of those objects, even if they're otherwise lost or a pain to track down from the present scope. (A couple function buttons in ddd let me do further poking around) It's another tool right alongside valgrind and debuggers. 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
